A typical servlet filter has following structure:
- do something with the request
- call doFilter(request, response);
- do something with the response
In most of these filters only the request or the response is modified.
With the separation of request.js and response.js I eliminate the
necessity to call doFilter() which is too often forgotten and clearly
separate request and response handling.
regards,
Lars
P.S. while writing this I see that it would be useful to have
request.js and response.js also for resource-based filters. so please
imagine following line:
/filters/{sling/nodetype}/{request|response}[.selector].{extension}
On 21.12.2007, at 15:25, Felix Meschberger wrote:
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
--
Lars Trieloff
[EMAIL PROTECTED]
http://weblogs.goshaky.com/weblogs/lars
