cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Olson <tol...@marketingforce.com>
Subject RE: [vote] forbidding flowscripts with no sendpage redirects (was Re: Saving pipeline output to a temp file...)
Date Wed, 12 Nov 2003 22:03:05 GMT
> Tim Olson wrote:
> > <map:match action="*/profile/edit">
> >   <map:call function="dumpUserData"/>
> >   <map:call function="dumpOrderData"/>
> >   <map:call function="dumpNewsItems"/>
> >   <map:generate src="cocoon://generate"/>
> >   <map:transform src="homePage.xsl"/>
> >   <map:serialize/>
> > </map:match>
> 
>   <map:match pattern="*/profile/edit">
>     <map:call function="dumpData"/>
>   </map:match>
> 
>   <map:match pattern="view">
>     <map:generate src="cocoon://generate"/>
>     <map:transform src="homePage.xsl"/>
>     <map:serialize/>
>   </map:match>
> 
> function dumpData() {
>    dumpUserData();
>    dumpOrderData();
>    dumpNewsItems();
>    cocoon.sendPage("view");
> }
> 
>       Ugo

i thought the original intention was to make the flow clearer?  now we have
three blocks of code to follow instead of one...

stefano's suggestion of
>   <pipeline internal-only="true">
>    <match pattern="screen/edit">
>     <generate src="cocoon://generate"/>
>     <transform src="profileForm.xsl"/>
>     <serialize/>
>    </match>
>   </pipeline>
> 
>   <pipeline>
>    <match pattern="*/profile/*">
>     <call function="main">
>      <param name="action" value="{2}"/>
>     </call>
>    </match>
>   </pipeline>
> 
> function main(action) {
>      func = this[action];
>      if (func != undefined) func.apply(this,args);
>      cocoon.sendPage("screen/" + action);
> }

is cleaner but we have many pages which need no backend data, only "simple"
xsl of our standard xml stream, so we would now have to write empty
javascript "flow controllers" for these pages.

throwing an exception for a case which works fine seems very heavy-handed to
me.  wouldn't a warning in the log suffice?  how about making the error
throwing configurable?
it pains me that our site will have to make significant refactorings,
increasing the complexity and verbosity of our code, to accomodate what
seems to me to be a stylistic decision facistly enforced, because some user
somewhere doesn't know that a map:call might not return.


Mime
View raw message