Reinhard Pötz wrote:
As I have been confused by all those suggestions you can find a summary
here: http://wiki.cocoondev.org/Wiki.jsp?page=FlowSitemapIntegration
nice, helps controlling my confusion as well
After the discussion and all your opinions I would prefer:
Integrating the flow processor/engine: --------------------------------------
<map:flows> <map:flow name="js" type="javascript"> <script src="flow/PetStoreImpl.js"/> <script src="flow/petstore.js"/> </map:flow> <map:flow name="java" type="atct"> <class src="org.apache.cocoon...."/> </map:flow> <map:flow name="fsm" type="fsm"> <blabla src="descriptors/fsm.xml"/> </map:flow> </map:flows>
... in order to be coherent. Please note that the flow element only has name and type. All other things are IMO part of the configuration (... someone proposed to have a class attribute --> that's useless for e.g. the JavaScript implementation)
indeed!
Call a flow the first time: --------------------------- <map:call flow="[yourFlow]" type="js"> <map:parameter name="x" value="y"/> </map:call>
I prefer "call" because this makes the most sense for me. But I'm +0.5 with initialize. And I like the word flow otherwise it is totally obscured that it is part of the flow implementation.
I find 'call' somewhat hiding the initialize/continue essence
nice idea with the @flow (gets us passed the @src discussion)
Please note again that we need a "type" attribute again.
indeed.
... and I don't like src because src means something different everywhere in Cocoon (something that can be called using the SoureResolver ...)
Continue a flow: ---------------- <map:continue id="..." type="js"> <map:parameter name="x" value="y"/> </map:continue>
in fact liking your @flow so much I would even get it in here to replace the @id:
in both cases this attribute does the same: it 'identifies' the 'flow' to be started or continued (so going for @flow in the one would almost impose it on the other on the grounds of coherency, IMHO)
Again, I don't like src (see reasons above) and we need the type attribute.
maybe too early to say, but I would hope that all flow-engine (or processor) implementations could share _one_ store of active FlowState's (actually I would see it as one possible anti-balkanization action, but people with other implementations in mind might have a different view)
having @type in there for now makes sense, and doesn't harm us since it could easily become just obsolete in the future case I'm mentioning
Component declaration: ---------------------- I'm indifferent on this ...
me too
--------------------------------------------------------------------
And here a completly new alternatvie (at least for this discussion:)
<map:flow call="" type="js" >
<map:parameter name="x" value="y"/> </map:flow>
and
<map:flow continue="" type="java" >
<map:parameter name="x" value="y"/> </map:flow>
This makes for me the greatest sense because you still know that you deal with flow and this is not obscured by call, continue, initialize or whatever.
Perhaps, this would make a renaming of the declaration in <map:flows>...</map:flows> necessary.
What do you think?
I like the ones above more, with only the slight remarks (just added some to the wiki to reflect)
My list then becomes: Integrating the flow processor/engine: - V2 : flows/flow/(@type,@name)/*
Call a flow the first time: - V2 : initialize/(@flow,@type)/paramaters
Continue a flow: (just added the option) - V7 : continue/(@flow,@type)/paramaters
Component declaration: (indifferent on the engine-processor)
Renamings: - V1 : FlowState(and -Manager)
Cheers, Reinhard
regards, -marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://radio.weblogs.com/0116284/ [EMAIL PROTECTED] [EMAIL PROTECTED]
