cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [vote] forbidding flowscripts with no sendpage redirects (was Re: Saving pipeline output to a temp file...)
Date Thu, 13 Nov 2003 18:27:33 GMT

On 13 Nov 2003, at 00:20, Andrzej Jan Taramina wrote:

> 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.

True. [see the other thread on flow polluting sitemap readability]

> 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.

nah, it follows the same patter of action: it's cool when it's nice and 
clean and simple... but the more complex it becomes the more it blows 
in your face, we must be more creative to solve this issue.

> also glad to see that I am not the only one that has used this 
> paradigm.
> <grins>

yeah, sounds like "millions of outlook users can't be wrong" as an add 
campaign ;-)

> 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>

you all the function twice? c'mon.

> 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

here you go, told you.

> where the method signature of dumpUserData would look like
> 	function dumpUserData( xValue, yValue ) {....}
> Clean...crisp...understandable...functional....and doesn't clutter the
> architecture.

bah, we have different tastes.

> +1 from me for the FlowscriptAction approach and soon too!

I think the selector idea is much better, let's work on that.


View raw message