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] InputModules for sitemap variables
Date Wed, 29 May 2002 14:14:53 GMT
On 29.May.2002 -- 03:34 PM, Sylvain Wallez wrote:
> Sylvain Wallez wrote:

> >I think you're going too far, for two reasons :
> >- you introduce heavy back-incompatibility issues by requiring all 
> >variables to be prefixed (i.e. the "sitemap" prefix)

That is bad, indeed. I tried to think along the lines of Nicola's
suggestion to replace sitemap vars with URIs / URLs to make it
consistent.

> >- you mix InputModules and Sources, which I consider, as I previously 
> >said, different beasts.

Again, that was to go on with the URI idea and I agree with you on
that being different things.

> >My opinion is that protocol-based variable substitution should be 
> >restricted to *InputModules only*, as what we want to substitute is a 
> >single character string, and not a data-stream produced by a Source.

Fine with that.

> >Sure, we can imagine a Source that produces a single element whose 
> >child text node can be used to substitute the variable. But for this 
> >(IMO rather rare) case, we could write a SourceInputModule.

Agreed, too. Actually, I would see interest in the whole document
including the markup as a single value e.g. to store or attach it
somewhere.

> >We also have to define a syntax that distinguishes "classical" sitemap 
> >variables from module-defined variables that is both readable and 
> >reduces the likelyness of backward-incompatibilities.
> >
> >I see several possibilities :
> >
> >  1. {module:parameter} : prefix parameter name by the module name.
> >     Very simple, but the more likely to lead to imcompatibilities.
> >  2. {/module:parameter} : same as above, but attach module-defined
> >     variables to the root of the variable tree. Unlikely to lead to
> >     imcompatibilities because the "/" is already used to travel up the
> >     hierarchy.
> >  3. {module://parameter} : more URL-ish, but IMO leads to a confusion
> >     with sources, which I would like to avoid.

1 looks most elegant, but 2 is probably best.

> >My personal preference goes to (2), which would change your examples to :

> >As for sitemap parameters currently under discussion, their could be 
> >identified either as non-prefixed root variables, i.e. "{/skin}", or 
> >by a "sitemap" pseudo-module, i.e. "{/sitemap:skin}".
> >
> >What do you think ?

Actually, I think one *could* write an input module that holds all
constants and even looks at the request object whether that constant
should be overridden by request parameters. (Will post example in
other thread).

> >I also volunteer to implement this (I should have some time for it 
> >starting at the end of next week).

	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