[jira] [Resolved] (MYFACES-3502) components inside f:metadata are recreated when the whole view is processed

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

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

Leonardo Uribe resolved MYFACES-3502.
-------------------------------------

       Resolution: Fixed
    Fix Version/s: 2.1.7
                   2.0.13
    
> components inside f:metadata are recreated when the whole view is processed
> ---------------------------------------------------------------------------
>
>                 Key: MYFACES-3502
>                 URL: https://issues.apache.org/jira/browse/MYFACES-3502
>             Project: MyFaces Core
>          Issue Type: Bug
>          Components: JSR-314
>    Affects Versions: 2.0.12, 2.1.6
>            Reporter: Leonardo Uribe
>            Assignee: Leonardo Uribe
>             Fix For: 2.0.13, 2.1.7
>
>
> There is a subtle but important when f:metadata sections are processed. Between the view metadata is created and the whole view is built, facelets algorithm discard and recreate all components. In typical situations this effect is not visible, because there is a description spec code that hide this effect. See UIViewParameter.setSubmittedValue() javadoc:
> "... PENDING (docs) Interesting that submitted value isn't saved by the parent ..."
> The discussion comes from issue:
> MYFACES-2645 The view state is saved before encodeAll() is called on every UIViewParameter in an AJAX request
> In that time, I commented the following:
> LU>> The javadocs of UIViewParameter.encodeAll says this:
> LU>> ".......Called specially by UIViewRoot.encodeEnd(javax.faces.context.FacesContext), this method simply sets the submitted value to be the return from 
> LU>> getStringValue(javax.faces.context.FacesContext)......"
> LU>> My question is why? isn't that bad? 
> In that time, the discussion was related to how to preserve the view params in ajax request. The argument was submittedValue is set to null on process validations, and it is necessary a way to preserve that value into the state. 
> The solution in that issue is valid, but what happen when validation fails? submittedValue should not change, so why its value is lost before encodeAll() is processed?. 
> By performance reasons, two different facelets are used for a view: one for create metadata that just process stuff inside <f:metadata> and the other for build the whole view (including metadata too). Since there are two different facelets, generated in different way, the associated tagId is different and then the generated ComponentSupport.MARK_CREATED identifier is different too. Then, when the whole view is processed, facelets cannot identify the component as the same, so it is removed and created again, and in the process submittedValue and localValue are discarded, looking as if they are set to null. 
> The solution is ensure facelets generate the same unique ids in ComponentSupport.MARK_CREATED when f:metadata is processed, no matter if the metadata facelet or the normal facelet process the view. CompilationManager.nextTagId() uses the alias and a counter to derive an unique tag id, so it will obviously generate different tags, so the idea is ignore that part of the unique id when f:metadata section is processed, and fix DefaultFaceletContext.generateUniqueId(), so it generate the same id.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira