cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Haul <h...@dvs1.informatik.tu-darmstadt.de>
Subject Re: [RT]: Unifying input modules and global parameters
Date Thu, 27 Jun 2002 14:25:11 GMT
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
haul@informatik.tu-darmstadt.de
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message