From: "Sylvain Wallez" <[EMAIL PROTECTED]>
> 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.
>
> Here are the various syntaxes that people have proposed so far :
>
> 1 : {request:foo}
> 2 : {/request:foo}
> 3 : {module:request:foo}
> 4 : {/module:request:foo}
> 5 : {module://request/foo}
6 : (all below apply, similarly to urls; prefer for consistency)
{foo} (default sitemap module )
{pathto/foo} (default sitemap module with path)
{module:request://pathto/foo} (complete parameter uri)
> 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.
+1
> 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}".
+1
Basically I want them to behave like urls do.
--
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]
