Re: Scriptable Filters

[Lars Trieloff <la...@trieloff.net>]

Indeed, this looks good.

On 29.12.2007, at 20:59, Felix Meschberger wrote:

> Hi all,
>
> Scriptable Filters may be implemented based on my recent "Everything  
> is
> a Resource" proposal. See [1]
>
> Regards
> Felix
>
> [1]
> http://cwiki.apache.org/SLING/everything-is-a-resource.html#EverythingisaResource-4.3Filters
>
> Am Freitag, den 21.12.2007, 14:49 +0100 schrieb Lars Trieloff:
>> Here is my proposal for scriptable filtering:
>>
>> == Goal ==
>> We want to allow users with limited knowledge and interest in OSGi,
>> Maven and Java to create filters in a similar fashion to creating
>> scripts for request handling.
>>
>> == Current Situation ==
>> Filters are OSGI components, implementing the Filter interface and
>> having a defined scope of either request, response or resource
>> (although I have only found examples of filter.scope=request).
>>
>> == Solution ==
>> We implement a RequestScriptFilter, ResponseScriptFilter and
>> ResourceScriptFilter class that in their doFilter method resolve a
>> filter script, execute this filter script and continue in the filter
>> chain. For each stage, only a single script is executed, script
>> authors that need more than one filter script per stage have  
>> following
>> options
>> - implementing a dispatcher script that will delegate to other filter
>> scripts
>> - subclassing the *ScriptFilter class and overriding the  
>> getSelector()
>> method, which is used in script resolution
>> - implementing a full-Sling filter using OSGi mechanisms
>> The *ScriptFilter have a default order of 0, authors who would like  
>> to
>> change this order have two options:
>> - implementing a dispatcher script that will delegate to other filter
>> scripts
>> - subclassing the *ScriptFilter class and overriding filter.order
>> property definition
>> Scripts are resolved in the following way:
>>
>> request filter scripts:
>> /filters/request[.selector].{extension} - the selector is optional if
>> the getSelector() method return null (which is the default), the
>> extension is determined by the ScriptFactory, eg. js for Javascript
>> or .rb for Ruby
>>
>> response filter scripts:
>> /filters/request[.selector].{extension} - as above
>>
>> resource filter scripts:
>> /filters/{sling/nodetype}/filter[.selector].{extension} - selector  
>> and
>> extension as above, sling/nodetype is the resolved path to the
>> matching resource type or node type.
>>
>> == Open Questions ==
>> Does it make sense to include the HTTP method in script resolution?  
>> If
>> so, how to express default filters that apply to all methods?
>>
>> regards,
>>
>> Lars
>>
>> --
>> Lars Trieloff
>> lars@trieloff.net
>> http://weblogs.goshaky.com/weblogs/lars
>>
>

--
Lars Trieloff
lars@trieloff.net
http://weblogs.goshaky.com/weblogs/lars