cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] InputModules for sitemap variables
Date Wed, 29 May 2002 13:26:17 GMT
Christian Haul wrote:

>On 28.May.2002 -- 04:01 PM, Christian Haul wrote:
>>On 27.May.2002 -- 10:32 AM, Christian Haul wrote:
>>>On 26.May.2002 -- 01:35 PM, Sylvain Wallez wrote:
>>>>Christian Haul wrote:
>>>>>On 24.May.2002 -- 04:00 PM, Sylvain Wallez wrote:
>>>>>>Chris, what about passing the full object model instead of just the

>>>>>>Request to {Input, Output}Modules ? This would allow a wider range
>>>Almost done. It causes some larger modifications to the new
>>>DatabaseActions since they cannot inherit the central setColumn method
>>OK, I'm done. Modules now use objectModel instead of the request
>>object. Necessary changes to actions / matchers that currently use
>>modules are finished.

Great !

>>Now someone more knowledgeable of the sitemap variables'
>>implementation can tackle the suggestion. :-)
>>To followup on Nicola Ken's comment, we could have a sitemap: pseudo
>>protocol for variables as we know them now and a module: pseudo
>>protocol for input modules. 
>Should have been
> Like
> <map:generate src="{sitemap:1}"/> 
> <!-- sitemap variable named "1" -->
> <map:generate src="{module:request-param:name}"/> 
> <!-- value obtained from input module "request-param" for an attribute named "name"
> <map:generate src="file.xml"/> 
> <!-- value "file.xml" -->
> <map:generate src="{cocoon://file.xml}"/> 
> <!-- value obtained from other pipeline -->
> <map:generate src="cocoon://file.xml"/> 
> <!-- value "cocoon://file.xml" -->
>	Chris.

Sorry for the delay : this subject is of great interest to me but I had 
some more-than-urgent work.

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)
- you mix InputModules and Sources, which I consider, as I previously 
said, different beasts.

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.

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.

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
   3. {module://parameter} : more URL-ish, but IMO leads to a confusion
      with sources, which I would like to avoid.

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

 <map:generate src="{1}"/> 
 <!-- sitemap variable named "1" -->
 <map:generate src="{/request-param:name}"/> 
 <!-- value obtained from input module "request-param" for an attribute named "name" -->
 <map:generate src="file.xml"/> 
 <!-- value "file.xml" -->
 <map:generate src="{source:cocoon://file.xml}"/> 
 <!-- value obtained from other pipeline : the "source" module fetches the
      text node of a single-element document -->
 <map:generate src="cocoon://file.xml"/> 
 <!-- value "cocoon://file.xml" -->

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 ?

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


Sylvain Wallez
 Anyware Technologies                  Apache Cocoon 

To unsubscribe, e-mail:
For additional commands, email:

View raw message