You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@myfaces.apache.org by Scott O'Bryan <da...@gmail.com> on 2007/07/26 21:41:53 UTC

[TRINIDAD] Oddness in org.apache.myfaces.trinidadinternal.application.StateManagerImpl

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

Re: [TRINIDAD] Oddness in org.apache.myfaces.trinidadinternal.application.StateManagerImpl

Posted by Scott O'Bryan <da...@gmail.com>.

I'll write up a JIRA ticket on this.

On 7/30/07, Martin Marinschek <ma...@gmail.com> wrote:
>
> Yes, Trinidad is fine - just use ViewHandler.createViewRoot()
>
> regards,
>
> Martin
>
> On 7/30/07, Adam Winer <aw...@gmail.com> 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 <ma...@gmail.com> 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 <aw...@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 <ma...@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 <aw...@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 <ma...@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 <aw...@gmail.com> wrote:
> > > > > > > > On 7/26/07, Scott O'Bryan <da...@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 <aw...@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 <da...@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
> > >
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>

Re: [TRINIDAD] Oddness in org.apache.myfaces.trinidadinternal.application.StateManagerImpl

Posted by Martin Marinschek <ma...@gmail.com>.

Yes, Trinidad is fine - just use ViewHandler.createViewRoot()

regards,

Martin

On 7/30/07, Adam Winer <aw...@gmail.com> 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 <ma...@gmail.com> 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 <aw...@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 <ma...@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 <aw...@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 <ma...@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 <aw...@gmail.com> wrote:
> > > > > > > On 7/26/07, Scott O'Bryan <da...@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 <aw...@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 <da...@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
> >
>


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: [TRINIDAD] Oddness in org.apache.myfaces.trinidadinternal.application.StateManagerImpl

Posted by Scott O'Bryan <da...@gmail.com>.

Sorry, createView. 

Scott O'Bryan wrote:
> I'll check, but I think using createViewRoot will be sufficient.
>
> Scott
>
> Adam Winer 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 <ma...@gmail.com> 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 <aw...@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 <ma...@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 <aw...@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 <ma...@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 <aw...@gmail.com> wrote:
>>>>>>>            
>>>>>>>> On 7/26/07, Scott O'Bryan <da...@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 <aw...@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 <da...@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
>>>
>>>     
>>
>>   
>
>