I'll write up a JIRA ticket on this.
On 7/30/07, Martin Marinschek <[EMAIL PROTECTED]> wrote:
>
> Yes, Trinidad is fine - just use ViewHandler.createViewRoot()
>
> regards,
>
> Martin
>
> On 7/30/07, Adam Winer <[EMAIL PROTECTED]> wrote:
> > OK, yes, but Trinidad *does not need an alternative ViewRoot*.
> > So, what should Trinidad be doing when it creates a UIViewRoot?
> >
> > -- Adam
> >
> >
> > On 7/29/07, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> > > 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
> > >
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
