Stephan Coboos dijo: > Ralph Goers wrote: > >>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. >> >> > Yes, I agree with you but why not using a solution which markes a > flowscript as "linear" or "returnable"? > > <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?
We already have <map:action> to this. With <map:action> the sitemap complexity grows very fast in some times to unreadable sizes. Best Regards, Antonio Gallardo.
