cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: RT: map:call as generic non-redirecting controller code
Date Thu, 28 Jun 2007 16:17:34 GMT
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: 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.


View raw message