Congrats for your project. But I really think this unspecified behaviour you're using is not the good way to go. So let's keep it as is in the upcoming 2.1.3 and forbid it in 2.1.4.
Why forbid it? I see no reason to elminate such a useful feature, unspecified or otherwise.
There's been a discussion about this, and we agreed on the fact that he semantics of <map:call function> and <map:call> continuation implied that it _must_ redirect somewhere using sendPage, sendPageAndWait or redirectTo.
The semantics you would like is the one of an action. I proposed to add a "flowscript action" that would share function and global variable scopes with the flowscript but have the appropriate contract of returning a Map of values to the sitemap.
So the flowscript call semantics will be strengthened in the 2.1.4 to avoid abuses of this unspecified behaviour. And the fact that you already rely on this behaviour shows that we must correct things quickly.
If it was only me, we would forbid it ASAP for the 2.1.3 release. What do others think?
My interpretation of the discussions and votes was that we: a) Do not allow nested sitemap components within <map:call> b) Do not allow returning Map as result of flow script invokation
These two pretty much rule out flowscript actions, but:
c) Allow flowscript to return empty response by the way of invoking sendStatus
Which solves empty response issue for webdav etc. And the last: d) No other decision was made
Which means that if you do not call sendPage* and do not call sendStatus, sitemap will continue execution. Did I miss something?
Vadim
