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.
(Sorry, Sylvain, nice try and your logic about tree vs. list is right,
but look at the result: that would make Perl look readable!)
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!)
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.
--
Stefano Mazzocchi <[EMAIL PROTECTED]>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
