cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <tcu...@dff.st>
Subject Re: [Announcement] sitemap variables
Date Fri, 11 Oct 2002 09:30:38 GMT
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message