Re: Direct Action vs. Component Action...
Re: Direct Action vs. Component Action...
- Subject: Re: Direct Action vs. Component Action...
- From: Deepak Nulu <email@hidden>
- Date: Thu, 27 Jul 2006 11:26:45 -0700
Hi Chuck,
Thanks for your response. I am glad to hear that "the difference is
not one that ought to invoke fear in your when choosing an
implementation" :-).
deepak
On Jul 27, 2006, at 10:45 AM, Chuck Hill wrote:
Hi,
On Jul 27, 2006, at 9:23 AM, Deepak Nulu wrote:
Hi David,
Thanks for your quick response (and for your articles in your
blog). I did learn from your articles that direct actions have
static bookmarkable URLs.
But I was wondering if:
(1) I did not need static bookmarkable URLs, and
(2) I needed a session to track user state, and
(3) I am using WOComponent objects to create the web pages, and
(4) the site would have a lot of users at the same time,
then which would be more efficient (from a scalability
standpoint): component actions or direct actions?
It is not properly a scalability question. It is an appropriate
technology question. Direct Action actions associate one specific
URL with one specific method in one specific class. When that URL
arrives, that method is run. This is ideal for adding additional
entry points, providing consistent, editable URLs and generally
making applications more web friendly. When the needs of your
application mesh with the services and constraints of direct
actions, they are a great choice. They have an additional
advantage of being potentially stateless and not requiring a
session. The downside of direct actions is that you need to be
concerned about whether there is a session or not and need to
handle form values yourself.
Component actions are always stateful and hence require a session.
Having a session is more expensive than not having a session, but
the difference is not one that ought to invoke fear in your when
choosing an implementation. If you need state then you need
state. You can still have state and choose between (or use both
of) direct and component actions. Component actions are easier to
use as WO does more of the work for you.
And for the same 4 "requirements" of the site, my other question
was whether I need a session object if all I want to do is make
sure that the user is a registered user. Or can the HTTP server
take care of this. If the answer is either, which is better (again
from a scalability standpoint)?
You could use the standard http authentication, or authenticate and
store the result in a cookie to meet your authentication goals and
not require a session.
Chuck
On
Jul 27, 2006, at 6:47 AM, David LeBer wrote:
On 26-Jul-06, at 11:11 PM, Deepak Nulu wrote:
Hi,
The first part of David LeBer's articles on Direct Actions
(http://david.codeferous.com/?p=63) says the following about
component actions:
"each visitor will receive a relatively heavyweight Session
object, so they may not be appropriate if you expect a lot of
visitors and/or you do not need to track their state. Direct
Action are designed for these situtations."
So if I have a direct action which (1) requires a session
object, and (2) returns a WOComponent object, will it be as
heavy weight as a component action? If not, what is it that
makes component actions relatively heavyweight?
If I have a site where multiple things can be accessed via
direct actions, and if I want some of these things to be
available only to registered users, would I need a session
object for these direct actions?
Deepak,
To be clear, DirectActions have two primary differences between
ComponentActions:
1. They have static (bookmarkable) URLs.
2. The use of a Session is optional.
Sessions are not bad, there are just times when you do not need
one, so why incur the expense? If you need to track user state, a
Session is an easy way to do that and for most applications
that's where it ends.
--
;david
--
David LeBer
Codeferous Software
'co-defer-ous' adj. producing or containing code
site: http://www.codeferous.com
blog: http://david.codeferous.com
--
Toronto Area Cocoa / WebObjects developers group:
http://www.tacow.org
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40global-village.net
This email sent to email@hidden
--
Coming in 2006 - an introduction to web applications using
WebObjects and Xcode http://www.global-village.net/wointro
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems. http://www.global-village.net/products/
practical_webobjects
_______________________________________________
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