cocoon-dev mailing list archives

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

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


"RequestObjectAccessor" or "SessionObjectAccessor" really would be too 
verbose, but "ObjectAccessor" for the general interface is maybe less 
abstract than simply "Accessor". Now talking about abstraction, it will 
be more difficult to write something more abstract than an interface 
having a single "Object get()" method ;-)

Well...

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }


Mime
View raw message