As for the proposal Sylvain and I uttered originally I would consider the discussion we had on the topic after Sylvain's post to direct more (but not completely) into the naming-proposals Stephan is introducing here...
The following might seem like nagging but I do share Sylvain's eagerness to get names really right, so I'm wide open for other alternatives and views...
Stephan Michels wrote:
If I think on different implementations for the flow, the names are not every intuitive, IHMO.
So, can I offer some alternatives?
On Wed, 16 Jul 2003, Reinhard Pötz wrote:
[A] The "Cocoon Advanced Control Flow" provides a controller that is linked into the sitemap (as **child element** of <map:sitemap .../>:
<map:flow type="[yourEngine]"> [configuration] </map:flow>
This reflects that the flow is not a *usual* sitemap resource but something else.
The point, which irritates me, is that you don't have a identifier to address the script/whatever.
So my favorite choise will be
<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="org.apache.cocoon...."/> <map:flow name="fsm" type="fsm" src="descriptors/fsm.xml"/> </map:flows>
So this will be coherent with the other objects.
and it makes perfect sense after the recent discussions
it does go a step further and assumes we allow for more then one flow impl to be active at any given time
not needing to choose one impl for the complete cocoon webapp is still something different then making sure that implementations can be swapped (we had a consensus on the latter, not yet on the first)
but again, it makes sense all the way and IMHO assures more easily for a seemless integration of what is around (and thus making sure more of the 'related' issues will be handled in equal ways, making the different impl more 'alligning' then 'competing')
[B] The controller is called by:
<map:call flow="[yourFlow]"> <map:parameter name="x" value="y"/> </map:call>
Seems fine, an alternative will be
<map:initiate flow="js" call="[Javascript function]"> <map:parameter name="x" value="y"/> </map:initiate>
<map:initiate type="java" call="[Java method]"> <map:parameter name="x" value="y"/> </map:call>
<map:initiate type="fsm" call="[Name of state]"> <map:parameter name="x" value="y"/> </map:initiate>
I like the combination of initiate/continue
yes, I stated this in another thread, looking at it from the POV of the sitemap there are two kinds of URI's:
1/ the ones that start/initiate a use case (of which the state is managed at the server side)
2/ the dynamic ones that point to states that can continue the process
[C] A state of the controller is called by:
<map:call state=""> <map:parameter name="x" value="y"/> </map:call>
We don't call states in this sense. We continue a continuation ;-)
actually I think we continue with the 'use-case'
or we continue the 'interaction'
I guess <map:continue continuation="{1}"/> is bad.
<map:continue src="{1}"/> or <map:continue id="{1}"/>
Still <map:continue state-id=".." /> might make sense as well?
[D] All flow interpreters[3] are Avalon components and declared in the cocoon.xonf:
<flow-engine default="[yourController]" logger="[yourLogger]"> ... </flow-engine>
+1, except the name, see next.
[E] Changes in the current Javascript implementation: - rename "Interpreter" to "FlowEngine",
Again, to be coherent my favorite is <flow-processor> like <xslt-processor> and <xpath-processor>, or treeprocessor.
quite indifferent here, since processor is still not catching it completely IMHO, but I don't have a better alternative yet :-(
- rename "WebContinuation" to "FlowState", and accordingly "WebContinuationManager" to "FlowStateManager".
Yes, the Continuation represents a state, but to make a clear difference as a new concept, I think 'Continuation' is accurate. But 'Web..'?!
I think there is two things here: interface and current implementation.
we should get the correct name for the abstract thing, but the WebContinuation could keep on existing as the flow-script-js-continuation thingy that just implements that (although some reference to js in that name would make more sense then?)
I still like FlowState in this context... as I said above we continue with the use case or interaction (rather then 'the continuation')... the reason why we can do that is because there is server side State of the Flow maintained for the current point in that process...
(I know State sounds like something 'passive' while the continue-responsibility it has points out some 'activity'... note however that the Flow-prefix makes up for that, and that the classic 'State' pattern suffers from the same, so some of us might be used to it)
- rename "WebContinuation" to "Continuation", and accordingly "WebContinuationManager" to "ContinuationManager".
Thoughts?
Stephan Michels.
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]
