cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Oliver <res1c...@verizon.net>
Subject Re: [RT] Generalizing the flow
Date Sat, 05 Jul 2003 21:24:09 GMT
Marc Portier wrote:

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

>
>> 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'
>
>>
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:

  var k = new Continuation();
  print(k instanceof Function)  // prints true
  k();




Mime
View raw message