Stefano Mazzocchi wrote:
> Hmmm, after restating that I hate actions and I hate nested actions
> even more because of {../../../1} let me state that I would hate them
> *even* more if we go the Torsend's {///1} way.
>
> Sylvain proposed the {[1]1} path and don't know about you, but that
> made me puking all over the floor.
Beeeark ! Honestly, I'm not really happy with this, and this was mainly
to show that we must find alternatives to "/" for navigating forward in
this list.
> (Sorry, Sylvain, nice try and your logic about tree vs. list is right,
> but look at the result: that would make Perl look readable!)
Interesting side-effect ! I should be rewarded for this ;-)
> Ilya proposed a form of namespacing, but Carsten noted that would
> collide with sitemap variable expansion of InputModules since
> {foo:bar} might end up colliding with an input module "foo" expanding
> variable "bar".
>
> If you think about it, Sylvain is proposing the exact same thing, but
> only inferring the namespace prefix from nested positioning. So, we
> might be doing
>
> {1.1}
>
> where the first position is inferred from the component nesting and
> the second one is inferred from the position of the expansion token. Yuck!
>
> Ilya is proposing to namespace them a little more explicitly and I see
> value in this approach even if it ads a little verbosity (which, many
> times, is a good thing)
>
> So, we could be doing implicit
>
> {type.attribute}
>
> namespaceing like in
>
> <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!)
This can often happen with matchers when e.g. an area of the application
is protected :
<map:match type="wildcard" pattern="admin/*">
<map:act type="auth">
<map:match type="wildcard" pattern="admin/adduser">
...
</map:match>
</map:act>
</map:match>
So explicit naming as proposed by Ilya finally seems the best approach
to me, as it removes all possible ambiguities at the price of a little
added verbosity. Since this added verbosity only happens when this
feature is used, this actually does no harm.
Let's see now how we can write that...
> Anyway, I agree that
>
> {type.attribute}
>
> and
>
> {request:param}
>
> are a little too similar to be really evident.
>
> Hmmm, let's see other potential syntaxes:
>
> {type[attribute]}
>
> which recalls vector indexing
>
> {attribute@type}
>
> which recalls email addressing (but uses inverted notation and could
> be even worse)
>
> {(type)attribute}
>
> which recalls lisp-like functional syntaxes
>
> {type?attribute)
>
> which recalls URL-encoding
>
> {type^attribute}
>
> which might recall a higher link between the two (or a pow() equivalent)
>
> Anyway, let's see what you think about this.
Puke, puke, puke ;-))
You're trying to find an alternative to the ':' which is used to
separate the prefix from the attribute name, because you make the
assumption that what's before the ':' *is* an inputmodule name.
But isn't it precisely this prefix (i.e. the namespace) that should be
used to distinguish between inputmodules and sitemap variables ? If yes
(and I think so), this means we have to find a naming convention for the
prefix, and not for the separator.
You may puke (if you still can ;-), but what about considering
sitemap-defined namespaces as internal to the sitemap, and thus prefix
them with a "#", that we all know as being used for internal links in
web pages ?
This would lead to (adapted from Ilya's proposal) :
<map:match pattern="*-*" name="mtch1">
<map:act type="my-action" name="act1">
<map:generate type="serverpages" src="{#mtch:1}.xsp">
<map:parameter name="display" value="{#mtch:2}"/>
<map:parameter name="param1" value="{#act1:1}"/>
<map:parameter name="param2" value="{#act1:2}"/>
<map:parameter name="param3" value="{request:1}"/>
<map:parameter name="param4" value="{1}"/>
</map:generate>
</map:act>
</map:match>
Explanation :
- {#mtch1:xxx} come from statement named "mtch1"
- {#act1:xxx} come from statement named "act1"
- {request:xxx} come from input-module "request"
- {xxx} works as usual and gets its value from the enclosing statement.
I changed "param-prefix" proposed by Ilya to "name" since this is
actually what it is : a name given to a sitemap statement.
Thoughts ?
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]
