Felix Meschberger wrote: > Hi all, > > Currently, we love using filtering in both Sling and microsling: Every > part of request processing is implemented using a filter. This was not > always the case: In the days when Sling was still private, there was no > filtering at all. > > Probably we must come to a mix of both: There are some tasks, which have > to be executed all the times and there are some tasks which may or may > not be executed. Examples of the former are authentication, proper error > handling, resource resolution and servlet/script resolution. Examples of > the latter are locale resolution, default setting of the response > content type etc. > > So, for microsling, I propose to not implement resource resolution as a > filter, in fact leaving default response content type setting the only > filtering task (currently). > > For Sling I propose to not implement filtering for authentication > (replace AuthenticationFilter by a service called directly), > errorhandler (replace ErrorHandlerFilter), contentresolution (replace > ContentResolverFilter) and component resolution (replace > ComponentResolver). These tasks are always executed in the listed order > by the Sling request processor. After the component is resolved the > registered filters are called and finally the component itself is > called. > > WDYT ? > Hmm, filters have the great advantage being very flexible. You can combine them in any order, make them optional etc. On the other hand I agree that some things are required for sling to work, so a filter doesn't seem quiet right.
I agree for resource and content resolution. But I'm not sure about authentication. Having a filter which does the authentication is very transparent. If we are using the servlet filter interface for these filters, its easy to use other authentication mechanisms like for example spring authentication (aka acegi) which is based on servlet filters as well. So for now, I personally tend to go with filters except where something is really required for Sling core to work. There we could use an explicit service instead. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
