On 15 Jan 2004, at 17:59, Hunsberger, Peter wrote:
Marc Portier <[EMAIL PROTECTED]> writes:
Vadim Gritsenko wrote:
Marc Portier wrote:
Vadim Gritsenko wrote:
Joerg Heinicke wrote:
BTW, what about my suggested FlowScriptSelector? http://marc.theaimsgroup.com/?t=106864448500002&r=1&w=2
What would be the difference between selector you proposed and ScriptAction with Javascript which we already have?
good question, I've never used it though... so I don't know, the important questions would be - does it have access to the FOM?
- does it make sense to add FOM to the ScriptAction? :-)
It would of have surprised me indeed :-)
- does it support the equivalent to <map:call continue="">
- are you planning to allow continuations in FlowSelector? :-)
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?
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...
Amen.
-- Stefano.
