Re: Why or why not use WODirectAction rather than WOComponent action, in a session based application ?
Re: Why or why not use WODirectAction rather than WOComponent action, in a session based application ?
- Subject: Re: Why or why not use WODirectAction rather than WOComponent action, in a session based application ?
- From: David LeBer <email@hidden>
- Date: Sun, 25 Sep 2005 10:09:02 -0400
On 25-Sep-05, at 8:45 AM, Stephane Guyot wrote:
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.
Like most things, choosing DirectActions over ComponentActions for
purely 'religious' reasons is just wrong.
In general I use DirectActions instead of ComponentActions when they
make sense:
1. They need to be book-markable.
2. Or they need to be accessed from an external source.
3. Or I don't want a session.
In general I use ComponentActions where they make sense:
1. I don't need them to be book-markable.
2. And I need or don't mind a session.
3. Or I am prototyping and the speed of development is valuable.
I've built entire content driven website apps in WebObjects using
pure DirectAction calls because they needed to be book-markable. The
CMS backend applications were built completely with ComponentActions
because it didn't.
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 ?
Most WODynamicElements have built-in support for generating
DirectActions, so does WORedirect. I've never found creating
DirectAction calls from my Components particularly onerous.
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.
Yes, this would be a requirement for DirectActions. I don't publish
my PKs though, I use a secondary ID that performs the same function
without requiring that.
Finally I've not had the kind of problems you've experienced with
Session management within DirectActions, in my experience WebObjects
just does the right thing.
--
;david
--
David LeBer
"I am codeferous!"
Codeferous Software
site: http://www.codeferous.com
blog: http://david.codeferous.com
_______________________________________________
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