Just so that people don't have to search: it's a bug in Facelets fixed
in the latest version 1.1.13.
regards,
Martin
On 9/6/07, Andrew Robinson <[EMAIL PROTECTED]> wrote:
> FYI, I started a new thread entitled "Major bug in facelets 1.1.11
> with mark and sweep code?" that is on the facelets user list and CC'd
> on this list as a result of my findings from this thread.
>
> -Andrew
>
> On 9/5/07, Adam Winer <[EMAIL PROTECTED]> wrote:
> > On 9/5/07, Andrew Robinson <[EMAIL PROTECTED]> wrote:
> > > Okay, I could really use some help, and I am confused on the Trinidad
> > > code and how it is supposed to work.
> > >
> > > I stepped through the code on a PPR partial submit restore view. And
> > > the code that starts to seem fishy is the
> > > "StateManagerImpl$PageState.popRoot(FacesContext)" function.
> > >
> > > Code as follows:
> > > UIViewRoot newRoot = (UIViewRoot)
> > > fc.getApplication().createComponent(UIViewRoot.COMPONENT_TYPE);
> > >
> > > // must call restoreState so that we setup attributes, listeners,
> > > // uniqueIds, etc ...
> > > newRoot.restoreState(fc, viewRootState);
> > >
> > > // we need to use a temp list because as a side effect of
> > > // adding a child to a UIComponent, that child is removed from
> > > // the parent UIComponent. So the following will break:
> > > // newRoot.getChildren().addAll(root.getChildren());
> > > // because "root"'s child List is being mutated as the List
> > > // is traversed.
> > > List<UIComponent> temp = new
> > > ArrayList<UIComponent>(root.getChildCount());
> > > temp.addAll(root.getChildren());
> > > newRoot.getChildren().addAll(temp);
> > > return newRoot;
> > >
> > > As you can see, the state of the new UIViewRoot is restored, then the
> > > children are added to the view root before this function returns, but
> > > neither the restoreState nor the processRestoreState functions are
> > > ever called on the children.
> >
> > This is the CACHE_VIEW_ROOT optimization. BTW, this
> > optimization *has* been tested with Facelets, though not
> > intensively with especially recent versions.
> >
> > > As a result the view is never restored fully. That is where I am
> > > getting the problem.
> >
> > No, it should be fully restored - all the children from the prior
> > request should still be there.
> >
> > >
> > > My configuration:
> > >
> > > Facelets 1.1.11
> > > Trinidad 1.0.3-SNAPSHOT
> > > Seam 1.2.1
> > > MyFaces 1.1.5
> > >
> > > View root: the one Trinidad installs
> > > ALTERNATE_VIEW_HANDLER: my own custom view handler that extends
> > > SeamFaceletViewHandler which in tern extends FaceletViewHandler.
> > >
> > > State saving method is client.
> > >
> > > Using *.jsf view mapping with .xhtml file suffixes.
> > >
> > > Trinidad's USE_APPLICATION_VIEW_CACHE parameter set to false.
> > >
> > > setting the facelets BUILD_BEFORE_RESTORE parameter to true actually
> > > "fixes" the error, but that is simply because the simple view I am in
> > > really has no "real" state to store. But even with this set, the
> > > children of UIViewRoot never have their state restored.
> > >
> > > My custom view handler creates my on view root that extends
> > > UIViewRoot, but I don't touch any of the state methods.
> > >
> > > Looking in the client HTML, it gets a bit fishy as well. This is what I
> > > found:
> > >
> > > <span id="_mainForm_Postscript">
> > > <input type="hidden" value="!-1f9a06ef"
> > > name="org.apache.myfaces.trinidad.faces.STATE"/>
> > >
> > > That value seems incredible small for a view state.
> >
> > That's because its a token. Not the full state.
> >
> > > I have tried server side state saving and have gotten the same result.
> > > The code that seems very wrong in terms of it shouldn't be executed
> > > ins in StateManagerImpl.java:
> > >
> > > UIViewRoot root = viewState.popRoot(context); // bug 4712492
> > > if (root != null)
> > > {
> > > _LOG.finer("UIViewRoot for token {0} already exists. Bypassing
> > > restoreState", token);
> > > return root;
> > > }
> > >
> > > This always is true on my PPR requests and seems to be the cause of
> > > the state never being restored.
> >
> > It's actually a really valuable optimization, especially for PPR.
> >
> > -- Adam
> >
> > > While in debug mode, if I force the root to be null, then everything
> > > works. I really don't know for sure, but the above code seems to
> > > completely break the restoring of the view state with the
> > > configuration I have.
> > >
> > > On 9/5/07, Andrew Robinson <[EMAIL PROTECTED]> wrote:
> > > > TreeState.saveState(FacesContext, UIXComponentBase) is being called, but
> > > >
> > > > TreeState.restoreState(FacesContext, UIXComponentBase) is never called.
> > > >
> > > > I'll have to look into this to see if it is something I caused or not.
> > > > Does Trinidad depend on a custom UIViewRoot implementation (I have my
> > > > own and a custom view handler that are worth looking into as the
> > > > source of the issue)?
> > > >
> > > > On 9/5/07, Andrew Robinson <[EMAIL PROTECTED]> wrote:
> > > > > It works fine outside of the facet,
> > > > >
> > > > > Broken:
> > > > >
> > > > > <tr:panelLabelAndMessage
> > > > > label="Test help">
> > > > > <tr:inputText id="testHelp" value="#{testHelpText}"
> > > > > simple="true" />
> > > > > <f:facet name="end">
> > > > > <cw:helpIcon for="testHelp"
> > > > > messageId="test_help" />
> > > > > </f:facet>
> > > > > </tr:panelLabelAndMessage>
> > > > >
> > > > > Works:
> > > > >
> > > > > <tr:panelLabelAndMessage
> > > > > label="Test help">
> > > > > <tr:inputText id="testHelp" value="#{testHelpText}"
> > > > > simple="true" />
> > > > > </tr:panelLabelAndMessage>
> > > > > <cw:helpIcon for="testHelp"
> > > > > messageId="test_help" />
> > > > >
> > > > > Looks like a possible bug in the state saving of facets or at least in
> > > > > the panelLabelAndMessage. Any ideas?
> > > > >
> > > >
> > >
> >
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
