Issue Details (XML | Word | Printable)

Key: JAVASERVERFACES_SPEC_PUBLIC-963
Type: Sub-task Sub-task
Status: Open Open
Priority: Critical Critical
Assignee: Unassigned
Reporter: Mathias Werlitz
Votes: 4
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
javaserverfaces-spec-public
JAVASERVERFACES_SPEC_PUBLIC-935

Alignment/extending of iterating ui components

Created: 01/Apr/11 10:32 AM   Updated: 27/Mar/14 10:06 PM
Component/s: None
Affects Version/s: 2.2
Fix Version/s: None

Time Tracking:
Not Specified

Status Whiteboard:

size_medium importance_small

Tags:
Participants: arjan tijms, Ed Burns and Mathias Werlitz


 Description  « Hide

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.



Mathias Werlitz added a comment - 21/Apr/11 11:12 AM - 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.


Ed Burns added a comment - 22/Apr/11 07:55 AM

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


arjan tijms added a comment - 27/Mar/14 10:06 PM

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.