cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: The real Processor concerns
Date Wed, 12 Oct 2005 20:13:36 GMT
Carsten Ziegeler wrote:
> Vadim Gritsenko wrote:
>>>>Maybe I miss the point completly as I haven't followed this thread in detail,

>>>>but aren't block properties (declared in block.xml and set in wiring.xml)
>>>Yes, gosh, you're right - the only question is, do we want to go this
>>>way and do this incompatible changes (means: removing the sitemap
>>>component configurations from the sitemap)?
>>But block properties are per block, while sitemap variables (and 
>>SitemapConfigurable interface) are per-sitemap.
>>So you could do implement some of this feature using block properties, but it's 
>>not really compatible and it won't replace SitemapConfigurable interface...
> Yeah, true as well - so I guess we just leave it the way it is - it
> works, why changing it? Just to get a cleaner interface? Hmm, don't
> think so.

Interface could be a bit cleaner, but what about implementation? It is a bit 
messy ATM. So I'm Ok with dropping this interface - it will allow to cleanup a 
bit of code (CocoonServiceManager/SitemapVariableHolder), but we need to 
implement functionality provided by <global-variables> and GlobalInputModule - 
any ideas about compatible replacement?

One compatible way could be to create SitemapConfigurationHolder component, and 
declare it in every sitemap which has configurations. For this to work, 
SitemapConfigurationHolder will need access to parent component manager in order 
to lookup parent SitemapConfigurationHolder, so that it can build a chain of 
configurations. GlobalInputModule can then simply lookup 
SitemapConfigurationHolder and ask for chained global-variables config.

So, do you know of a way how SitemapConfigurationHolder can get to a parent 
SitemapConfigurationHolder instance?


View raw message