[jira] [Resolved] (MYFACES-3811) Fix c:forEach behavior once for all

["Leonardo Uribe (JIRA)" <de...@myfaces.apache.org>]

     [ https://issues.apache.org/jira/browse/MYFACES-3811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Leonardo Uribe resolved MYFACES-3811.
-------------------------------------

       Resolution: Fixed
    Fix Version/s: 2.2.0
         Assignee: Leonardo Uribe

This was really, really, really hard to fix. It is clear the relationship between the generated ids and the values that c:forEach traverse in the collection. The most difficult part is keep the state consistent, so I add a junit test in the acid test, which runs under all state saving configurations. Some methods were added to FaceletCompositionContext to handle the special way required to generate the ids and keep the generation consistent.

The nice thing is now it will be possible to make combinations of c:forEach and other dynamic tags like ui:include src="#{...}" or c:if and keep the state consistent and PSS algorithm working well.

I added the old algorithm as org.apache.myfaces.STRICT_JSF_2_FACELETS_COMPATIBILITY too.

> Fix c:forEach behavior once for all
> -----------------------------------
>
>                 Key: MYFACES-3811
>                 URL: https://issues.apache.org/jira/browse/MYFACES-3811
>             Project: MyFaces Core
>          Issue Type: Task
>          Components: JSR-344
>            Reporter: Leonardo Uribe
>            Assignee: Leonardo Uribe
>             Fix For: 2.2.0
>
>
> It is well known c:forEach tag is broken, and that it is advised to users to avoid this tag or at least ensure the collection that iterates this component to be static over the application lifetime. 
> But users keep trying over and over to use this tag, perceiving this behavior as a bug. See:
> - MYFACES-3570
> - MYFACES-3389
> - MYFACES-3329
> A lot of important fixes has been done in MyFaces code, and with the introduction of 2.2.x, we can finally try to fix this problem once for all.
> The challenge for this issue is we need to save the iteration data (only if the data is Serializable or StateHolder) into the component state and synchronize this with the generated ids, so if a new element is added or an existing one is removed, we keep the state and the id generation consistent. 
> Now we have the environment set to do the job: an stable id generation algorithm, a well understood algorithm for PSS and we are in the process to get a release of 2.2 branch.



--
This message was sent by Atlassian JIRA
(v6.1#6144)