Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
Received-SPF: pass (athena.apache.org: domain of martin.marinschek@gmail.com
 designates 209.85.132.250 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=tgoQrgqKU2ut5QeFziY4YHAqA3aLLvqOQ6cX3DIB+nHyuNA67m1vlkDvSTK66z2k2lpZhbAowFjRpNX7UE/8oM+YvN8RCePK5OvBro5F3+eRUlZMtnna1ubhD5OrUesAY91e4Xi4CBODHqhc71of2ds4pb5cQC9g8YC4SJ3BmLM=
Message-ID: <5a99335f0707290334t4ca3bd39gb6189f741b612e6d@mail.gmail.com>
Date: Sun, 29 Jul 2007 12:34:45 +0200
From: "Martin Marinschek" <martin.marinschek@gmail.com>
To: "MyFaces Development" <dev@myfaces.apache.org>
Subject: Re: [TRINIDAD] Oddness in
 org.apache.myfaces.trinidadinternal.application.StateManagerImpl
In-Reply-To: <6dac79b90707281109o78b2c801m39fcd2f4f146d2cb@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <46A8F901.4070108@gmail.com>
	 <6dac79b90707261346k3ac139e6t19b7eb5f68a399ae@mail.gmail.com>
	 <323d8a020707261917s27b7aba0sf9f9aed6fd4b60c3@mail.gmail.com>
	 <6dac79b90707262217m236cdb4bg16886aaf6a95920b@mail.gmail.com>
	 <5a99335f0707270009s7c4182feoae2827eff23693d5@mail.gmail.com>
	 <6dac79b90707270912l69f9107fnb2a8a5f042497d81@mail.gmail.com>
	 <5a99335f0707272314x4fae5692l4beca6b71c442708@mail.gmail.com>
	 <6dac79b90707281109o78b2c801m39fcd2f4f146d2cb@mail.gmail.com>

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