Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 98746 invoked by uid 500); 8 Oct 2002 10:14:36 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 98730 invoked from network); 8 Oct 2002 10:14:35 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Antonio Gallardo Rivera Organization: AG Software, S. A. To: cocoon-dev@xml.apache.org Subject: Re: [Proposal]: Advanced Value Substitution Date: Tue, 8 Oct 2002 04:13:17 -0600 User-Agent: KMail/1.4.3 References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200210080413.17307.agallardo@agsoftware.dnsalias.com> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N El Martes, 08 de Octubre de 2002 03:38, Carsten Ziegeler escribi=F3: > 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 ? Wh= at > > 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 oft= en > > considered as a bad practice - if allowed by compilers. In the sitema= p, > > 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=20 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