From: "Sylvain Wallez" <[EMAIL PROTECTED]>
> 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.
> >
+1
> 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:
http:
ftp:
file:
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)
or
{parameter://request.module/pathto/foo} (complete parameter uri)
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
