Conal Tuohy wrote:
>Stefano wrote:
>
>
>> <matcher type="M1">
>> <matcher type="M2">
>> <act type="A1">
>> <act type="A2">
>> <read src="{A2.a}/{A1.b}/{M1.c}/{M2.d}/{request:param}"/>
>> </act>
>> </act>
>> </matcher>
>> </matcher>
>>
>>where the only problem is the nesting of two components of
>>the same type
>>(but I don't really see a need for this and I would think
>>it's a design
>>mistake of the component if you need to do it!)
>>
>>
>
>Yes it probably is a design mistake ... but what about referring to the
>component by name, rather than type?
>
>
Oops, sorry Conal, I answered Stefano's post without reading yours,
which is really close to what I'm proposing.
>Someone else suggested xpath, and there was some discussion that some xpath
>expressions would cause problems with nested sitemaps, but an xpath like
>"id('foo')" would not have this problem. Or, if not xpath, a simpler naming
>scheme could be used like:
>
> <matcher type="M1" id="some-meaningful-label">
> <matcher type="M2" id="another-meaningful-label">
> <act type="A1" id="another-label">
> <act type="A2" id="whatever">
> <read
>src="{#some-meaningful-label/a}/{#another-meaningful-label/b}/{#another-labe
>l/c}/{#whatever.d}/{request:param}"/>
> </act>
> </act>
> </matcher>
> </matcher>
>
>OK maybe my labels are too long ;-) but it is at least an absolutely clear
>way to refer to the variable, which doesn't involve counting the number of /
>characters. Plus it has the advantage of helping to document the use of each
>component in the pipeline.
>
>Just my 2c (and that's 2 NZ cents BTW - just a bit less than 1 US cent)
>
Money doesn't count in opensource projects :-)
Your proposal based on IDs implies that the name of a statement has to
be unique in the sitemap (as a regular ID in an XML file). IMO, this is
too restrictive as we may want to use the same name in different
branches of the sitemap.
Now we also have to think about overloading. Consider this :
<map:match pattern="*" name="foo">
<map:act type="my-action" name="foo">
<map:generate type="serverpages" src="{foo:1}.xsp"/>
</map:act>
</map:match>
Where does {foo:1} come from ? I would say that if a statement has the
same name as an enclosing statement, then variables defined by this
enclosing statement are *totally hidden*. Some people talked about
inheritance, but IMO this will lead to ambiguities and erratic
behaviours that will be difficult to understand.
So in the above example, 'foo:1' comes from the action, and if '1' isn't
defined by the action, then it's value is null, even if the matcher has
a value for '1'.
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]
