This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 131997 - Allow List<Model> and Model[] to be used as data source for the rest of data bindable components
Summary: Allow List<Model> and Model[] to be used as data source for the rest of data ...
Status: NEW
Alias: None
Product: obsolete
Classification: Unclassified
Component: visualweb (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: Winston Prakash
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-04-03 23:58 UTC by bikestain
Modified: 2008-04-03 23:58 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description bikestain 2008-04-03 23:58:44 UTC
This is related to issue 130332
It was a nice idea to allow data binding without having to implement an extra DataProvider for each model class.
However, this feature is currently limited to the Table component.
Is it possible to extend it to other data-bindable components such as  Dropdown, Radio and Checkbox groups?

Although no DataProvider implementation is needed for the Table now, most of the web apps still use the other data 
components and still have to deal with custom DataProvider implemenations just to support these components.
Data binding dialog should allow selection of List<Model> and Model[] properties as data providers, and let the users 
choose a couple of the Model's properties - one for display and another for value.

As an extra enhancement, it would be more useful if the users could customize display/value names manually to use not 
just model's properties but arbitrary JSF expresions (with evaluation based on the current list item as a root)

For example, say the Model has properties:
-String id
-String name
-ModelType type

For implementation simplicity, the UI would only list these three properties in the Display and Value lists and would 
only allow to select them as binding expressions (similar to what the regular property binding dialog does)
But then users could customize the expression and use something like this:
#{currentItem.type.somePropertyOfType.etc}
#{!empty currentItem.name? currentItem.name : 'noname'}