[EMAIL PROTECTED] wrote:
Although most of the arguments are clear, they also raise more questions :-)
I don't know if I get all arguments but at least some:
1. Both actions and flow scripts were designed for the controller part.
2. Actions were often misused, so a new concept was searched for.
Could you give an example of this "misuse"?
hm, as I see things (and there are many opinions I'm afraid) you should look at Actions as being the equivalent of 'static' methods in Java
they apply to all your users in the same way, and the 'instance' data they need to maybe work upon to do user-sepcific stuff needs to be stored/collected from the session all the time
conceptually 'flow' often seems to have it's own instance data (i.e. not be strictly stateless)
solving these cases in a classic web programming paradigm forces you to put that information over in the session, complicating your strict use-case-controller by adding both session store/lookup instructions and extra stress to manage that session object well (avoiding attribute-key-conflicts)
to me deciding between both is similar to deciding between static or not in Java. Equally the classic Java-advice 'avoid static when unsure' should be extended to this area: choose flow (and sendPageAndWait) over actions
HTH even if the explanation is not technically conclusive (there is some emotions and personal feeling/vision around this, so be sure to develop your own and be open enough to test it regularly in real life cases)
3. Interpreting (flow script) vs. compiling (actions). 4. Procedural style of the flow scripts is nearer to flow control. 5. Support of continuations with flow scripts.
From a newbie point of view: the idea behind it is fairly easy to grasp, butwhen trying to figure out why it doesn't work as expected (e.g. with Woody forms) it is very incomprehensible. But maybe that is related to 6.
hm, my guess would be it has more to do with experience and feeling comfortable, knowing your way around...
this might help a bit: http://cocoon.apache.org/2.1/howto/howto-flow-debugger.html
but doing some print() statements often helps fast to nail it down
6. Less delivered code for flow scripts while there are many actions available.
7. Better separating of concerns for flow scripts.
8. Therefore less sitemap readibility (the sitemap flow is not that obvious, because parts of the logic is in the flow script).
hm, probably 'non-exclusive-role of the classic sitemap in deciding the pipeline to use' might be a more political correct (opinion neutral) transcription of point 8 :-)
Thanks for the explanation. Can you, or anyone else, give ideas as to when to use actions and when to use flow? I don't have the feeling that they are interchangeable. On the other hand I feel that using both actions and flow in a single webapp will add to the complexity.
see above: understand what they are good at, consider the flow solution first (and just don't consider anything else if there is 'flow' or end-user interaction to control in your use case)
flowscripts without own variables or sendPageAndWait (or showForm) are candidates to be reconsidered... (if there is even no backend to connect then matchers, selectors or input-modules might be an even better choice)
Bye, Helma
regards, -marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
