This has been a problem with Facelets from the start. Facelets has always built and serialized the component tree in one fell swoop. I've run into this problem a number of times when trying to add default behavior to a component tree. Of course, you have the PreRenderViewEvent, which gets called just before the rendering begins, so you have a populated tree at that point. However, any changes to the tree are not recorded by the state saving mechanism (I'd need to verify that). Perhaps what we need instead is for the state saving to recheck if the component tree state changed by a PreRenderViewEvent listener. (Of course, I think you could do this yourself in one of these listeners, but not the ideal solution). This brings up an important documentation question. At what point in the lifecycle do we recommend that the application add dynamic elements to the component tree? Some guidance would be helpful. -Dan On Mon, Nov 2, 2009 at 4:52 PM, Ryan Lubke <Ryan.Lubke(a)sun.com&gt; wrote: > Please see Mojarra-1383 [1] for background on this issue. > > Based on this, it seems we would need to remove the last bullet item in > this section that states: > > "Publish an PostAddToViewEvent with the created UIViewRoot as the event > source." > > and move the responsibility of publishing this event to > ViewDeclarationLanguage.buildView() - the > point when the view is actually populated. > > Thoughts? > > [1] https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1383 > -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://www.google.com/profiles/dan.j.allen

> ** Allows the application to modify the state of any component in the tree > just before the tree state is written out. Does that seem useful? I have never had a use-case for a callback after rendering and before saving the state. Why would that be necessary - a concrete use-case? If I create components dynamically, I make them transient, so they are not save-stated anyways - so no need to modify the state of components before save-stating.

Of course, you have the PreRenderViewEvent, which gets called just before the rendering begins, so you have a populated tree at that point. However, any changes to the tree are not recorded by the state saving mechanism (I'd need to verify that).

Based on this, it seems we would need to remove the last bullet item in this section that states: "Publish an PostAddToViewEvent with the created UIViewRoot as the event source." and move the responsibility of publishing this event to ViewDeclarationLanguage.buildView() - the point when the view is actually populated.