On Wednesday, Nov 5, 2003, at 13:41 Europe/Rome, Vadim Gritsenko wrote:
...
Before we vote: how to resolve "flow actions" issue then? There should be migration path for users who already have wrote an actions wtih flow.
(remember? you've said that actions should be replaced with flowscript ;-)
You teaser ;-)
IMVHO, an action is an overlap of three concerns:
1) processing logic external to the sitemap used to drive its flow 2) processing logic external to the pipelines used to drive its creation 3) processing logic used to update the external environment
A potential migration strategy is:
1) should be done in the flow, either rewriting in javascript or refactoring the logic, moving it into an isolated component (either avalon or simple java class to instantiate from the flow)
3) this should be refactored into a class or component
which leaves us with 2).
I've seen far too many actions that set parameters that are later used by selectors. This is WRONG!!! You should be writing a selector!!!
But at the very end, I think the issues at stake are orthogonal: Unico and I want a simple way to generate reponses with empty-payloads because this is going to be common for more complex uses of HTTP.
You propose to clone the ugly action-like sitemap semantics with flowscript logic.
No, I don't. I'm just teasing ;-)
I'd like to see following:
1) If flow calls sendPage*(), sitemap execution terminates. 2) If flow calls sendStatus(), sitemap execution terminates. 3) If flow does none of the above, sitemap execution continues.
I think we have already consensus on (1) and (2). (3) is the current behavior which can stay.
I agree with comments in this other thread that let's not introduce nested components in <map:call/>. Instead, if needed, let's introduce <act type="flow"/>. Sometime later.
Vadim
