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...
I'll look into this, Marc.
No, it does not. You see, a Continuation _really_ _is_ a function (in Scheme and in Rhino and in other languages that support continuations). And you call them like any another function:
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'
var k = new Continuation(); print(k instanceof Function) // prints true k();
