Return-Path: 
 <dev-return-59683-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 16113 invoked from network); 19 Apr 2004 16:57:51 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 19 Apr 2004 16:57:51 -0000
Received: (qmail 99051 invoked by uid 500); 19 Apr 2004 16:57:40 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 99000 invoked by uid 500); 19 Apr 2004 16:57:40 -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 98986 invoked from network); 19 Apr 2004 16:57:39 -0000
Received: from unknown (HELO mgate1.stjude.org) (192.55.208.20)
  by daedalus.apache.org with SMTP; 19 Apr 2004 16:57:39 -0000
Message-ID: 
 <1E0CC447E59C974CA5C7160D2A2854EC097DF1@SJMEMXMB04.stjude.sjcrh.local>
From: "Hunsberger, Peter" <Peter.Hunsberger@STJUDE.ORG>
To: <dev@cocoon.apache.org>
Date: Mon, 19 Apr 2004 11:57:42 -0500
Subject: RE: [RT] Use of flowscript or the pyramid of contracts  (was Re: [RT]
 Checked exceptions considered harmful)
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-OriginalArrivalTime: 19 Apr 2004 16:57:42.0311 (UTC)
 FILETIME=[6DF1FB70:01C4262F]
X-SEF-FD9E3BCC-24E9-4B6F-96E-FFC4B78-SJCRH: 1
content-class: urn:content-classes:message
Thread-Topic: [RT] Use of flowscript or the pyramid of contracts  (was Re:
 [RT] Checked exceptions considered harmful)
Thread-Index: AcQl8wHnf/tfnVX6TPme1tcZ5ieduwAOZIWQ
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

Daniel Fagerstrom <danielf@nada.kth.se> writes:

<snip/>

> I believe OTH that some of the "simpler" input modules,=20
> especially the=20
> request module, the request attribute module and the flow attribute=20
> module, makes it possible to have a *cleaner* SOC, than it is=20
> possible=20
> without them. Let me give a simple example:
>=20
> <match pattern=3D"table.html">
>    <generate src=3D"table.xml"/>
>    <transform src=3D"table2html.xsl">
>      <parameter name=3D"sortOrder" value=3D"{request-param:sortOrder}"/>
>    </transform>
>    <serialize>
> </match>
>=20

<snip/>
>=20
> I fail to see that:
>=20
> <flow language=3D"javascript">
>    <script src=3D"sortOrder.js"/>
> </flow>
>=20
> <match pattern=3D"table.html">
>    <call function=3D"getSortOrder"/>
> </match>
>=20
> <match pattern=3D"table-view">
>    <generate src=3D"table.xml"/>
>    <transform src=3D"table2html.xsl">
>      <parameter name=3D"sortOrder" value=3D"{flow-attribute:sortOrder}"/>
>    </transform>
>    <serialize>
> </match>
>=20
> sortOrder.js:
>=20
> function getSortOrder() {
>    sendPage("table-view",
>             {"sortOrder": cocoon.request.attibute.sortOrder}
> }
>=20
> would be an improvement in clearity compared to using input modules,=20

Ok, but what I think you are partly missing is the level of generic
sitemap that flow can allows.  Instead it becomes something more like:

 <flow language=3D"javascript">
    <script src=3D"controller.js"/>
 </flow>
=20
 <map:match pattern=3D"*.html">
    <map:call function=3D"main">
	<map:parameter name=3D"p1" value=3D"{1}"/>
    </map:call>
 </map:match>
=20
 <match pattern=3D"_page.*">
    <generate src=3D"{1}.xml"/>
    <transform src=3D"page2html.xsl"/>
    <serialize>
 </match>

controller.js:

 function main( page ){
	var func =3D this[ page ];
      var args =3D new Array( page );
      if ( func !=3D undefined )
      {
          func.apply( this, args );
      }
      else
	    sendPage( "_page.+page );
 }

 function table( page ) {
    sendPage("_page."+ page,
             {"sortOrder": cocoon.request.attibute.sortOrder}
 }
=20
(I believe making the generic XSLT processor handle the flow generated
parameters directly wouldn't be that hard?  In our case, we just have a
whole patch of common parameters we always pass in the sitemap, subbing
them in via an action, but that's more-or-less the same thing as using a
module to get at them...)

If you're site map shrinks down to almost nothing, and all the logic on
what page is being called is in the flow script, doesn't that add
clarity?  In your example, you're still using the sitemap to determine
page flow...

<snip/>=20