[jira] [Commented] (MYFACES-3660) Component resource added using @ResourceDependency annotation from a facelet component should have an id defined by facelets

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

    [ https://issues.apache.org/jira/browse/MYFACES-3660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511010#comment-13511010 ] 

Leonardo Uribe commented on MYFACES-3660:
-----------------------------------------

Committed solution for this problem, waiting for review and confirmation to close this one. It include these changes:

- When a component subtree is passed under binding property:

<h:panelGrid columns="1" binding="#{page.uiComponent}"/>

The node is marked to be saved and restored fully

- The uniqueIdCounter used in UIViewRoot.createUniqueId() is saved and restored before call vdl.buildView() avoiding repeat the same number each time the view is built. This ensures components that are added/removed by a programatical manipulation to be unique, but note UniqueIdVendor interface do a better job in this part to reduce . 

- When @ResourceDependency component is added and this is done under facelets control, use an unique special id, since these components does not have state but depends on the view structure to be generated, and they are recalculated each time the view is built.
                
> Component resource added using @ResourceDependency annotation from a facelet component should have an id defined by facelets
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: MYFACES-3660
>                 URL: https://issues.apache.org/jira/browse/MYFACES-3660
>             Project: MyFaces Core
>          Issue Type: Bug
>          Components: JSR-314
>            Reporter: Leonardo Uribe
>            Assignee: Leonardo Uribe
>
> A problem related to @ResourceDependency has been mentioned on:
> http://stackoverflow.com/questions/13526624/duplicate-id-error-with-partial-state-saving-and-myfaces-codi
> CODI add a component called WindowContextIdHolderComponent in ResponseWriter.startDocument(), and later a UIViewRoot.createUniqueId() call is done when getClientId() is called from the code that checks for duplicate ids. 
> The problem is the code that process @ResourceDependency annotations in ApplicationImpl object let UIViewRoot.addComponentResource() internals to call createUniqueId(). In the example proposed, there is a dynamic block that changes the resources added at an specific moment of time, and since by PSS saving algorithm, restore view phase calls buildView() before restore the initial state, the count of uniqueIdCounter in UIViewRoot is never restored, and there is a chance that the same id of the one assigned to WindowContextIdHolderComponent can be set to a component resource added by @ResourceDependency effect.
> The problem of how generate ids is well known and has been studied for a long time. A general solution for facelets was committed in MYFACES-3329, and has worked well so far.
> In few words, we need to generate predictable component ids to make PSS algorithm reliable, otherwise it will be problems related to state saving that are very difficult to track down and solve. In the other hand, PSS algorithm impose some restrictions over the view that conflicts with dynamic manipulations of the component tree.
> I think the solution for this one is ensure all components created inside facelets vdl.buildView has unique ids, doing some changes over UIViewRoot.createUniqueId and changing @ResourceDependency processing in ApplicationImpl, so if facelets is processing the current view use FaceletCompositionContext.generateUniqueComponentId() to set an Id. Since @ResourceDependency depends on the component tree structure, the ids will now contains the information related to the tree structure itself (in the generated id), preventing duplicates.
> In theory, if we can ensure that all components generated by facelets has a component id defined by facelets algorithm, createUniqueId will be let to components added programatically, so we can do some hack to restore the uniqueIdCounter for UIViewRoot on restore view phase before call vdl.buildView, and simulate the same behavior we had in JSF 1.2, without the side effects over the state and performance.
> I think solutions using a HashMap using duplicates or random generators are out of discussion, because they will not ensure the predictability we need to get correct operation of PSS algorithm.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira