cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Gallardo Rivera <agalla...@agsoftware.dnsalias.com>
Subject Re: [Proposal]: Advanced Value Substitution
Date Tue, 08 Oct 2002 10:13:17 GMT
El Martes, 08 de Octubre de 2002 03:38, Carsten Ziegeler escribió:
> Sylvain Wallez wrote:
> > >So, keeping this short, I propose to change the search algorithm
> > >for value substitution:
> > >If a key is not found in the inner block, the search is continued
> > >up the chain.
> >
> > Crawling up the chain can be very expensive !
>
> Yes, maybe.
>
> > >So in the above example {1} is first searched in the values
> > >delivered by the action - not found there - and then searched
> > >in the values by the matcher.
> >
> > Your above example, even if it seems nice at first, leads to some
> > predictability problems : how do you know which {1} will be used ? What
> > if several components in the stack return a {1} but with a different
> > meaning ?
> >
> > In a programming language, a local variable is *written* in the code,
> > and you know which one you are using, even if hiding variables is often
> > considered as a bad practice - if allowed by compilers. In the sitemap,
> > returned variables are optional and their names aren't visible.
>
> Hmm, not exactly - they are not optional - they are defined by the used
> component. If you read the docs, you know which ones this component
> returns. They are not directly visible - yes, that's true.
>
> If you simply use a variable in a programming language you don't know
> which one is used, either. You have to carefully scan the code and
> the same applies to the sitemap where you have to scan the sitemap
> (and the docs).
> And you still can use {../../../../37} - no problem.
>
> In the last months I saw many cocoon users complaining or even
> getting stuck into this area. They forgot a ../ here and so on.

I think we had problems in this area because this was a new approach and 
nobody told us about the "change".

Antonio Gallardo.
>
> > >The old path syntax is untouched - so no compatibility problems
> > >but easier handling.
> > >
> > >What do you think?
> >
> > Sorry Carsten, this is a day where we don't agree :-/
>
> Sniff....ok, let's continue the discussions tomorrow :)
>
> Carsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message