On Friday 11 October 2002 00:28, 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.
both make me puke - in terms of syntax...
> (Sorry, Sylvain, nice try and your logic about tree vs. list is right,
> but look at the result: that would make Perl look readable!)
hm... let me guess - you hate perl ? ;)
> 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".
...as well as I did ;)
> 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)
...well, we could name the levels and make the sitemap check for level
name clashes. so the original list
List {
1. Map{1,2}
2. Map{a}
3. Map{a,b}
}
would become
List {
1. "firstmatcher" - Map{1,2}
2. "firstaction" - Map{a}
3. "otheraction" - Map{a,b}
}
So the clashes are
1. pretty obvious
2. easy to resolve
So we could either name the levels or use there level count if there is none.
<matcher type="M1" level="firstmatcher">
<act type="A1" level="firstaction">
<act type="A2" level="otheraction">
<read src="{firstmatcher.1}/{firstaction.a}/{3.b}/{request:param}"/>
</act>
</act>
</matcher>
<snip/>
> 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!)
I totally disaggree here!! SoC is also valid for actions (we know you hate
actions ;) ...so seperating functionallity into different - even nested -
actions does make sense!
> 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.
...as I said: it's hard to come up with a new syntax that is not yet used
somewhere else :)
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
