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
[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]
