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) enough?
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?
Vadim
