ListShuttle/Ordering List components redesign
It's time to decide the way of impl for the components as them are one of the "most wanted" ones. That topic are created in order to discuss the way of redesign which will allow the developer to spend less time on component adoption. It will contains only model problem for now but bringing other problems are welcome for discussion for sure. All the features not bringed there - will be added as a requirements direclty to wiki after we will get the result for that thread.
That document talks about two components listShuttle and orderingList. And if the model problem will be resolved - pickList will just not be eeded anymore. (Or we could just rename listShuttle if pickList will sounds better.)
Problems of 3.3.x implementation
- Main problem in 3.3.x (and the reason of the third pickList component to appear) was requirement of having converter and equals and hashCode methods defined for the Objects which used as the component source/target bindings. That was the reason of most of the forum problems discussions as it caused much of the developers spend a lot of time in the debug before having simple "select" functinoality to work.
- All the other problems are more minor however them should be adressed at some point so will be listed in final wiki page after the main design problem will be solved.
Advantage of 3.3.x which has to be kept
It's not enough for modern application to have simple selects with just the label(rich:pickList). It was critical feature to have multiple columns in representation and being able to show different type of content there.
<To add?>
Features proposed to drop
Initially I want to propose only one feature to that list - ability to have editable components in the lists. Reasons:
- unnatural for select component in general. It supposed to order/select from some list rather than edit that list and make selection in the same time.
- workarounds available. If the developer really need in such hybrid he could get the dataTable, create composite component and just add all the selection ordering functionality there.
- Problems in implementation. Complexity of such support caused by the nesessity to support UIData processing (instead just having selection mechanism) was the reason of numerous issues.
Proposal for implementing the components without converter requirement
Simplest proposal looks like - to use new JSF 2 SelectItems features. f:selectItems allows us to define:
- value - Object. could be SelectItem, SelectItem's array or list, or Array or list of any objects(most interesting for us).
- var - name for request scoped variable used during iteration of the list or array defined in value.
- itemLabel, itemValue - should be poited using EL and var to the value/label actual values.
- itemDisabled, itemDescription and so on - usefull for other functionality but could be skipped for now(just for that section discussion I mean).
So we could now use the next definition instead:
<rich:listShuttle sourceValues="#{bean.source}" targetValues="#{bean.target}"
items="#{bean.fooItems}" var="foo" itemValue="#{foo.id}" itemDisabled="#{foo.disabled}">
<rich:column>
#{foo.label}
</rich:column>
<rich:column>
<h:graphicImage value="#{foo.imageURL}">
</rich:column>
</rich:listShuttle>
It will allows us to act with that component as with pure select having labels encoded using nested columns rendering and having value for each object which will allow us to identify that object in source list.
source and target values in that case could store just itemValue (foo.id) instead of having collections of the original elements. (also as pure select does)
And finally for the guys who not need the complex variant:
<rich:listShuttle targetValues="#{bean.target}" items="#{bean.fooItems}">
could be used. In that case fooItems expected to be selectItems.
Alternative
Just an alternative to the previous way. It's less convinient as I think because required to learn one more entity.
We could just create our special visual model in order not to deal with converters and other staff. But actually for the user it will means the same actions - he will need to get his original data and convert to our special model in order it to be processed correctly.
