I have the same feeling here. Filter are flexible. Specially for making processing like authencitation
I would like to say that microsling is very simple to understand as it is. I like the combinaison of the different serlvets & filters. Cool & great job. On 10/17/07, Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > > 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] >
