cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@STJUDE.ORG>
Subject RE: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Date Mon, 19 Apr 2004 16:57:42 GMT
Daniel Fagerstrom <> writes:


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

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

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="javascript">
    <script src="controller.js"/>
 <map:match pattern="*.html">
    <map:call function="main">
	<map:parameter name="p1" value="{1}"/>
 <match pattern="_page.*">
    <generate src="{1}.xml"/>
    <transform src="page2html.xsl"/>


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

 function table( page ) {
    sendPage("_page."+ page,
             {"sortOrder": cocoon.request.attibute.sortOrder}
(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...


View raw message