-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add rowStatePreserved property to UIRepeat, exactly the same as UIData #1263
Comments
@glassfishrobot Commented |
@glassfishrobot Commented |
@glassfishrobot Commented |
@glassfishrobot Commented |
@glassfishrobot Commented |
|
@arjantijms @BalusC WDYT about this? im currently working on a PF bug: primefaces/primefaces#10047 the problem is that ui:repeat doesnt have rowStatePreserved like UIData |
@BalusC are you ok with this? would like to start adding it to MF then |
Sure. I however still want to extract a base class based on common logic of UIData and UIRepeat (UIIterable?) so we don't need to copy paste logic and it's also useful for e.g. PrimeFaces DataTable/Repeat, but I imagine this is a bit more of work. |
yep, a base class would be the best i will start right now to add rowStatePreserved to ui:repeat in MF |
@BalusC |
added rowStatePreserved to ui:repeat for now |
Do you have a link to MF commit for reference? |
I had reused a lot of methods from our UIData class, so it would be good to create a superclass to avoid duplication in 5.0. |
We should indeed really look at some common superclass and preferably also move UIRepeat into the jakarta.faces.component API as earlier suggested by @mnriem . As to the concrete issue, this can also be solved/workarounded by simply using c:forEach instead of ui:repeat. This is less trivial for h:dataTable (you'd need to write all the HTML table markup yourself), hence the rowStatePreserved makes more sense over there in h:dataTable. |
eclipse-ee4j/mojarra#2247 contains a useful use case / reproducer that could be used as tck. |
a helper class so UIRepeat can also utilize them jakartaee/faces#1263
yeah sure |
getter/setter as UIRepeat is going to be moved into API of Faces.next jakartaee/faces#1263
This is the implementation work for #1230, but it can be done outside of the spec because properties can be added to Facelet backed components without having to change the TLD.
The text was updated successfully, but these errors were encountered: