1 2 Previous Next 20 Replies Latest reply on Aug 29, 2011 9:05 PM by valmir

    ListShuttle/Ordering List components redesign

    ilya_shaikovsky

      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

      1. 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.
      2. 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.

        • 1. Re: ListShuttle/Ordering List components redesign
          jbalunas

          Hi All,

           

          We will be discussing the ListShuttle and PickList component options for 4.1 at tomorrows meeting.  Please read through the details above and we'll discuss requirements tomorrow. 

           

          The idea of combining these components is important I think since their functionality is so similar.

           

          -Jay

          • 2. Re: ListShuttle/Ordering List components redesign
            nbelaevski

            Hi all,

             

            I agree for select items, but not sure that we should maintain both source and target values at this point - IMHO only target value is really necessary.

            And I think that we can relax requirement for preserving ordering of source items, IMHO that's beyond list shuttle scope and use cases.

             

            About necessity for converter - if we keep collection of initial values unmodified in component, then we can go without converters easily - simply by using index of the item in the list as its key. 

             

            Should we add sorting/filtering at this stage?

             

            Ilya,

             

            can you please clarify on this:

             

            >> 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)

             

            I guess you meant to say collection of item values, not simple value?

            • 3. Re: ListShuttle/Ordering List components redesign
              jbalunas

              Nick Belaevski wrote:

               

              I agree for select items, but not sure that we should maintain both source and target values at this point - IMHO only target value is really necessary.

              And I think that we can relax requirement for preserving ordering of source items, IMHO that's beyond list shuttle scope and use cases.

              This depends on how you view the "role" of the listShuttle, although I agree we can loosen some of the requirements here I think as well.  ListShuttle is changing both source and target lists - in most cases that means listShuttle is responsible for both the source and target.  I do think we can pass some of the management responsibility to the user though ( perhaps with listener events ).  This would give them the flexibility to manage to shifts ( both ways ), and let us focus on the core component.

               

              About necessity for converter - if we keep collection of initial values unmodified in component, then we can go without converters easily - simply by using index of the item in the list as its key. 

              This would make source list static correct?  We would no longer be actually modifying source - only changing target?

               

              Should we add sorting/filtering at this stage?

              My initial thought here is no.  This is some of the advanced functionality that we can leave to the users so they can optimize and handle as needed for their app.  We should think about how a user would want to do this however.

              • 4. Re: ListShuttle/Ordering List components redesign
                nbelaevski

                Jay Balunas wrote:

                 

                Nick Belaevski wrote:

                 

                I agree for select items, but not sure that we should maintain both source and target values at this point - IMHO only target value is really necessary.

                And I think that we can relax requirement for preserving ordering of source items, IMHO that's beyond list shuttle scope and use cases.

                This depends on how you view the "role" of the listShuttle, although I agree we can loosen some of the requirements here I think as well.  ListShuttle is changing both source and target lists - in most cases that means listShuttle is responsible for both the source and target.  I do think we can pass some of the management responsibility to the user though ( perhaps with listener events ).  This would give them the flexibility to manage to shifts ( both ways ), and let us focus on the core component.

                 

                About necessity for converter - if we keep collection of initial values unmodified in component, then we can go without converters easily - simply by using index of the item in the list as its key. 

                This would make source list static correct?  We would no longer be actually modifying source - only changing target?

                Yes, that's it. I see this component as input for target list that allows to select some items in the certain order.

                • 5. Re: ListShuttle/Ordering List components redesign
                  ilya_shaikovsky

                  1) I completelly agree with Nick about targetValue. I really thought about the same but just forgot to include. Having the source value really not helpfull in cases a looked to across different apps. Besides it's possible just calculate them having all items and choosen ones.

                   

                   

                  2)

                  Ilya,

                   

                  can you please clarify on this:

                   

                  >> 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)

                   

                  I guess you meant to say collection of item values, not simple value?

                  good catch, sure.

                   

                  3) Should we add sorting/filtering at this stage?

                   

                  I really voting for "no" Because of the same as inputs support. My personal opinion that in order to be usefull and convenient - component should be created in a simple way from the beginning. In that case as just select with optional values ordering.. stable and lightweight.. and then it would be possible to play with it and having etalon behavior - compare to the "swiss knife" which could be done by adding filtering/sorting/pagging/and finally inputs support 

                  • 6. Re: ListShuttle/Ordering List components redesign
                    jbalunas

                    Ilya Shaikovsky wrote:

                     

                    1) I completelly agree with Nick about targetValue. I really thought about the same but just forgot to include. Having the source value really not helpfull in cases a looked to across different apps. Besides it's possible just calculate them having all items and choosen ones.

                    Then we are really talking about a pure PickList - a component for picking items from one list, and copying them to the target.  The ListShuttle imo represents the shuttling of items between lists - implying modifying both.

                     

                    There are valid use-cases for both however, so we'll need to make sure we satisfy requirements.  However this could also be managed by users if we provide the right events, and listener support.  i.e. they could listen for a shift, and adjust source if them want to.

                    • 7. Re: ListShuttle/Ordering List components redesign
                      jbalunas

                      Ilya Shaikovsky wrote:

                       

                      3) Should we add sorting/filtering at this stage?

                       

                      I really voting for "no" Because of the same as inputs support. My personal opinion that in order to be usefull and convenient - component should be created in a simple way from the beginning. In that case as just select with optional values ordering.. stable and lightweight.. and then it would be possible to play with it and having etalon behavior - compare to the "swiss knife" which could be done by adding filtering/sorting/pagging/and finally inputs support 

                      Agree - and again I think that we can leave this to the user if we provide the correct event/listener support.  I think we need to make sure to take these things into consideration, but we don't need to implement them.

                      • 8. Re: ListShuttle/Ordering List components redesign
                        lfryc

                        Making source list static will require relatively complex client-side API for source list management - and I'm fine with that - I don't like idea of having go through the server request when achieving removing of items from source list.

                         

                         

                        We should also provide samples for all of the scenarios which was possible in 3.3.x and which was requested by users - it will allow grab that component and rewrap with CC easily, achieving own custom behavior without the need copy&paste our component.

                        • 9. Re: ListShuttle/Ordering List components redesign
                          nbelaevski

                          Lukas,

                           

                          Just to clarify: what I mean by static is not keeping it immutable at all, but keep an immutable copy of the list on the server. On the client both source and target lists are modifiable.

                           

                          >> We should also provide samples for all of the scenarios which was possible in 3.3.x and which was requested by users - it will allow grab

                          >> that component and rewrap with CC easily, achieving own custom behavior without the need copy&paste our component.

                           

                          Ilya,

                           

                          YThen the question is: do you know if somebody used command/input components in listShuttle 3.x applications?

                          • 10. Re: ListShuttle/Ordering List components redesign
                            bleathem

                            Here's my summary of the List components dicsussion:

                             

                            In RichFaces 3.3

                            Components:

                            OrderingList
                            Order items in a single list
                            PickList
                            Select items from the left list, and move them to the right list
                            ListShuttle
                            A PickList where the right-side list is an ordering list

                            The PickList is a seperate component altogether from the ListShuttle in RichFaces 3.3 because the ListShuttle required the list item objects to implement the equals, hashCode, and provide converters.  The PickList was provided as an easier to use alternative.

                            Advantages

                            Support for multiple columns, with defferent types of content

                            Dis-advantages

                            • Too many components to choose from, with overlapping functionality
                            • Too many methods to implement to use the ListShuttle
                            • Editable items in the list introduce too much complexity

                            For RichFaces 4.1

                            The proposal

                            • Use the JSF 2 f:selectItems functionality within our list.
                              • Using the <rich:listXxx> will be like using a h:datatable or ui:repeat
                            • Keep the source list static on the server.
                            • Broadcast an event when an item is added/removed from the target list

                            Moving forward

                            I'll begin prototyping the above functionality, but please feel free to add any further toughts/requirements to this discussion.

                            • 11. Re: ListShuttle/Ordering List components redesign
                              bleathem

                              More on the plan moving forward:

                               

                              The initial prototype:

                              The initial prototype will be either a pickList or orderingList implementation, as the listshuttle will be a combination of those two. 

                              Any thoughts on what would be the preferred component to start with?

                               

                              PickList prototype:

                              On the serverside, the PickList will modify only the target collection, leaving the source collection untouched.  As pointed out above, the new source collection can be inferred from the initial source collection, and the new target collection.

                               

                              The model of this component will be as close to the SelectMany component as possible.

                               

                              OrderingList prototype:

                              A single collection will back the orederingList.

                               

                              As I get further into the protoype, I'll follow-up with the list of attributes and events the components will support.

                              • 12. Re: ListShuttle/Ordering List components redesign
                                bleathem

                                Following up with a preview of the picklist component.

                                 

                                Example facelet source:

                                            <rich-input:pickList id="pickList" value="#{richBean.values}">
                                                <f:selectItem itemValue="0" itemLabel="Option 0" />
                                                <f:selectItem itemValue="1" itemLabel="Option 1" />
                                                <f:selectItem itemValue="2" itemLabel="Option 2" />
                                                <f:selectItem itemValue="3" itemLabel="Option 3" />
                                                <f:selectItem itemValue="4" itemLabel="Option 4" />
                                            </rich-input:pickList>
                                

                                 

                                Gives this result:

                                picklist.png

                                 

                                I next need to add the support for multi-colum support with <rich:column>.

                                 

                                If you are intested, Source is available in the pickList feature branch of the github components repository.

                                https://github.com/richfaces/components/tree/feature/pickList

                                • 13. Re: ListShuttle/Ordering List components redesign
                                  bleathem

                                  The proposal here was to have the selectItems' definitions in the pickList tag itself.  What do people think of instead keeping this in child f:select tags?

                                   

                                  The resulting xhtml would look like:

                                  <rich:pickList id="pickList" value="#{richBean.values}">
                                      <f:selectItems value="#{beanSelector.values}" var="item"  itemValue="#{item}" itemLabel="#{item.title}" />
                                      <f:converter converterId="EntityBeanConverter" />
                                      <rich:column>
                                          ....
                                      <rich:column>
                                      <rich:column>
                                          ....
                                      <rich:column>
                                  </rich:pickList>
                                  

                                   

                                  To me this seems cleaner/more consistent with the way selectItems are treated in the rest of the platform.  It does however break with usage patters of other iterators, like dataTables and uiLrepeat.

                                   

                                  Your feedback is appreciated!

                                  • 14. Re: ListShuttle/Ordering List components redesign
                                    nbelaevski

                                    Brian,

                                     

                                    Looks good for me. For usage patterns of iterators - we've already got iteration components with the similar style of declaration - that's tree with adaptor tags. So I don't see a big issue there.

                                    1 2 Previous Next