You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@apache.org> on 2005/03/11 15:18:55 UTC
Adding cocoon.suicide() to the FOM API.
Hi all,
There are some flowscript use cases where we want to stop the current
flowscript without creating a continuation, as we don't want to the user
to go back to the script.
An example is a "login" function where the caller function expects this
function to exit only if login is successful, but that has to handle
e.g. a registration process that includes a "cancel" button.
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()".
Any objection?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Adding cocoon.suicide() to the FOM API.
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 11 mars 05, à 16:17, Sylvain Wallez a écrit :
> ..."suicide" comes from Scheme, where continuations were born, and
> therefore may not be obvious to our "normal" users ;-)
/me is normal then ;-)
> ...So what about the simple "flow.exit()"? ..
sounds good
> ...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.
+1, makes things clearer.
-Bertrand
Re: Accessors (was Re: Adding cocoon.suicide() to the FOM API.)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Ralph Goers wrote:
> Daniel Fagerstrom wrote:
>> Ralph Goers wrote:
<snip/>
>>> Is this what I hope it means? If it is, then I hope to see classes
>>> like Request, Session, Context, etc. be modified to implement the
>>> interface. To me, this would mean that they implement a static get
>>> method that returns the appropriate instance of the object. Perhaps
>>> a better name for this would be Accessible. I guess your plan is to
>>> implement a separate Accessor class to do this instead?
>>
>> I'm not geting what your aim at, could you tell a little bit about how
>> you want to use the accessores so that I can understand why you prefer
>> such a solution compared to the component based approach that we have
>> discussed.
>
> Actually, a couple approaches have been mentioned. As I understand
> them, they are:
> 1. Have a global "component object model" that everything is anchored
> in and accessed through.
Like FOM which in turn is modeled after the browser object model in web
browsers. Part of the idea IIRC was that it should be natural to used
for people who had used JS in browsers.
> Frankly, I see this as a bad idea that needs
> to go away - at least the accessing part. There are so many reasons why
> this is awful that I don't even want to start listing them. But just for
> a start, it is hardly object oriented as it makes the component object
> model have to know way too much.
It data oriented rather than object oriented. If that is good or bad
depends on your perspective. For accessing the kind of data that we have
in FOM it is OK for me. So I guess that you have to list some of your
agruments anyway if you want me to understand why its awful.
> 2. Have an Accessor interface, presumably with a class that implements
> it for each type of object to be accessed, such as RequestAccessor,
> SessionAccessor, etc. In and of itself, this isn't a bad idea. It just
> isn't necessary, in my opinion.
>
> When I was working on my last portal enhancements, I was frustrated that
> I couldn't get ahold of some of the objects I needed. The "right way"
> would have required that I make some of the classes implement Avalon
> interfaces which, of course, meant adding more definitions to
> cocoon.xconf. This is frustrating when all you want is to the reference
> to some other object, but to get it you have to have a Context or a
> service manager. It would be much more convenient for a lot of objects,
> as well as many flow applications, to be able to just do:
> Object.getInstance();
Ok, if your webapps contains a lot of custom Java code I can understand
that the Avalon way can be frustrating. The webapps that we build where
I work contains very small amounts of custom Java code. For us having
things configurable is an advantage rather than the opposite.
> This places the burden for locating the correct object instance on the
> object itself which, in my opinion, is where it belongs. It also allows
> the object to use any number of techniques to locate the correct
> instance; it can retrieve it from the object model, from the component
> manager, or whatever.
I don't know, IOC component managers where IIUC invented because some
people had bad experiences with the scalability for direct object
access. I have used that paradigm for so long that I don't remember what
problems I might have had before ;) But I think Cocoon is easier to use
and maintain if we follow the same design patterns everywhere.
Don't you think some of the problems that you describe above becomes
smaller if we introduce the possibility to use modern containers like
Spring and Hivemind in application code, like Carsten proposed?
I don't see the accessors as a general way to integrate business objects
in Cocoon but just as a evolution of the input/output module concept
that is better adapted to the needs in templates and flow and not only
to the needs for the sitemap.
> Furthermore, it allows one to write something
> like ${Request} in a template or flowscript and have that be replaced
> with a reference to the correct object instance.
How does the template know in what package to find the Request object?
And how does it know if it should use the http or command line variant?
I get the feeling that one have to rebuild quite a lot of the
architecture that we already have from Avalon if we follow the
X.getInstance() way.
> Is that clearer?
It is. But to me it seem like we are attacking different problem areas,
and I'm not certain that they should be solved with the same tool.
/Daniel
Re: Accessors (was Re: Adding cocoon.suicide() to the FOM API.)
Posted by Ralph Goers <Ra...@dslextreme.com>.
Daniel Fagerstrom wrote:
> Ralph Goers wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Oh yes, sure. I totally agree with the concept. It's not a factory
>>> and it's not an object holder as depending on the implementation it
>>> can be either or even something else. So accessor is fine!
>>
>> Did this accessor thing evolve from another discussion? It seemed to
>> pop up out of thin air in this thread.
>
> It did, I had thought a little bit more about what to call them and
> wanted to tell, Sylvain decreased the confussion by changing the
> thread name.
>
>> Is this what I hope it means? If it is, then I hope to see classes
>> like Request, Session, Context, etc. be modified to implement the
>> interface. To me, this would mean that they implement a static get
>> method that returns the appropriate instance of the object. Perhaps
>> a better name for this would be Accessible. I guess your plan is to
>> implement a separate Accessor class to do this instead?
>
>
> I'm not geting what your aim at, could you tell a little bit about how
> you want to use the accessores so that I can understand why you prefer
> such a solution compared to the component based approach that we have
> discussed.
Actually, a couple approaches have been mentioned. As I understand
them, they are:
1. Have a global "component object model" that everything is anchored
in and accessed through. Frankly, I see this as a bad idea that needs
to go away - at least the accessing part. There are so many reasons why
this is awful that I don't even want to start listing them. But just for
a start, it is hardly object oriented as it makes the component object
model have to know way too much.
2. Have an Accessor interface, presumably with a class that implements
it for each type of object to be accessed, such as RequestAccessor,
SessionAccessor, etc. In and of itself, this isn't a bad idea. It just
isn't necessary, in my opinion.
When I was working on my last portal enhancements, I was frustrated that
I couldn't get ahold of some of the objects I needed. The "right way"
would have required that I make some of the classes implement Avalon
interfaces which, of course, meant adding more definitions to
cocoon.xconf. This is frustrating when all you want is to the reference
to some other object, but to get it you have to have a Context or a
service manager. It would be much more convenient for a lot of objects,
as well as many flow applications, to be able to just do:
Object.getInstance();
This places the burden for locating the correct object instance on the
object itself which, in my opinion, is where it belongs. It also allows
the object to use any number of techniques to locate the correct
instance; it can retrieve it from the object model, from the component
manager, or whatever. Furthermore, it allows one to write something
like ${Request} in a template or flowscript and have that be replaced
with a reference to the correct object instance.
Is that clearer?
Ralph
Re: Accessors (was Re: Adding cocoon.suicide() to the FOM API.)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Ralph Goers wrote:
> Sylvain Wallez wrote:
>
>>>
>>>
>>> I can agree that it seem to break some common ideas about good
>>> coding practice. But we have been through the arguments and it seem
>>> OK. We probably find out if it works when we start to implement and
>>> integrate it.
>>
>>
>>
>>
>> Oh yes, sure. I totally agree with the concept. It's not a factory
>> and it's not an object holder as depending on the implementation it
>> can be either or even something else. So accessor is fine!
>>
>> Sylvain
>
>
> Did this accessor thing evolve from another discussion? It seemed to
> pop up out of thin air in this thread.
It did, I had thought a little bit more about what to call them and
wanted to tell, Sylvain decreased the confussion by changing the thread
name.
> Is this what I hope it means? If it is, then I hope to see classes
> like Request, Session, Context, etc. be modified to implement the
> interface. To me, this would mean that they implement a static get
> method that returns the appropriate instance of the object. Perhaps a
> better name for this would be Accessible. I guess your plan is to
> implement a separate Accessor class to do this instead?
I'm not geting what your aim at, could you tell a little bit about how
you want to use the accessores so that I can understand why you prefer
such a solution compared to the component based approach that we have
discussed.
/Daniel
Re: Accessors (was Re: Adding cocoon.suicide() to the FOM API.)
Posted by Ralph Goers <Ra...@dslextreme.com>.
Sylvain Wallez wrote:
>>
>>
>> I can agree that it seem to break some common ideas about good coding
>> practice. But we have been through the arguments and it seem OK. We
>> probably find out if it works when we start to implement and
>> integrate it.
>
>
>
> Oh yes, sure. I totally agree with the concept. It's not a factory and
> it's not an object holder as depending on the implementation it can be
> either or even something else. So accessor is fine!
>
> Sylvain
Did this accessor thing evolve from another discussion? It seemed to
pop up out of thin air in this thread.
Is this what I hope it means? If it is, then I hope to see classes like
Request, Session, Context, etc. be modified to implement the interface.
To me, this would mean that they implement a static get method that
returns the appropriate instance of the object. Perhaps a better name
for this would be Accessible. I guess your plan is to implement a
separate Accessor class to do this instead?
Ralph
Accessors (was Re: Adding cocoon.suicide() to the FOM API.)
Posted by Sylvain Wallez <sy...@apache.org>.
Daniel Fagerstrom wrote:
> Sylvain Wallez wrote:
>
>> Daniel Fagerstrom wrote:
>
>
> <snip/>
>
>>> 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".
>
>
> Its also ok.
>
>> Now talking about abstraction, it will be more difficult to write
>> something more abstract than an interface having a single "Object
>> get()" method ;-)
>
>
> The Component marker interface was a little bit more abstract ;)
Oh yes, forgot about that one ;-)
>> Well...
>
>
> I can agree that it seem to break some common ideas about good coding
> practice. But we have been through the arguments and it seem OK. We
> probably find out if it works when we start to implement and integrate it.
Oh yes, sure. I totally agree with the concept. It's not a factory and
it's not an object holder as depending on the implementation it can be
either or even something else. So accessor is fine!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Adding cocoon.suicide() to the FOM API.
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Sylvain Wallez wrote:
> Daniel Fagerstrom wrote:
<snip/>
>> 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".
Its also ok.
> Now talking about abstraction, it will be more difficult to write
> something more abstract than an interface having a single "Object
> get()" method ;-)
The Component marker interface was a little bit more abstract ;)
> Well...
I can agree that it seem to break some common ideas about good coding
practice. But we have been through the arguments and it seem OK. We
probably find out if it works when we start to implement and integrate it.
/Daniel
Re: Adding cocoon.suicide() to the FOM API.
Posted by Sylvain Wallez <sy...@apache.org>.
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 }
Re: Adding cocoon.suicide() to the FOM API.
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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
Re: Adding cocoon.suicide() to the FOM API.
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
>
> 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.
>
> 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
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Adding cocoon.suicide() to the FOM API.
Posted by Sylvain Wallez <sy...@apache.org>.
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.
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?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Adding cocoon.suicide() to the FOM API.
Posted by Vadim Gritsenko <va...@reverycodes.com>.
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?
Another suggestion:
cocoon.terminate();
As in "terminate flow". Shorter, and supposedly clearer than suicide.
Vadim
Re: Adding cocoon.suicide() to the FOM API.
Posted by Bertrand Delacretaz <bd...@apache.org>.
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 ;-)
-Bertrand
Re: Adding cocoon.suicide() to the FOM API.
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
> Hi all,
>
> There are some flowscript use cases where we want to stop the current
> flowscript without creating a continuation, as we don't want to the user
> to go back to the script.
>
> An example is a "login" function where the caller function expects this
> function to exit only if login is successful, but that has to handle
> e.g. a registration process that includes a "cancel" button.
>
> 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()".
>
> Any objection?
hmmm, cocoon.suicide() smells of 'shutdown the whole thing' which is
kind of allarming :-)
I don't mind the functionality being added, but I would like a less
worrying name for it.
--
Stefano.
Re: Adding cocoon.suicide() to the FOM API.
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Sylvain Wallez wrote:
> Hi all,
>
> There are some flowscript use cases where we want to stop the current
> flowscript without creating a continuation, as we don't want to the user
> to go back to the script.
>
> An example is a "login" function where the caller function expects this
> function to exit only if login is successful, but that has to handle
> e.g. a registration process that includes a "cancel" button.
>
> This is currently possible using "FOM_Cocoon.suicide()" which is what is
or by creating another top level continuation.
> used internally by cocoon.sendPageAndWait (see fom_system.js), and I
> would like to make this more visible by being available as
> "cocoon.suicide()".
>
> Any objection?
+1
Vadim