Return-Path: 
 <cocoon-dev-return-25621-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 38105 invoked by uid 500); 12 Apr 2002 14:00:41 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 38094 invoked from network); 12 Apr 2002 14:00:41 -0000
Message-ID: <021401c1e22a$67ebe060$9ac78842@galina>
From: "Ivelin Ivanov" <ivelin@apache.org>
To: <cocoon-dev@xml.apache.org>
References: <FDCEAB9D7DE70246A419ECF68553D10456B835@POSTMAN.flagship.ru>
Subject: Re: continuation fear (was Re: [status & RT] design challenges)
Date: Fri, 12 Apr 2002 09:00:29 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="koi8-r"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N


----- Original Message -----
From: "Piroumian Konstantin" <KPiroumian@protek.com>
To: <cocoon-dev@xml.apache.org>
Sent: Friday, April 12, 2002 6:16 AM
Subject: RE: continuation fear (was Re: [status & RT] design challenges)
<snip/>

> >That's too much of a price to pay when an interpreted
> > language already does it for me.
>
> The key phrase is "does it for me" - interpreted language is another
> language that you should learn, you should get used to it and you should
> study also a lot of "best practices" samples and good docs to learn from.

Second that.
I am starting to understand why Schecoon is a lot more flexible and powerful
than I originally thought.
However I would ask Ovidiu to consider at least an alternative "poor man"
solution which will do the job for many of us. I will not repeat myself more
than just refering back to the <map:fetch> construct as an extension to
<map:redirect> and <map:call> (or <map:forward> :).

Konstantin is <map:fetch/> extension getting anywhere close to your flow map
solution?


Thanks,

Ivelin



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