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 12:30:48 GMT
Carsten Ziegeler skrev:
> Daniel Fagerstrom wrote:
>> 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.
> Ah, yes, you're right of course. I forgot to mention that I wanted to
> change the
> MountTableProcessor later on to exactly provide that feature.

>> 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.
> Yes, true - unfortunately the configuration gets a little bit
> complicated as you then have to add each and every sitemap processor as
> a bean in spring instead of using a generic approach.
Are you using so many sitemap processors so that becomes a problem? We 
have something like that today. The tree processor is configured as a 
component, or will a Spring bean configuration be much more verbose?

Irrespectively of if the bean configuration becomes verbose or not, it 
will help us towards better modularization. Each block, or rather each 
sample block, can contribute its sitemap as a sitemap processor that is 
configured in its bean configuration. In this way we get rid of the 
sitemap copying part of the deployer.


View raw message