Hi Lars,
Am Freitag, den 21.12.2007, 16:26 +0100 schrieb Lars Trieloff:
> A typical servlet filter has following structure:
>
> - do something with the request
> - call doFilter(request, response);
> - do something with the response
I fear this does not work.... The request object has no setters to
overwrite request internals and at the time the response filter is
called, the response may already be committed. We could solve the
request case in that the RequestScriptFilter class creates a request
wrapper allowing the script set fields to overwrite.
For the response it is somewhat more complicated, especially if there is
a lot of output, which when the response is not wrapped must be
cached ....
So using request and response wrappers is easier and more stable to
overwrite certain "data" and to modify input and output on the fly.
>
> 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
Well, the problem is, that the Filter API defines a protocol. If this
protocol is not followed, errors arise. I think, we should not try to
work around people not being able to cope with protocols :-)
> separate request and response handling.
Not sure, whether it works that easily. In fact, sometimes processing
may not even be separable for example if a filter decides based on the
request, whether the next filter is to be called or a response should be
generated and request processing terminated.
Regards
Felix
>
> 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
>
