Details

    • Type: Sub-task Sub-task
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.2
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Status Whiteboard:
      Hide

      size_medium importance_small

      Show
      size_medium importance_small

      Description

      UIRepeat and UIData do pretty much the same: iterate over a collection of items. There should be a common base class for this, encapsulating the complicated logic for saving/restoring and iterating the state of the "rows". Something like "UIIterate".

      Writing iterating components is very complicated at the moment. This base class should be easy to extend and also support any kind of data structures, not only "lists". Using an integer for the "row" iterating index is insufficient for creating "tree" components. A string or kind of indexing object would be much more flexible.

      UIRepeat and UIData could extend this class and provide the existing interface on top of it.

        Activity

        Hide
        Manfred Riem added a comment -

        Setting priority to Major

        Show
        Manfred Riem added a comment - Setting priority to Major
        Hide
        Ed Burns added a comment -

        Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

        Show
        Ed Burns added a comment - Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.
        Hide
        arjan tijms added a comment -

        I think is a very important issue. In general UIData seems to be more robust than UIRepeat, but they indeed do pretty much the same thing and when inspecting the code it also looks like they had similar implementations at one time and/or borrowed from each other.

        If there was a common implementation bugs such as JAVASERVERFACES-3215 would probably not have been there.

        It would also prevent issues like JAVASERVERFACES_SPEC_PUBLIC-1103. In that case UIData got a new feature that UIRepeat would have needed just as well, but because of the time between JSF releases now has to wait for this for a rather long time.

        Show
        arjan tijms added a comment - I think is a very important issue. In general UIData seems to be more robust than UIRepeat , but they indeed do pretty much the same thing and when inspecting the code it also looks like they had similar implementations at one time and/or borrowed from each other. If there was a common implementation bugs such as JAVASERVERFACES-3215 would probably not have been there. It would also prevent issues like JAVASERVERFACES_SPEC_PUBLIC-1103 . In that case UIData got a new feature that UIRepeat would have needed just as well, but because of the time between JSF releases now has to wait for this for a rather long time.
        Hide
        Ed Burns added a comment -

        I thought we had an issue for this, but yes, it's a good idea.

        Show
        Ed Burns added a comment - I thought we had an issue for this, but yes, it's a good idea.
        Hide
        Mathias Werlitz added a comment - - edited

        Well the essential difference between UIData(<h:dataTable>) and UIRepeat is how the iteration is done during render response.
        UIRepeat iterates in the component and HtmlDataTable iterates in the renderer. This flexibility should be possible. Iterating in the renderer can be easier for "tree" components.

        I could imagine a structure like this:

        UINamingContainer
        |
        UIIterate
        |
        |- UISequentialIterate
        | |
        | |- UIData
        | |- UIRepeat
        |
        |- UITree?

        At least there should be an marking interface for such components because state saving seems to be different when nesting of iterating components is possible. For example UIRepeat already checks for UIData or UIRepeat parents. UIData does only look for itself as a parent.

        Show
        Mathias Werlitz added a comment - - edited Well the essential difference between UIData(<h:dataTable>) and UIRepeat is how the iteration is done during render response. UIRepeat iterates in the component and HtmlDataTable iterates in the renderer. This flexibility should be possible. Iterating in the renderer can be easier for "tree" components. I could imagine a structure like this: UINamingContainer | UIIterate | |- UISequentialIterate | | | |- UIData | |- UIRepeat | |- UITree? At least there should be an marking interface for such components because state saving seems to be different when nesting of iterating components is possible. For example UIRepeat already checks for UIData or UIRepeat parents. UIData does only look for itself as a parent.

          People

          • Assignee:
            Unassigned
            Reporter:
            Mathias Werlitz
          • Votes:
            4 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated: