myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott O'Bryan <darkar...@gmail.com>
Subject Re: [TRINIDAD] Oddness in org.apache.myfaces.trinidadinternal.application.StateManagerImpl
Date Mon, 30 Jul 2007 17:46:05 GMT
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 <martin.marinschek@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 <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