cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [2.2] New processor interface/approach
Date Wed, 12 Jul 2006 09:35:21 GMT
Carsten Ziegeler skrev:
> Sylvain Wallez wrote:
>> However, a few remarks:
>> - how is Processor different from Servlet?
> The interface is similar. The difference is configuration and who
> manages the component. If a processor is a component we can use all nice
> features of spring for that and I think the configuration is nicer.
> Things like changing the configuration at runtime should be easier as
> well as you don't have to modify the web.xml.
Servlet is just an interface, no one prevents you from managing a 
component that implements Servlet in Spring. And as you rather often is 
going to need a Servlet context or configuration within a Processor, you 
end up pretty close to Servlet anyway.

The advantage to use the Servlet interface is that we give the users 
greater flexibility in reusing the various controllers that we might 

But as said before, we can evaluate the consequences when you have 
implemented a little bit more. It shouldn't be much work to change to 
Servlet, if that is a better idea.

>> - SitemapProcessorFactory is pretty close to
>> ServletContext.getRequestDipatcher()
> No, not exactly. The dispatcher is based in the request uri where as the
> sitemap process factory gives you a processor for a sitemap specified by
> the sitemap location which might be totally different to the incomming uri.
Don't think this is the best way to do it. The current 
MountTableProcessor means that you only can mount SitemapProcessor and 
no other kinds of controllers, as it explicitly manage the creation of 
the SitemapProcessors. IMO it is better to let the component container 
(Spring) create the SitemapProcessor (and other processors), then the 
MountTableProcessor instead contains an association between uri prefixes 
and component ids. And this makes it usable together with any processor 
as its not the concern of the MountTableProcessor to create the 
processor anymore.

Also it makes the path to the sitemap for a specific SitemapProcessor a 
concern for the configuration of the SietmapProcessor rather than the 
configuration of the MountTableProcessor. Much better SoC IMO.


View raw message