cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: [RT] Generalizing the flow
Date Sat, 05 Jul 2003 21:08:27 GMT


Christopher Oliver wrote:
> Sylvain Wallez wrote:
> <snip>
> 
>>
>> Names are one of the most important things in design, since it's first 
>> through the names that a user goes into a set of classes. Bad names 
>> imply wrong understanding. Abstractions named after a particular 
>> implementation make other implementations look clumsy, since they 
>> don't fit into the name, even if they fit into the real underlying 
>> concept.
> 
> 
> Fine. Would you mind demonstrating at least one alternative 
> implementation of "FlowEngine" and "FlowController"  so that the rest of 
> us can make a technical assessement of how well it "fits" if you intend 
> to make these name changes?
> 

tried in the wiki with the guestbook example

although that did it the other way around: showed the programming 
on top of one, not the engine itself

this InteractionState implementation of the FlowEngine would do 
the folowing:

upon the map:call controller=".."
it would

0/ find the classname associated to that controller, instantiate 
it, and assign an ID for this instantiation

1/ stores this instance in some store (the same store as where 
the WebContinuationFlowEngine is storing his I would assume)

2/ call the processing function of this instantance that returns
   - a prepared bean-dict
   - a selected pipeline for publishing

3/ put the '#$continuation/id' information element in the request 
so it reads the forementioned ID

4/ set the bean-dict in the Request

5/ call the selected pipeline


upon the map:call state=".."
it would (exactly like it would for the webcontinuation case?)

1/ lookup the state-id in its store of instances

2-to-5/ with this instance: as above 2-to-5/

the only difference with the webcontinuation case for 
map:call/@state is that it keeps on using the same state-id and 
temporary resource (and will only store ONE server side object 
for the duration of the application-flow...)


I believe this difference could make for a more suitable model in 
some cases.

As such the FlowEngine becomes a layer that sits between the 
sitemap and the Interpreter.

In both implementation cases it manages temporary server side 
resources for which there will be a mapping URI onto it.

These managed resources are in fact in both cases responsible for
-preparing a bean dict
-selecting a pipeline for publication
in both cases they succeed in doing this based on their internal 
'state'.

(it is implementation specific whether or not that application 
state is required to include a 'frozen continuation' into a 
script function so it knows where to pick up the thread)

Hope this clarifies...

> Even so, I really don't like your names. <map:call> made perfect sense 
> when calling a continuation or function (since they are actually 
> callable). I don't quite get what "calling" a "state" means.
> 

after the above you might see that it in fact makes equal sense 
as 'calling' a 'continuation'


> Chris
> 

-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


Mime
View raw message