Hi Lars,
Sounds simple and usefull.
Just one question: What is the difference betwen the Request filter and
the Response filter ?
And a clarification the script must/may wrap the request and response
objects to inject new data, or do you think that only parameters would
be "overwritten" ?
Regards
Felix
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
> [EMAIL PROTECTED]
> http://weblogs.goshaky.com/weblogs/lars
>
