On 27.Jun.2002 -- 02:40 PM, Sylvain Wallez wrote: > Carsten Ziegeler wrote: > >Currently, the global parameters are declared in the > >map:pipelines section of a sitemap and the scope > >is the map:pipeline sections.
I don't like this. Because it is yet another concept with overlaps with other concepts. IMHO it boils down to the variable discussion which was rejected because sitemap is no programming language. > >- global parameters are not inherited/available to > > sub-sitemaps > > I'm not sure if it's good for them to be automatically inherited. I > suggested to add <map:parameters> to <map:mount> to achieve a behaviour > similar to <xsl:param> (see > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102267914817420&w=2) While I don't like global parameters, having parameters for mount makes sense because I believe a mount differs not much from a call. OTOH with the advent of flowscripts, deprecating calls or at least parameters for it might be sensible. Since in all other cases parameters are used by the construct immediately preceeding the parameter, the principle of least surprise would suggest that parameters to "call" and "mount" are used by "call" and "mount" respectively and not made available later on. > >Advantage: > >- Configuration directly in the sitemap > > > >The input modules are completly defined in the cocoon.xconf, > >they can be used inside every sitemap by first choosing > >the input module and then the key, like {request:parametername}. > > > >Advantage: > >- Simple use > >- Single configured values are available in all sitemaps > > > >Disadvantage: > >- Configuration is not in the sitemap, but in the cocoon.xconf I don't really see a need why any component should be configured in sitemap.xmap at all -- if we had a way to break up the global configuration file into small chunks. Thus I'm in favour of removing all the actions, matchers, and selectors from sitemap.xmap. Not for adding another category to it. > >Proposed Solution > >Make one input module sitemap configurable, like the > >authentication manager. This means a (global) input module is > >defined in the cocoon.xconf, but can be additionally configured > >in the sitemap. > >A subsitemap inherits this configuration from it's parent sitemap > >and can add own key/value pairs, so this would look like this: Again, I don't like it. And even if we are in alpha, we shouldn't introduce features we will regret later because the installed base relies on them so we cannot remove them again. > Also, a few days ago, you have forbidden someone to add additional > components in <map:components>, but since it _does_ work (only with the > TreeProcessor, just like InputModules), wouldn't it be simpler to add > <input-modules> in <map:components> to locally redefine/augment the set > of input modules defined in cocoon.xconf ? Note that allowing this would > be a first step towards a separate xconf per sitemap, and then cocoon > blocks. And even though I pointed out that it is possible I did it only because I mistakenly thought map:components was an advertised feature. No, let's wait for a consensus for blocks and see if it would help us here. Chris. -- C h r i s t i a n H a u l [EMAIL PROTECTED] fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
