cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [VOTE] Syntax for module-based sitemap variables
Date Thu, 30 May 2002 14:42:16 GMT
Stefano Mazzocchi wrote:

>Sylvain Wallez wrote:
>>Hi team,
>>We all agree to add module-based sitemap variables, but we didn't came
>>to a consensus about it's syntax. So let's vote to make a choice. To
>>illustrate each possible syntax, I will consider the substitution of the
>>"foo" request parameter using the "request" InputModule.
>Sorry if the question has been answered previously, but where is this
>"InputModule" defined?

What, aren't you up to date with the Cocoon source base ??? Don't worry, 
I also have some problems to follow the CVS logs ;)

Anyway, look at org.apache.cocoon.components.modules.input in HEAD, you 
will find there the InputModule interface and several implementation. 
Basically, a module is a component that gives access to simple data 
elements (compared to sources which give access to large streams of data).

>I'm worrying about possible namespacing issues with future cocoon

I'm not sure there are some issues : this is used only for sitemap 
variable resolution, i.e. inside the "{}" syntax, and not the syntax of 
URLs, which is where AFAIK blocks will appear.

>>Here are the various syntaxes that people have proposed so far :
>>1 : {request:foo}
>>2 : {/request:foo}
>between these I prefer #1. #2 seems to imply that the trailing path has
>an effect on the use.

This was a syntactic hack proposal to avoid name clashes in the 
hypothetic case where a sitemap variable has a colon in its name. But 
this is actually solved either by forbidding it as you suggest, or by 
using the builtin "sitemap" module.

>>3 : {module:request:foo}
>>4 : {/module:request:foo}
>>5 : {module://request/foo}
>what is a 'module' in this sense?

'module' is there to denote that the information comes from a module 
(implementation of InputModule). I personally don't like it as it shows 
in the syntax some implementation details that IMO should not be there : 
what is important in this example is that we get the value of the "foo" 
request parameter and not that it is obtained by an InputModule.

>between #3 and #4, the same consideration above apply. #5 is even worse:
>it seems to imply an entirely new protocol and might conflict with
>cocoon blocks in the future.
>>My +1 goes to (1) : I don't see the need to explicitly specify
>>"module:", just as we don't prefix URLs with "source:" or "url:" to
>>specify if they should be handled by a SourceFactory or URLFactory. And
>>if one day we add another mechanism to InputModules, the choice will be
>>the job of a variable resolver, just at it is today's job of the
>>SourceResolver for URLs.
>>In order to have a more formal definition of sitemap variables, I
>>suggest that we consider unprefixed variables to belong to a builtin
>>"sitemap" module, which can be named explicitely, for example if the
>>variable name contains a colon, e.g. "{sitemap:foo:bar}".
>Much easier: force variable names *not* to contain a colon. It works for
>XML elements and people using XML stuff are used to the notion of colon
>as a namespaced prefixed declaration.

That's exactly why I proposed to use a colon, as we widely use this for 
both URL schemes and XML namespace prefixes.


Sylvain Wallez
  Anyware Technologies                  Apache Cocoon 

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

View raw message