Hi,
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.
Ellis.
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: 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
