On 2/17/06, Laurie Harper <[EMAIL PROTECTED]> wrote:
Werner Punz wrote:
> Laurie Harper schrieb:
>> I have a need for similar functionality to the Tomahawk Extensions
>> filter, and have been thinking about ways to achieve it without
>> requiring user config. I was hoping I could find a standard JSF hook
>> that I could plug into through a faces-config entry but haven't come up
>> with anything viable yet. So I thought I'd ask the obvious question:
>>
>> Is the extensions filter the only viable approach? If not, what are the
>> other options and the reasons they were rejected in favour of the filter?
>>
>> It seems to be a somewhat common problem that people either don't
>> install the filter or don't get it configured correctly, so I'm guessing
>> if there were a better way, the Tomahawk components would be using it...
>> If it's simply the case that no-one's invested the time to implement a
>> configuration-free alternative, and someone can describe what's
>> involved, I'll be happy to contribute an implementation :-)
>>
>> L.
>>
>>
> Actually no, the filter is not the only viable approach, you could
> replace the filter with a phase listener. I personally have the same
> problems as you have with the servlet filter approach, it works, but it
> is too problematic for the end users.
>
> But in the end I thing all JSF projects should consolidate on a common
> resource loading mechanism. John Fallows has an interesting project,
> Weblets, that one is a common resource format, with its own resource
> loading mechanism for every framework there is.
>
> For JSF he uses a phase listener (which is a snap in without user
> config) and a ViewHandler (which can be moved into a tools class, I
> talked those things over with him, the ViewHandler was only used to
> achieve API similarity to JSF)

Interesting. I was under the impression that Weblets did not and would
not support the 'add <script> elements to the document head' part of the
equation. I'll have to have another look at it.

I think that is true for weblets, and it is definitely true for Shale Remoting.  What remoting offers is a helper class that computes the calculate the appropriate resource URL for you to render.  Actually adding the <script> element (or call addResource() in the case of Tomahawk) is still your responsibility.

L.


Craig

Reply via email to