cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ellis Pritchard <>
Subject Re: RT: map:call as generic non-redirecting controller code
Date Tue, 03 Jul 2007 10:39:12 GMT

Yes, looking at that thread makes the decision look at best  
arbitrary, at worst spiteful for those who were doing something quite  
elegant with the former behaviour!

But it's actually not so bad for the 'facists' out there (see the  
thread for why I use this term!!):

It is the CallFunctionNode which enforces the contract of  
redirection, not any higher level flow construct; therefore we  
*could* leave that contract alone, and instead implement this  
functionality (ironically) with an Action, which then defines exactly  
the semantics as discussed (or, if actions are really to be frowned  
upon, an entirely new type of sitemap node).

So at the minimum we'd only need to:
a) change the Interpreter API to allow a function to return a value.
b) write an Action to allow calling the function and returning the  
value to the nested sitemap.


On 28 Jun 2007, at 17:17, Daniel Fagerstrom wrote:

> Ellis Pritchard skrev:
>> Hi,
>> I've often wondered why <map:call function="xxx"> has been  
>> implemented so that it is an error to return without sending a  
>> redirect to a pipeline.
> In the original design the flowscript where intended to work as it  
> does today. By mistake the above mentioned error check wasn't  
> implemented from the beginning. When people saw that, there was a  
> vote about introducing it: 
> t=106849566300008&r=1&w=2 and then the error check was introduced:  
> In the meantime some people had start to used flowscripts as action  
> an where quite happy about it. But they didn't succeed in  
> convincing the community that it should be allowed. The end of the  
> thread, starting with  
> Tim Olson's mail contains a discussion. While rereading it I find  
> the arguments for forbidding "flowscripts as actions" quite weak.
>> I presume this is a design decision dating back to the beginning  
>> of Cocoon Flow.
>> However, it looks to me that this would be something generally  
>> useful, and could completely replace the use of custom Actions,  
>> and improve the flow-sitemap interaction.
> Agree completely. I have taught Cocoon to a number of people and  
> most of them have found this limitation of flowscript use  
> frustrating. It also makes the sitemap unnecessarily hard to follow  
> in many cases.
>> Examples include:
>>     - all the normal Action things (propagating parameters, login  
>> state etc.)
>>     - complicated logic for determining branching in a pipeline  
>> e.g. a or b or (a and b) or !(a or b) selects different rendering  
>> pipelines logic.
>> The Interpreter interface currently has a callFunction method with  
>> a void return; certainly the underlying JavaScript implementation  
>> can return an Object, as can any Java implementation, so there's  
>> no reason why a Flow function couldn't return a Map (e.g. JS  
>> Object) which would be used for parameterisation of a nested  
>> pipeline in exactly the same way as Actions do. There's also no  
>> reason why the function could not continue to be able to redirect,  
>> as Actions do.
>> In the case where map:call is not being used as part of a  
>> continuation, the requirement for redirection simply adds a  
>> superfluous match in the pipeline, which may well not be valid in  
>> any other context of invocation (e.g. it relies on flow-attributes).
>> Personally, I also hate having to put those redirection URIs in  
>> the Flow, even if passed by parameter, rather than, for example  
>> returning navigation ids (cf. struts, JSF) which could then be  
>> used to allow the sitemap to select the appropriate rendering  
>> pipeline. If someone re-factors the sitemap, they may have no idea  
>> as to where the URI is used in a FlowScript, and therefore will  
>> easily break the application. It also, I think, breaks SoC by  
>> mixing logic with stuff normally handled by the sitemap.
>> For instance, in a simple non-CForms flow I may wish to  
>> distinguish between the rendering pipeline taken if in an AJAX  
>> request, and the rendering pipeline taken in a non-AJAX request.  
>> So I could pass two URIs through to the flow as parameters and  
>> then choose between them when doing a sendPage*(); however, then  
>> again, I may now wish to use different rendering pipelines when  
>> using CForms: since the sendFormAndWait() function doesn't return  
>> until a terminating submit button is pressed, I don't have that  
>> level of control on a per-request basis (e.g. my first show uses  
>> the page-level rendering pipeline which is a huge aggregation,  
>> subsequent AJAX-request shows just need to render the form itself,  
>> thus saving the (expensive) aggregation. Using return ids instead  
>> of redirection would allow the sitemap to make that rendering  
>> decision.
>> Would anyone else like to share their thoughts?
> I agree with your ideas and think we should implement them.
> /Daniel

View raw message