On 2/16/06, Laurie Harper <[EMAIL PROTECTED]> wrote:
Craig McClanahan wrote:
> On 2/16/06, Cagatay Civici <[EMAIL PROTECTED]> wrote:
>> Hi Laurie,
>>
>> It seems a phaselistener is what you are looking for, it is pluggable and
>> does not require any user configuration.
>
> One thing you can do in a filter that you cannot in a phase listener is wrap
> the response object, so that you can intercept the output and modify it.
> ExtensionsFilter does this so it can postprocess and insert the resource
> tags.
>
> The closest you could come in a phase listener would be to interject a
> ResponseWriter that buffered up the output -- then, after Render Response
> complete, goes in and does the same sort of injection followed by writing
> the modified response out to the real client.  That should work, as long as
> *all* of the output were done via ResponseWriter.  I suspect that will be
> true if you are using something like Facelets or Clay, but likely *not* to
> be true if you are using JSP pages.

Yep, that's exactly the problem. Weblets, Shale Remoting and a few other
options exist for actually serving static content from a jar; the
problem is inserting the references to that content (scripts and CSS for
the most part).

The 'buffering response writer' idea was one of the things I looked at
but I didn't see an easy way to inject one. Sounds like that wouldn't
work portably in any case, though.

This part of the problem, at least, is pretty easy to deal with :-).  Call FacesContext.setResponseWriter() -- perhaps after calling getResponseWriter() to save the original one, if any -- in a "before render response" phase listener, and do the inject-and-copy trick in the corresponding "after render response" listener.

Shale Remoting plays this sort of game to deal with asynchronous AJAX callbacks.

Maybe this is something worth raising in the JSF WG, though I imagine
it's a bit late in the development of the 1.2 spec to get something like
this in there.

L.

Craig

Reply via email to