cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Adding cocoon.suicide() to the FOM API.
Date Fri, 11 Mar 2005 15:31:45 GMT
Sylvain Wallez wrote:

> Bertrand Delacretaz wrote:
>
>> Le 11 mars 05, à 15:18, Sylvain Wallez a écrit :
>>
>>> ...This is currently possible using "FOM_Cocoon.suicide()" which is 
>>> what is used internally by cocoon.sendPageAndWait (see 
>>> fom_system.js), and I would like to make this more visible by being 
>>> available as "cocoon.suicide()".
>>
>> It is not cocoon that is killed, it is the current flowscript, so why 
>> not
>>
>>  cocoon.killCurrentFlow()
>>
>> instead, to avoid confusion?
>>
>> "suicide" is marginally funny but not very explicit about what 
>> happens next ;-)
>
> "suicide" comes from Scheme, where continuations were born, and 
> therefore may not be obvious to our "normal" users ;-)
>
> Now rather than using the IMO verbose "killCurrentFlow", we could 
> start separating "cocoon" from "flow" as I suggested a while ago.
>
> So what about the simple "flow.exit()"? I also though about 
> "flow.kill()" but it can convey the meaning of killing the current 
> continuation tree. There's also "flow.stop()" but it implies a 
> possible return which is not what we want. 

+1 for flow.exit()

> We could also start providing flow.sendPage{AndWait}(), 
> flow.sendStatus(), flow.getComponent() etc... as direct links to their 
> cocoon.* counterpart and initiate the migration of their 
> implementation from FOM_Cocoon to a new FOM_Flow without backward 
> incompatibility.
>
> WDYT? 

+1

We seemed to have converged to a nice solution for unified environment 
handling, so just go ahead ;)

BTW, concerning what to call the "object accessors", what about just 
"accessor", e.g. RequestAccessor, SessionAccessor etc.

/Daniel



Mime
View raw message