Yes, I agree with you but why not using a solution which markes a flowscript as "linear" or "returnable"?I don't mean to start any kind of flame war here and the following is strictly my opinion.
Actually the statement below is the exact reason I and my colleagues are reticent to use flowscript. I have no problem with using flowscript to manage a couple of pages that are linked together (i.e. - a form to fill out followed by a confirmation page). But using it for more than this violates the separation of concerns principal that Cocoon strives to achieve through the sitemap. It is far too easy to start throwing all your business as well as presentation logic into flowscript and soon you'll end up with something worse than JSPs. This is impossible to do with just the sitemap.
Frankly, I have been concerned with how so much effort seems to be focused
on moving Cocoon from its sitemap roots to flowscript.
<map:call function="myFunction" return="true"/>
If this flag was setted it should be impossible to use sendPage and sendPageAndWait, ... within the flowscript. So it is not possible to call another pipeline and the flow must return to the called position in the pipeline. With this solution you have a kind of action which is much more easier to develope.
1.) If you read the sitemap you can decide (by reading the sitemap! not the flowscript!) which <map:call/> returns after work at the same position.
2.) The programmer of a flowscript is not able to use sendPage,... and therefore he has to design the flowscript to fit this need.
What do you think about this?
Regards
