<snip/>
> So what about allowing <map:components> to be written <map:components > src="sitemap.xconf"/> ? Well, I am +0 for this one... but I guess Stefano convinced me. Shouldn't this happen as a block configuration? Something like this: <cocoon-block> <sitemap src="sitemap.xmap"/> <components src="sitemap.xconf"/> <roles src="sitemap.roles"/> </cocoon-block> > This way, each [sub-]sitemap (or cocoon block) comes with a sitemap.xmap > and an optional sitemap.xconf defininig its local components, if any. this was already proposed in the xconf thread but IIRC it was shot down... > The current behaviour should also be kept, for compatibility and for > people which aren't confused by having components in the sitemap. sure thing... > Now the question is do we define system-wide sitemap components in > cocoon.xconf ? If yes, they should be IMO restricted to the very minimum > of what we're likely to find in _every_ sitemap, i.e. wildcard and > regexp matchers, file and xsp generators, xsl transformer, xml and html > serializers. > > Note also that some system-level components may make use of some sitemap > components. Namely, the xml serializer used in some source > implementations, IIRC. true... > >So, SoC or not, is the above really what we want? I think, no! > > > >Hmm, currently I'm thinking of voting -1 for defining the components > >in the xconf. This would create a deadlock. Very interesting > >and funny thing... > > > Does sitemap-local xconf remove the lock ? it would from my side... but maybe Stefano would give a -1 then ;) -- Torsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
