Return-Path: 
 <dev-return-45158-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 28499 invoked by uid 500); 18 Jul 2003 09:33:37 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
list-post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 28456 invoked from network); 18 Jul 2003 09:33:36 -0000
Received: from vern.chem.tu-berlin.de (130.149.66.116)
  by daedalus.apache.org with SMTP; 18 Jul 2003 09:33:36 -0000
Received: from vern.chem.tu-berlin.de (localhost [127.0.0.1])
	by vern.chem.tu-berlin.de (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id
 h6I9XlGD017454
	for <dev@cocoon.apache.org>; Fri, 18 Jul 2003 11:33:48 +0200
Received: from localhost (stephan@localhost)
	by vern.chem.tu-berlin.de (8.12.3/8.12.3/Submit) with ESMTP id h6I9Xl3q017451
	for <dev@cocoon.apache.org>; Fri, 18 Jul 2003 11:33:47 +0200
X-Authentication-Warning: vern.chem.tu-berlin.de: stephan owned process doing
 -bs
Date: Fri, 18 Jul 2003 11:33:47 +0200 (CEST)
From: Stephan Michels <stephan@apache.org>
X-X-Sender: stephan@vern.chem.tu-berlin.de
To: cocoon-dev <dev@cocoon.apache.org>
Subject: RE: [Vote] Controller/Sitemap integration
In-Reply-To: <001401c34d0a$f37f8c20$1e01a8c0@WRPO>
Message-ID: <Pine.LNX.4.44.0307181114060.16717-100000@vern.chem.tu-berlin.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N


On Fri, 18 Jul 2003, Reinhard P=F6tz wrote:

> > From: Stephan Michels
> >
> > <map:initiate> -> select flow -> <map:flow>                     \\
> >                   -> select implementation -> <flow-processor>
> >
> > Ohh moment, what makes the flow component different from
> > other sitemap components? Nothing!
>
> >From a technical POV you are completly right but I share Stefano's idea
> that we should show our users that the flow component is different from
> the sitemap components. So I'm -1 on this.
>
> >
> > <map:components>
> >  <map:flow name=3D"petshop" class=3D
> > "org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter">
> >   <reload-scripts>true</reload-scripts>
> >   <check-time>4000</check-time>
> >   <script src=3D"flow/PetStoreImpl.js"/>
> >   <script src=3D"flow/petstore.js"/>
> >  </map:flow>
> > <map:components>
>
> ... so I like the new section <map:flows>...</map:flows> more. See the
> reasons above.

Oh yes, I mean

<map:components>
 <map:flows>
  <map:flow name=3D"petshop" class=3D
 "org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter">
   <reload-scripts>true</reload-scripts>
   <check-time>4000</check-time>
   <script src=3D"flow/PetStoreImpl.js"/>
   <script src=3D"flow/petstore.js"/>
  </map:flow>
 </map:flows>
<map:components>

like every other components.

> And I think it is FS to determine the implementation
> (org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter) at
> sitemap level.
> Do you have a usecase which makes this necessary? I wrote a lot of JS
> flow scripts and haven't had a need for this yet.

1. Usecase: You don't want to use flows -> remove the flow section
2. Usecase: You have different flows in the same map.
3. Usecase: You use different implementations in the same map.

The fact, that specifying of components in the sitemap is in general
a bad pratice, is another point, but don't want to discuss
here(,perhaps later :))

> > <map:initiate type=3D"petshop" start=3D"addItem"/>
> > <map:continue type=3D"petshop" id=3D"{1}"/>
> >
> > Hey, I love this :)
>
> I think this obscures that a flow processor/engine is used. Of course
> this makes only sense in connection with <map:flows>...</map:flows>.
> Therefore I like following syntax more.
>
> <map:initiate flow=3D"addItem" type=3D"petshop" />
> <map:continue flow=3D"{1}"     type=3D"petshop" />
>
> Would you be fine with this?

I thought with @type to combine the implementation(Javascript) and
instance(petstore.js), which I see as practice, which already used
with the other components.

Another way could be

<map:initiate flow=3D"addItem" type=3D"petshop" src=3D"flow/petstore.js/>
<map:continue flow=3D"{1}"     type=3D"petshop" src=3D"flow/petstore.js/>

And the flow processor could cache the instance with @src
as key.

But nevertheless, I like most

<map:components>
 <map:flows>
  <map:flow name=3D"petshop" class=3D
 "org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter">
   <reload-scripts>true</reload-scripts>
   <check-time>4000</check-time>
   <script src=3D"flow/PetStoreImpl.js"/>
   <script src=3D"flow/petstore.js"/>
  </map:flow>
 </map:flows>
<map:components>

<map:pipeline>
 [...]
 <map:initiate type=3D"petshop" start=3D"addItem"/>
 [...]
</map:pipeline>

<map:pipeline>
 [...]
 <map:continue type=3D"petshop" id=3D"{1}"/>
 [...]
</map:pipeline>

This makes the concept really symmetric to the other
components, and can signal that the continuations
are the successor of the actions.

Stephan.5~