This will not work in cases where a renderkit may override the UIViewRoot
(like Trinidad). Even if decorating occurs, 301 tries to implement
namespacing by making it's UIViewRoot implement a naming container.
Something which the decorators are probably NOT going to do...
Either way, I think you answered my question. I remember us discussing this
in the EG and we basically said that if the base faces UIViewRoot is
obtained then we would wrap it in a naming container version of the class.
But if we are using a custom UIViewRoot, then it is up to that
implementation to handle namespacing.. So in short I think we can keep this
optimization in so long as we enhance Trinidad's UIViewRoot to support a
naming container OR handle namespacing via another mechanism.
This had a lot of discussion in 301 and it was our only real alternative.
That said, I'm hoping namespacing is something that can be added to JSF 2.0.
Scott
On 7/26/07, Adam Winer <[EMAIL PROTECTED]> wrote:
This code is part of a major optimization for state saving;
it's just as pertinent in 1.2 as it was in 1.1.
It can be disabled with the CACHE_VIEW_ROOT flag.
However, disabling it should be a last resort. How does
the bridge swap in a custom UIViewRoot implementation
if *not* by registering a subclass of UIViewRoot on the application
(which can be done declaratively in META-INF/faces-config.xml)?
-- Adam
On 7/26/07, Scott O'Bryan <[EMAIL PROTECTED]> wrote:
> Hey guys,
>
> There is some oddness that I'm seeing in Trinidad which is going to
> cause some issues with the 301 implementation and I'm trying to
> understand the problem so that I can figure out whether we need to go
> another route with 301 or what.. Here is the code I'm looking at:
>
> public UIViewRoot popRoot(FacesContext fc)
> {
> UIViewRoot root = null;
> Object viewRootState = null;
> // we need to synchronize because we are mutating _root
> // which is shared between simultaneous requests from the same
user:
> synchronized(this)
> {
> if (_root != null)
> {
> root = _root;
> viewRootState = _viewRootState;
> // we must clear the cached viewRoot. This is because
> UIComponent trees
> // are mutable and if the back button
> // is used to come back to an old PageState, then it would be
> // really bad if we reused that component tree:
> _root = null;
> _viewRootState = null;
> }
> }
>
> if (root != null)
> {
> // If an error happens during updateModel, JSF 1.1 does not
> // clear FacesEvents (or FacesMessages, IIRC), so any pending
> // events will still be present, on the subsequent request.
> // so to clear the events, we create a new UIViewRoot.
> // must get the UIViewRoot from the application so that
> // we pick up any custom ViewRoot defined in faces-config.xml:
> 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;
> }
>
> return null;
> }
> }
>
> The part that is going to cause an issue is where root != null. The
> reason for this is that in the portal environemnt we use a custom
> UIViewRoot that implements a naming container. Therefore, doing this
> call gives us the original UIViewRoot as opposed to the bridge's
> UIViewRoot. The comment seems to indicate that this was added for JSF
> 1.1, so is this needed in the 1.2 branch? If so, when would this case
> occur and is there anyway to not have to do this?
>
> Thanks,
> Scott O'Bryan
>
