On Sun, 2008-03-30 at 20:04 +0200, Werner Punz wrote:
> Mario Ivankovits schrieb:
> > Hi!
> >> Weblets for instance allows a zeroconf resource loading
> >> via phase listeners which trigger, usually this triggering
> >> is done before phase1, but there are portlet cases where
> >> it happens later.
> > What are the JSF phases executed by weblets then? Probably we find a
> > pattern which allows us to decide if it was a resource serving.
> > 
> Hi Mario
> Weblets usually triggers before the Restore View Phase for non portlet 
> cases and otherwise before the apply request values phase for portlets.
> There also is a trigger for before render Response to trigger as early
> as possible for other cases which even suppress those phases.
> 
> (This seems a little bit unecessry to me probably the last one checking 
> the before render response is needed only I have to recheck that)
> It simply means trigger asap before even doing any jsf related word.
> 
> What you probably could do is to ignore requests in your garbage 
> collection of the page context, which trigger the lifecycle but do not 
> go through the phase properly, aka terminate early, that way you 
> probably could cover at least 95% of all use cases.

Werner, Orchestra already does ignore requests that "terminate early".

All the orchestra cleanup of access-scoped conversations is handled by a
phase listener that runs only in post-render. That's enough to work
correctly with Tomahawk PPR requests for example; they use a pre-render
phase-listener that stops the lifecycle at that point, meaning that no
access conversations get discarded.

If weblets doesn't run the post-render phase, then Orchestra will have
no problems with it either.

The problem with richfaces is that it appears from the original post
that it runs a completely normal JSF lifecycle, including all the
post-render phase listeners when rendering its custom resources (the
".xcss" file in this case).

I wonder what "viewId" it uses when processing the stylesheet request.
Does the server see a request for viewId "foo.jsf", then suddenly a
request for viewId "foo.xcss", then later the postback for "foo.jsf"
again? I presume so; seems odd to me though. Wouldn't that stuff up a
number of different backbutton/breadcrumb type systems? And what about
things like Spring WebFlow that have a strict state-machine of allowed
navigation flows?


Regards,
Simon

Reply via email to