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.
>>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
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
