1 2 Previous Next 21 Replies Latest reply on Jan 20, 2010 7:59 AM by Anton Belevich

    Richfaces 4.0 dataTables models implementation discussion

    Anton Belevich Novice

      Hi,

      As all of you know in the richfaces 4.0.0 were proposed provide two dataTables component instead of combine all features to the one high featured component. These components are:

      1. SimpleDataTable - light-weight component with simple table functionality with table based markup.

      2. ExtendedDataTable - complex but high featured component with fully div based markup.

      see wiki article article


      During implementation discussion were proposed two points of view for the data model processing implementation:

      1. Use existing dataModels from the 3.3.X with needed fixes for the JSF2.0 api. Fix selection bug when sorting changes, add grouping feature for the subtables.
      + there is a well tested code what should be refactored for the richfaces 4.0.0.
      - user should implement custom dataModels which extend our models if he want implement specific behaviors;

      2. Proposed by Nick. Create some kind of visual data model where will be stored current states for the selection/grouping/filtering etc. for each column and provide api for work with these functionality. For example there is a simple bean, which contains List of some fooObjects and implements method for the sortEvent processing

      @ManagedBean(name="sampleBean")
      @SessionScoped
      public class SampleBean {
      
       private List <FooObject> fooData;
      
       private VisualModel visualModel;
      
      
       public sortListener(SortEvent event) {
       String direction = visualMoldel.getSortDirection();
       // do fooData sorting
       }
      }
      


      dataTable with sorting controls which support asc/desc sorting.
       <rich:dataTable visualModel="#{sampleBean.visualModel}" listener="#{sampleBean.sortListener}" value="#{sampleBean.fooData}">
      


      User click on sorting control, sort event fired and sortListener method called in this method user should get sort direction from the visual model and do sort for the list of data objects. The same way grouping and filtering features could be implemented

      + There is now need for the user to implement custom data models, he could use standard JSF dataModels. (Some kind of functionality to bind row key with the object is still required. Probably, in a variant of extended rowKeyConverter - this should be designed to work on EJB side and use only API dependencies.)
      - All works relating to sorting/filtering/grouping etc. should be implemented by user himself.


      Thoughts which way we should choose are welcome




        • 1. Re: Richfaces 4.0 dataTables models implementation discussio
          Ilya Shaikovsky Master

          Has some additional questions about #2:

          1) if the user always need to write the listerners for corresponding events and provide code for sorting/filtering/... listeners? Or we will provide some default mechanisms?

          2) In general can't get the advantages of VisualModel class. Why it's better than just simple maps which can hold the states as currently? If the user will have to define such bindings why he should learn some additional class?

          3)

          + There is now need for the user to implement custom data models, he could use standard JSF dataModels.

          This is available in current default implementation also. And seems complex example required in order to get advantages of #2 approach on that.

          4)
          Create some kind of visual data model where will be stored current states for the selection/grouping/filtering etc. for each column and provide api for work with these functionality.

          some api draft usage samples and benefits?

          In general, currently I'm vote for #1.

          • 2. Re: Richfaces 4.0 dataTables models implementation discussio
            Nick Belaevski Master

             

            "ilya_shaikovsky" wrote:
            Has some additional questions about #2:

            2) In general can't get the advantages of VisualModel class. Why it's better than just simple maps which can hold the states as currently? If the user will have to define such bindings why he should learn some additional class?


            That's a right question, compare javax.swing.SortOrder and org.richfaces.model.SortOrder. Classes are named the same but have almost different representation. So why the developer should learn some additional class?

            "ilya_shaikovsky" wrote:
            3)
            + There is now need for the user to implement custom data models, he could use standard JSF dataModels.

            This is available in current default implementation also. And seems complex example required in order to get advantages of #2 approach on that.

            Is Seam booking complex enough?



            • 3. Re: Richfaces 4.0 dataTables models implementation discussio
              Ilya Shaikovsky Master

               


              That's a right question, compare javax.swing.SortOrder and org.richfaces.model.SortOrder. Classes are named the same but have almost different representation. So why the developer should learn some additional class?

              Sorry but still not clear why we should add VisualModel to this this list of predefined model classes.
              Is Seam booking complex enough?

              I'm asking about a sample of second approach in comparison with the first one. I'm not sure that could clearly get the whole idea picture. And the statement "second approach allows to use standard jsf models" is true for current approach also in default impl.

              • 4. Re: Richfaces 4.0 dataTables models implementation discussio
                Nick Belaevski Master

                 

                "ilya_shaikovsky" wrote:

                That's a right question, compare javax.swing.SortOrder and org.richfaces.model.SortOrder. Classes are named the same but have almost different representation. So why the developer should learn some additional class?

                Sorry but still not clear why we should add VisualModel to this this list of predefined model classes.

                I don't think that usage of Map/Lists is more representative than a special class for this case.

                "ilya_shaikovsky" wrote:
                Is Seam booking complex enough?

                I'm asking about a sample of second approach in comparison with the first one. I'm not sure that could clearly get the whole idea picture. And the statement "second approach allows to use standard jsf models" is true for current approach also in default impl.

                I don't have example of this right now.

                • 5. Re: Richfaces 4.0 dataTables models implementation discussio
                  Nick Belaevski Master

                  For this code:

                  @ManagedBean(name="sampleBean")
                  @SessionScoped
                  public class SampleBean {
                  
                   private List <FooObject> fooData;
                  
                   private VisualModel visualModel;
                  
                  
                   public sortListener(SortEvent event) {
                   String direction = visualMoldel.getSortDirection();
                   // do fooData sorting
                   }
                  }
                  sortListener(SortEvent) is not necessary.
                  fooData is a list built according to data contained visualModel

                  • 6. Re: Richfaces 4.0 dataTables models implementation discussio
                    Alexander Smirnov Master

                    The initial idea of the visual model was created to divide visual representation and data in the component, to allow developer reuse the same data in different components. The use-case is:
                    1) data model represents database or other source content only, but has no relation with component state.Therefore developer can use same model with different components. It could be two or more components on the same page or couple of page instances opened in different windows.
                    2) visual model represents component state only ( column sizes, selected rows, sort order, filters, whatever else ) that defines component representation. It could be internal object created by component or user bean binded by EL to component attribute.
                    3) These models should be desined close to existed UI technologies, like Swing, to let developer to use existing skills with different technologies, either from Java GUI to JSF or in the back direction.
                    The most complicated thing is data loading optimization, because it requires interaction between visual and data model to propagate current page range, sorting or filtering expressions to the data model. It could be done by listeners or some kind of binding between data model and visual model.
                    I also suggest to revise current features and put seldom use-cases from component implementation to custom models.

                    • 7. Re: Richfaces 4.0 dataTables models implementation discussio
                      Nick Belaevski Master

                      I've drawn my vision in UML editor, please take a look:

                       

                      data_models.png

                       

                      Message was edited by: Nick Belaevski

                      • 9. Re: Richfaces 4.0 dataTables models implementation discussio
                        Jay Balunas Master

                        Awesome I will take a look and we can discuss in tomorrows meeting!

                        • 10. Re: Richfaces 4.0 dataTables models implementation discussio
                          Nick Belaevski Master

                          I've added methods and attributes for rich:datascroller, please take a look at new diagram:

                          • 11. Re: Richfaces 4.0 dataTables models implementation discussio
                            Jay Balunas Master

                            OK - finally got around to this and read the article that Alex pointed to on the Presentation Model http://martinfowler.com/eaaDev/PresentationModel.html which seems similar.

                            So one question from above that has not been addressed is the necessity of default classes and settings. I want to make sure we do not require users to implement visual model classes to get default behaviors. How would this be addressed?

                            That being said I think it makes a lot of sense to separate UI data and the actual source data. For many reasons that I think most of us know. Especially when you start talking about shifting/removing columns, filters, etc....

                            In this design how would users sync current view data and source data when the user wants to commit updates? I'm assuming they would need to capture that action and sync manaully ( not saying this is bad ).

                            What is the current state of this discussion?

                            Have you guys moved forward with this visual model? Is there any small example I can view?

                            • 12. Re: Richfaces 4.0 dataTables models implementation discussio
                              Nick Belaevski Master

                               

                              "jbalunas@redhat.com" wrote:
                              So one question from above that has not been addressed is the necessity of default classes and settings. I want to make sure we do not require users to implement visual model classes to get default behaviors. How would this be addressed?

                              Component either pulls visual model classes from user bean (that's not a necessary step, user will have to create and potentially implement visual model classes) or pushes it into user's view bean. Contract is just the same as for "binding" attribute.

                              "jbalunas@redhat.com" wrote:
                              That being said I think it makes a lot of sense to separate UI data and the actual source data. For many reasons that I think most of us know. Especially when you start talking about shifting/removing columns, filters, etc....

                              This example requires additional page code just to give model a clue which column has been sorted or filtered. Visual model classes should represent this information in a developer-friendly way.

                              "jbalunas@redhat.com" wrote:
                              In this design how would users sync current view data and source data when the user wants to commit updates? I'm assuming they would need to capture that action and sync manaully ( not saying this is bad ).

                              Iteration components require data twice per postback request and once per initial request. So, ViewBean#getDataModel() method bound via EL-expression to "value" attribute will be called. In this case, ViewBean should be able to create criteria or query according to visual state taken from visual model injected into the bean and pass back already filtered/sorted/paged subset of data. Page code that will be required for the user to inject this:
                              <r:dataTable value="#{viewBean.dataModel}" visualModel="#{viewBean.visualModel}" />
                              - there should be an attribute containing ModelsAggregator in ViewBean.

                              Note that if we implement built into component in-memory handling for data (sorting etc.) we will need some way to distinguish processed vs not processed data (maybe two attributes for "value"?).
                              For data scroller, I'd suggest to to solve the problem by special SequenceDataModel class - there's getter for rows count passed as constructor arguments and preload() method which actually requests paged subset from the model. One more aspect of paged models is that they are dependent on actual state of data, not only some state stored before. Example: if there is no data for 5th page in model, empty list should be used on postback, but the last (e.g. 3rd page) for rendering.
                              Also I think we should keep paging logic in component, and not in view bean, otherwise we will need it to update visual model when paging is used.

                              "jbalunas@redhat.com" wrote:
                              What is the current state of this discussion?

                              Have you guys moved forward with this visual model? Is there any small example I can view?

                              No, there's no example code for now.

                              • 13. Re: Richfaces 4.0 dataTables models implementation discussio
                                Anton Belevich Novice

                                 


                                Note that if we implement built into component in-memory handling for data (sorting etc.) we will need some way to distinguish processed vs not processed data (maybe two attributes for "value"?).


                                Sorry seems I didn't understand. Why we should implement two attributes for the "value"?

                                • 14. Re: Richfaces 4.0 dataTables models implementation discussio
                                  Nick Belaevski Master

                                   

                                  "abelevich" wrote:

                                  Note that if we implement built into component in-memory handling for data (sorting etc.) we will need some way to distinguish processed vs not processed data (maybe two attributes for "value"?).


                                  Sorry seems I didn't understand. Why we should implement two attributes for the "value"?

                                  "value" - component does in-memory processing, "processedValue" - subset of data prepared according to rules from visual model.

                                  1 2 Previous Next