Revisited Proposed Flow Renaming (was Re: [Vote] Controller/Sitemap integration)

[Marc Portier <mp...@outerthought.org>]

While I was typing this mail Carsten has proposed to release on 
the 29th, so let me please restate that I don't want to be in the 
way of that release in any way... (so postponing the vote is OK 
with me)

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/
mpo@outerthought.org                              mpo@apache.org

Re: Revisited Proposed Flow Renaming (was Re: [Vote] Controller/Sitemap integration)

[Daniel Fagerstrom <da...@nada.kth.se>]

  Marc Portier wrote:
...

> -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?

Flowscripts are not only usable for handling page flow in webapps, you 
can also write flowscripts that perform some side effects and ends with 
a sendPage, (and not use any sendPageAndWait), i.e. perform a side 
effect and return a page. This use will not set up any continuation 
object and have about the same use cases as actions. I would guess that 
people who write a lot of flowscripts will prefer this construction 
before with actions. For this use case "call" seem to be a much more 
natural name than "initiate" while they IMHO has similar descriptive 
value for multi page flow I would prefer the naming as is..

/Daniel