Return-Path: 
 <dev-return-44502-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 50376 invoked by uid 500); 5 Jul 2003 21:24:10 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
list-post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 50363 invoked from network); 5 Jul 2003 21:24:09 -0000
Received: from pop018pub.verizon.net (HELO pop018.verizon.net)
 (206.46.170.212)
  by daedalus.apache.org with SMTP; 5 Jul 2003 21:24:09 -0000
Received: from verizon.net ([4.40.118.187]) by pop018.verizon.net
          (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP
          id <20030705212415.OIZP11703.pop018.verizon.net@verizon.net>
          for <dev@cocoon.apache.org>; Sat, 5 Jul 2003 16:24:15 -0500
Message-ID: <3F0741F9.5010804@verizon.net>
Date: Sat, 05 Jul 2003 14:24:09 -0700
From: Christopher Oliver <res1cf5x@verizon.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] Generalizing the flow
References: <3F058848.9080502@anyware-tech.com> <3F05D752.4070004@verizon.net>
 <3F05F85E.3070501@outerthought.org> <3F061023.9040008@verizon.net>
 <3F06CB3C.4090609@anyware-tech.com> <3F0705E7.5030804@verizon.net>
 <3F072642.6070607@anyware-tech.com> <3F072E5B.3030402@verizon.net>
 <3F073E4B.6020606@outerthought.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Authentication-Info: Submitted using SMTP AUTH at pop018.verizon.net from
 [4.40.118.187] at Sat, 5 Jul 2003 16:24:15 -0500
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

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();