Mailing-List: contact users-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Discussion" <users@myfaces.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Message-Id: <48521CC1-CBD6-4C9F-96E0-60E43A01BA4C@winterstein-web.de>
From: Bernd Winterstein <bernd@winterstein-web.de>
To: "MyFaces Discussion" <users@myfaces.apache.org>
In-Reply-To: <1206709877.6529.15.camel@simon-laptop>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Re: orchestra conversation closed by stylesheet
Date: Fri, 28 Mar 2008 19:45:54 +0100
References: <4AC0EA1B-E0C8-463C-896E-D6E117A4A816@winterstein-web.de>
 <1206709877.6529.15.camel@simon-laptop>

Hi Simon,
many thanks for your tips. I checked the phase-listener solution, but  
it's a little dirty.
The resource request skips phases 2-5. And the after RESTORE_VIEW  
callback is not called.
In the before callback I do not know how to get the view id. As a  
solution i check the source component of the phase event.
If it starts with org.ajax4jsf.resource.ResourceLifecycle I tell  
orchestra to ignore the request.

It's not beautiful but it seems to work.

Bernd


Am 28.03.2008 um 14:11 schrieb simon:
> Hi Bernd,
>
> On Fri, 2008-03-28 at 12:11 +0100, Bernd Winterstein wrote:
>> Hi
>> I have a one page conversation with access-scope. The page contains
>> several tabs which are switched by Ajax calls.
>> The first time the page is loaded the last request is a css download,
>> upon which orchestra closes the conversation. The following requests
>> for other tabs works perfect, the conversations stays open.
>>
>>
>> Mrz 28 11:37:21 DEBUG
>> org
>> .apache.myfaces.orchestra.conversation.jsf.AccessScopePhaseListener
>> invalidateAccessScopedConversations     Clearing access-scoped
>> conversation contactSearchController after rendering view /pages/
>> doctor_details.jsp
>> <-- THIS IS OKAY(old page)
>>
>> Mrz 28 11:37:21 DEBUG
>> org
>> .apache.myfaces.orchestra.conversation.jsf.AccessScopePhaseListener
>> invalidateAccessScopedConversations     Not clearing accessed
>> conversation doctorDetailsController after rendering view /pages/
>> doctor_details.jsp
>> <-- THIS IS OKAY(NEW PAGE, CONVERSATION  SHOULD STAY OPEN)
>>
>>
>> Mrz 28 11:37:21 DEBUG
>> org
>> .apache.myfaces.orchestra.conversation.jsf.AccessScopePhaseListener
>> invalidateAccessScopedConversations     Clearing access-scoped
>> conversation doctorDetailsController after rendering view /org/
>> richfaces/renderkit/html/css/basic_classes.xcss
>> <-- THIS IS WHAT I DON'T understand
>
> You appear to have the suffix ".xcss" mapped to the FacesServlet, ie
> that full facelets lifecycle (including phase listeners) is being run
> when serving up that css file.
>
> That's not usual; normally a css is a static resource, and is not  
> served by the FacesServlet. Therefore the jsf phase-listeners do not  
> run and this will not occur. I suppose it's some odd RichFaces  
> feature that requires a JSF lifecycle to serve a css file.
>
> Orchestra's AccessScopeManagerConfiguration class can be configured  
> in spring to ignore specific view names:
>
>    <bean
>         
> name 
> = 
> "org 
> .apache 
> .myfaces.orchestra.conversation.AccessScopeManagerConfiguration"
>         
> class 
> = 
> "org 
> .apache 
> .myfaces.orchestra.conversation.AccessScopeManagerConfiguration"
>        scope="singleton">
>   ... define set of views to ignore here ...
>    </bean>
>
> However currently this supports only fixed view names, not patterns  
> like "*.xcss", so this doesn't help in your case.
>
> The AccessScopePhaseListener does also ignore requests, however, if
>  AccessScopeManager.getInstance().setIgnoreRequest()
> has been called. So I suggest that you add a phase-listener which  
> just checks the current view-id, and if it ends with ".xcss" then  
> set the ignoreRequest state on the AccessScopeManager. Note that  
> this is just a request-scoped object, so there is no need to "reset"  
> the state.
>
> Regards,
> Simon
>
>
> See file spring-orchestra-init.xml within the orchestra jar for some  
> further details.
>
> The AccessScopePhaseLinstener.
>
> Hmm..
> So for now, you probably need to subclass the AccessScopeManager  
> class itself,
>
>