seperate from that position I'ld just like to get the show on stage and not let us run away from the discussion now that we are getting closer... (I wouldn't mind getting us to a vote soon)
sorry if this approach makes you scizofrenic...
Reinhard P�tz wrote:
So I'm +1 to release the flow implementation as it is ASAP and discuss this again when the second implementation is on the table. As already mentioned there will be only littly changes necessary for flow users (not more changes than with 2.0 --> 2.1).
starting to feel guilty about not having the implementation yet (Sylvain went at length explaining why we didn't want to do that)
so I jumped into it and set some other stuff asside to get my nose into the code of o.a.c.components.flow first and maybe get a better understanding
(please correct me where appropriate)
Current situation:
The delegate from the POV of the sitemap is the Interpreter that gets called to either callFunction() or handleContinuation(). This Interpreter also has a callback forwardTo() function which hands over the control back to the sitemap providing the URI of the selected pipeline to use for publishing the answer...
For convenience of specific InterpreterImpls there is an AbstractInterpreter one can subclass from, it already maintains a reference to the ContinuationsManager (see below) and provides the implementation for the forwardTo() which is most likely to be similar for all implementations (at least if they want to be reusing existing publication pipeline components that go look for the bean and continuation object in the predefined spots)
The ContinuationsManager interface and his sole implementation ContinuationsManagerImpl manage the lifecycle (create, store for retrieval and cleanup==invalidate) of the actual WebContinuations.
These WebContinuations in their turn are not in anyway directed to any implementation, instead they are wrapping whatever stateful 'user-object' the specific InterpreterImplementation would like to be stored. (they also allow, for hooking them up in trees, and they carry their own id, which is the thing that is showing up in the dynamic URI's of course, and is also the 'key' by which the ContinuationsManager is perfroming it's lookup)
This makes me understand a number of things
- WebContinuations do not need an intermediate layer or interface to implement cause they solve the multiple impl issue already the other way around (wrapping around the so called user-object)
[so please ignore my earlier remark in this area]
- as a consequence the ContinuationManagerImpl is already fully aware of how to manage the continuations of different implementations. However they are not *driving* the handleContinuation(), yet are peacefully under control of the Interpreter at hand to give back the WebContinuation stored by a certain id. This is mainly because the Interpreter can then unwrap the user-object from the WebContinuation, cast it to the correct subclass, share preparation work in building some execution context,....
[so unlike what I was thinking out loud earlier: if we are to have more then one possible Interpreter declared inside one cocoon instance, then some @type will be required in both initiate and continue cases to point to the correct InterpreterImpl
Coming back on the renaming from this angle:
-1- FlowState, FlowStateManager, DefaultFlowStateManager *could* be a replacement for WebContinuation, ContinuationManager and ContinuationManagerImpl...
but I'm getting quite indefferent on this... the historic connection between Interpreters and WebContinuations is not reflected by the code in any way, so it's more in our minds then anywhere else (maybe realizing this helps us setting it asside)
-2- Interpreter should be changed to FlowProcessor (more sense then FlowEngine becomes apparent now?) and its methods could make the transition from
callFunction(String funcName, List params, Environment env)
handleContinuation(String contId, List params, Environment env)
towards
initiateFlow(String flowId, List params, Environment env)
continueFlow(String contId, List params, Environment env)
which maybe gets mapped back to the
<map:initiate flow="flowId" type="interpreter-name" /> <map:continue flow="contId" type="interpreter-name" />
that was still under discussion somewhat?
-3- What remains open is how to declare more then one active FlowProcessor, for which I think the lign up with other components inside Cocoon (like Generators et al.) makes the most sense, but I'm open for other suggestions here
(off course I assuming that the expressed consensus about actually allowing this is big enough to consider this additional change)
what do others think?
-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]
