cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Reinhard Poetz" <reinh...@apache.org>
Subject RE: [vote] forbidding flowscripts with no sendpage redirects (was Re: Saving pipeline output to a temp file...)
Date Thu, 13 Nov 2003 08:27:18 GMT

From: Andrzej Jan Taramina
 
> Ugo suggested:
> 
> >   <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");
> > }
> > 
> 
> The main problem I have with this approach is that without 
> looking at the 
> script code, there is no easy way of telling that the first 
> match will end up 
> calling the second one and so the flow of the application 
> becomes more 
> opaque...and thus harder to understand and maintain.
> 
> I like Tim's approach much better....where everything is in 
> one place and the 
> high level flow of control is quite clear and transparent.
> 
> also glad to see that I am not the only one that has used 
> this paradigm.  
> <grins>
> 
> An action that will call a flowscript for you without the sendPage 
> restriction would seem to be a reasonable alternative, in 
> which case Tony's 
> code then looks like:
> 
> <map:match action="*/profile/edit">
> 	<map:act type="FlowscriptAction"  function="dumpUserData">
> 		<map:call function="dumpOrderData"/>
> 		<map:call function="dumpNewsItems"/>
> 		<map:generate src="cocoon://generate"/>
> 		<map:transform src="homePage.xsl"/>
> 		<map:serialize/>
> 	</map:act>
> 	... error stuff can go here...
> </map:match>
> 
> Which I like even better...since you have the ability to 
> branch the flow 
> based on success/failure of the action.  You could also allow 
> parameters as 
> input to the function by doing something like:
> 
> <map:act type="FlowscriptAction"  function="dumpUserData">
> 	<map:parameter value="xxx"/> <!-- name attribute could 
> be ignored -->
> 	<map:parameter value="yyy"/>
>      .... as before
> 
> where the method signature of dumpUserData would look like
> 
> 	function dumpUserData( xValue, yValue ) {....}
> 
> Clean...crisp...understandable...functional....and doesn't 
> clutter the 
> architecture.
> 
> +1 from me for the FlowscriptAction approach and soon too!


I followed this discussion the last days and I'm still wondering why you
need this "FlowscriptAction". If you need an Action then use an Action.
What's the problem? If you say you want the fast development cycles of
Flowscript because it is interpreted then use an XSP-Action (which
should be nearly as fast)[1]

I don't like it that we blur the Flowscript concept to achieve things
that can already be done today nearly in the same way some of you
propose. In the long run I fear that nobody knows what the Cocoon
Control flow is about and everybody talks about different things. I
think this harms Cocoon more than it helps. So please come up with
usecases which make it really necessary to go this way!

... but maybe I'm the only one with these thoughts ...

--
Reinhard


[1] I've to admit that I have never used it but only read about it
(http://wiki.cocoondev.org/Wiki.jsp?page=XSPAction)


Mime
View raw message