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: http://marc.info/?t=106849566300008&r=1&w=2 and then the
error check was introduced:
http://marc.info/?l=xml-cocoon-cvs&m=106858783407241&w=2.
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
http://marc.info/?t=106849566300008&r=1&w=2, 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
