cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicola Ken Barozzi" <>
Subject Re: [VOTE] Syntax for module-based sitemap variables
Date Thu, 30 May 2002 15:01:23 GMT
From: "Sylvain Wallez" <>

> 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
> >blocks.
> >
> 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.

Could you give us an example on why there will be problems with blocks?
Won't block uris start with block: ?

> >>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.

module: is a scheme.

Uris *do* tell you implementation details:

I don't see why this is a problem.

> >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.

Please read my previous posts on this thread.

I have explained that I preferred the use of a URI, for consistency.

This would imply an initial scheme (not necessarily protocol) and a path (we
do use ../../, and this is missing from what you seem to prefer).

> >>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.

I still prefer this uri syntax:

          {foo}  (default sitemap module )
          {pathto/foo}  (default sitemap module with path)
          {module:request://pathto/foo} (complete parameter uri)
          {parameter://request.module/pathto/foo} (complete parameter uri)

Nicola Ken Barozzi         
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)

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

View raw message