simon schrieb:
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?

Not sure if this is really orchestras problem, best guess probably is to contact Sergeij from Exadel if this is a richfaces bug.

Cheers

Werner

Reply via email to