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.
Great.
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.
/Daniel
