cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ellis Pritchard <el...@nukinetics.com>
Subject RT: map:call as generic non-redirecting controller code
Date Thu, 28 Jun 2007 13:58:59 GMT
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.

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.

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?

Ellis.

P.S. It looks like this could be implemented without breaking  
existing code, since redirect from a function invocation would still  
be possible.


Mime
View raw message