myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Marinschek" <martin.marinsc...@gmail.com>
Subject Re: [TRINIDAD] Oddness in org.apache.myfaces.trinidadinternal.application.StateManagerImpl
Date Sun, 29 Jul 2007 10:34:45 GMT
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 <awiner@gmail.com> 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 <martin.marinschek@gmail.com> 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 <awiner@gmail.com> 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 <martin.marinschek@gmail.com> 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 <awiner@gmail.com> wrote:
> > > > > On 7/26/07, Scott O'Bryan <darkarena@gmail.com> 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 <awiner@gmail.com> 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 <darkarena@gmail.com> 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

Mime
View raw message