<map:match pattern="*/profile/edit"> <map:call function="dumpData"/> </map:match>
<map:match pattern="view"> <map:generate src="cocoon://generate"/> <map:transform src="homePage.xsl"/> <map:serialize/> </map:match>
function dumpData() { dumpUserData(); dumpOrderData(); dumpNewsItems(); cocoon.sendPage("view"); }
The main problem I have with this approach is that without looking at the script code, there is no easy way of telling that the first match will end up calling the second one and so the flow of the application becomes more opaque...and thus harder to understand and maintain.
I like Tim's approach much better....where everything is in one place and the high level flow of control is quite clear and transparent.
For the moment it's better to have this that restrictive. But have a look at the recent thread "[RT] Is flowscript polluting sitemap readability?". Maybe, but really only maybe as it was only a random thought and we must think about the concept, there will be a Selector in the future that leads the sitemap flow depending on the result of the flow script. This brings the light back to the sitemap and can reduce opaqueness ;-)
And this will remove the need for such an action-like behaviour you and Tim relied on. BTW what exactly should the FlowAction do? I didn't follow the thread closely. If it does that what I imagine (or fear) we are back to actions and don't need any flow. I like the Selector approach much more. But let's discuss it at that thread.
Joerg
