BTW, what about my suggested FlowScriptSelector? http://marc.theaimsgroup.com/?t=106864448500002&r=1&w=2
...
Not as I remember the discussion, no...
From the top of my head the main idea was to not have the calls to publishing pipelines hidden in the flowScripts, but rather letting the flowScripts return some 'state' that could include the continution-point
based on that returned state the flow-selector would then be visibly in the sitemap be doing the selction of the pipeline
a better name would probably be the FlowScriptResultSelector :-)
the main drive was to decouple the flowscipt-functions from the sitemap that calls them: if they would return some code upon which to select the coupling would be less tight and reuse higher...
making sense? other interpretations of the discussion?
These have been exactly my thoughts, Marc, so 1000 points to you :)
Wow, this seems completely upside down to me! We've been using flow script to purely drive flow, the sitemap to purely generate content and Java classes called by the flow to drive business logic. Adding flow decisions back to the sitemap seems to remove the "flow" out of flow?
Yes, perhaps you can get a more generic flow controller, but you do so at the expense of a less generic sitemap. What's the point? I prefer to have _all_ my flow logic in one spot: the flow controller...
Indeed, Peter, it's a completely different concept and - even if it were better - we won't implement it. The thoughts were tied to the old sitemap. You have the whole application in one file. I did see the flow only as action replacement and wanted to control the sitemap flow (i.e. pipeline selection) in the sitemap. In the meantime I have changed my opinion. The clearer SoC is a good and important point.
With the question above I only wanted to provoke a reaction by the man on the whiteboard but he didn't say more than this one word:
Amen.
BTW, what exactly does this mean, what are the shades and nuances of "Amen"? Is it complete agreement, nothing to add?
Joerg
