Hi Adam,
well, there was a long discussion on this in the EG. The problem is
that you can't tell the sequence of who is going to be called first in
ViewHandler.createView(), so we can't make sure renderView will always
delegate through to us...
So what was planned was - if you use the standard view, it will be
wrapped automatically, if a component lib needs some alternative
ViewRoot, it needs to do something for portlet-compliancy.
regards,
Martin
On 7/28/07, Adam Winer <[EMAIL PROTECTED]> wrote:
> That's where I'm not clear: calling ViewHandler.createView()
> should be enough. If you're putting any more requirements on
> developers than *either* calling ViewHandler.createView()
> or Application.createComponent(), and nothing more, then
> there's a big problem here.
>
> -- Adam
>
>
> On 7/27/07, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> > Hi Adam,
> >
> > yes, this would fix the issue - plus implementing this NamingContainer
> > stuff as soon as it is on the table what it exactly looks like.
> >
> > regards,
> >
> > Martin
> >
> > On 7/27/07, Adam Winer <[EMAIL PROTECTED]> wrote:
> > > OK, so it sounds like a simple fix here is that Trinidad should
> > > go through ViewHandler.createViewRoot() instead of the
> > > Application to create the view root?
> > >
> > > -- Adam
> > >
> > >
> > > On 7/27/07, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> > > > Hi Adam,
> > > >
> > > > the currently choosen route is to override createViewRoot() in
> > > > ViewHandler.
> > > >
> > > > In this case, the created UIViewRoot can be checked --> if it
> > > > incorporates namespace-handling, there is no need to wrap it, if it
> > > > doesn't it is wrapped by the portlet-bridge's own UIViewRoot.
> > > >
> > > > regards,
> > > >
> > > > Martin
> > > >
> > > > On 7/27/07, Adam Winer <[EMAIL PROTECTED]> wrote:
> > > > > On 7/26/07, Scott O'Bryan <[EMAIL PROTECTED]> wrote:
> > > > > > This will not work in cases where a renderkit may override the
> > > > > > UIViewRoot
> > > > > > (like Trinidad).
> > > > >
> > > > > Trinidad doesn't override the UIViewRoot.
> > > > >
> > > > > > 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...
> > > > >
> > > > > But how do you get that UIViewRoot in there? There's
> > > > > two mechanisms - override createViewRoot() in ViewHandler,
> > > > > or configure a UIViewRoot subclass on the Application...
> > > > > which do you 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
> > > > >
> > > > > Trinidad doesn't have a UIViewRoot...
> > > > >
> > > > > -- Adam
> > > > >
> > > > >
> > > > > > 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
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > http://www.irian.at
> > > >
> > > > Your JSF powerhouse -
> > > > JSF Consulting, Development and
> > > > Courses in English and German
> > > >
> > > > Professional Support for Apache MyFaces
> > > >
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
