Sylvain Wallez wrote:
> 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 ;)
Actually, I have enough of a hard time following my life's change flows
:/
> 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).
All right.
> >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.
Ok, great. That clears my concerns.
> >>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.
Agreed, you get my vote for {request:foo}, KISS!
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
