myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Winer" <awi...@gmail.com>
Subject Re: [Trinidad] Large difference in generated ID between UIXComponentBase and UIComponentBase
Date Thu, 06 Sep 2007 05:18:24 GMT
On 9/5/07, Andrew Robinson <andrew.rw.robinson@gmail.com> 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 <andrew.rw.robinson@gmail.com> 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 <andrew.rw.robinson@gmail.com> 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?
> > >
> >
>

Mime
View raw message