Why or why not use WODirectAction rather than WOComponent action, in a session based application ?
Why or why not use WODirectAction rather than WOComponent action, in a session based application ?
- Subject: Why or why not use WODirectAction rather than WOComponent action, in a session based application ?
- From: Stephane Guyot <email@hidden>
- Date: Sun, 25 Sep 2005 14:45:38 +0200
Hi all,
i'm looking for arguments for using simple component action rather
direct action (everywhere).
Currently starting a new WebObjects Application with a team of
developpers, we have a "business portal" to implement. My trouble is
that one guy wants to use WODirectAction for every action of the portal
page , where simple component action are required. I don't like
DirectAction so much, i think they are usefull when we needs to
publish some Actions to other Applications, DirectAction often implied
"spaghetti code", they are hard to maintain because if they are not
used specially for the outside world of the Application it's simply
hard to make distinction between the outside API required and the
internal API required for one application.
It's easy to call a component action from a new DirectAction if needed,
but the reverse is not true. How did you call an action in a
DirectAction from a component ? I need to instantiate the DirectAction
by hand on the server side ?
It's easy to create unwanted session with DirectAction, calling
session() rather than existingSession(), or simply because the stupid
IE browser is loosing cookies ( when working in storeIDsInCookies ).
It's very simple to have access to selectedObject or list of objects in
a WOComponent, usually "WebObjects do it for free", when we needs
special arguments in a DirectAction to determine the "object context",
and then publishing primary key or other things to the client side in
the url.
Well finally, i'm perhaps wrong but ....
any suggestions, comments are wellcome ,
thanks in advance,
Stephane
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden