Christian Haul wrote:
>On 28.May.2002 -- 04:01 PM, Christian Haul wrote:
>
>>On 27.May.2002 -- 10:32 AM, Christian Haul wrote:
>>
>>>On 26.May.2002 -- 01:35 PM, Sylvain Wallez wrote:
>>>
>>>>Christian Haul wrote:
>>>>
>>>>>On 24.May.2002 -- 04:00 PM, Sylvain Wallez wrote:
>>>>>
>>>>>>Chris, what about passing the full object model instead of just the
>>>>>>Request to {Input, Output}Modules ? This would allow a wider range of
>>>>>>implementations.
>>>>>>
>>>Almost done. It causes some larger modifications to the new
>>>DatabaseActions since they cannot inherit the central setColumn method
>>>anymore.
>>>
>>OK, I'm done. Modules now use objectModel instead of the request
>>object. Necessary changes to actions / matchers that currently use
>>modules are finished.
>>
Great !
>>Now someone more knowledgeable of the sitemap variables'
>>implementation can tackle the suggestion. :-)
>>
>>To followup on Nicola Ken's comment, we could have a sitemap: pseudo
>>protocol for variables as we know them now and a module: pseudo
>>protocol for input modules.
>>
>
>Should have been
>
> Like
>
> <map:generate src="{sitemap:1}"/>
> <!-- sitemap variable named "1" -->
>
> <map:generate src="{module:request-param:name}"/>
> <!-- value obtained from input module "request-param" for an attribute named "name"
>-->
>
> <map:generate src="file.xml"/>
> <!-- value "file.xml" -->
>
> <map:generate src="{cocoon://file.xml}"/>
> <!-- value obtained from other pipeline -->
>
> <map:generate src="cocoon://file.xml"/>
> <!-- value "cocoon://file.xml" -->
>
> Chris.
>
Sorry for the delay : this subject is of great interest to me but I had
some more-than-urgent work.
I think you're going too far, for two reasons :
- you introduce heavy back-incompatibility issues by requiring all
variables to be prefixed (i.e. the "sitemap" prefix)
- you mix InputModules and Sources, which I consider, as I previously
said, different beasts.
My opinion is that protocol-based variable substitution should be
restricted to *InputModules only*, as what we want to substitute is a
single character string, and not a data-stream produced by a Source.
Sure, we can imagine a Source that produces a single element whose child
text node can be used to substitute the variable. But for this (IMO
rather rare) case, we could write a SourceInputModule.
We also have to define a syntax that distinguishes "classical" sitemap
variables from module-defined variables that is both readable and
reduces the likelyness of backward-incompatibilities.
I see several possibilities :
1. {module:parameter} : prefix parameter name by the module name.
Very simple, but the more likely to lead to imcompatibilities.
2. {/module:parameter} : same as above, but attach module-defined
variables to the root of the variable tree. Unlikely to lead to
imcompatibilities because the "/" is already used to travel up the
hierarchy.
3. {module://parameter} : more URL-ish, but IMO leads to a confusion
with sources, which I would like to avoid.
My personal preference goes to (2), which would change your examples to :
<map:generate src="{1}"/>
<!-- sitemap variable named "1" -->
<map:generate src="{/request-param:name}"/>
<!-- value obtained from input module "request-param" for an attribute named "name"
-->
<map:generate src="file.xml"/>
<!-- value "file.xml" -->
<map:generate src="{source:cocoon://file.xml}"/>
<!-- value obtained from other pipeline : the "source" module fetches the
text node of a single-element document -->
<map:generate src="cocoon://file.xml"/>
<!-- value "cocoon://file.xml" -->
As for sitemap parameters currently under discussion, their could be identified either
as non-prefixed root variables, i.e. "{/skin}", or by a "sitemap" pseudo-module, i.e.
"{/sitemap:skin}".
What do you think ?
I also volunteer to implement this (I should have some time for it starting at the end
of next week).
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]
