cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivelin Ivanov" <ive...@apache.org>
Subject Re: AbstractAction Poolable?
Date Thu, 11 Apr 2002 12:17:55 GMT

I see.
I didn't realize actions are generally used for things different from user
input handling.


----- Original Message -----
From: "Peter Royal" <proyal@managingpartners.com>
To: <cocoon-dev@xml.apache.org>
Sent: Wednesday, April 10, 2002 10:00 PM
Subject: Re: AbstractAction Poolable?


> On Wednesday 10 April 2002 10:59 pm, Ivelin Ivanov wrote:
> > Not being an Avalon specialist, I think that Nick has a good point.
> > Why shouldn't the AbstractAction be poolable?
> > It's been an inconvenience that Strut's Actions must be thread safe.
> > Actions usually deal with forms and tend to hold on to a bunch of
stateful
> > objects. (validatiors, a list of timezones, a list of countries, user
> > locale, session, request, etc.)
> > It feels cleaner when you don't need to pass these objects around during
an
> > Action execution.
> > Of course you can use ThreadLocal and get away, but it'll make UI
coders'
> > lifes easier if they don't need to think threads. Memory is not as
> > expensive as it used to be ...
>
> With AbstractAction *not* having a lifestyle interface (Poolable /
> ThreadSafe) the component author that subclasses AbstractAction then has
the
> choice of what to use.
>
> Yes, you are right for form validation. My form validation action is
> Poolable, but its the only one that I've got that's poolable. The rest of
my
> actions are ThreadSafe because they're much simpler and don't need to keep
as
> much stateful information (or it can be easily passed as method
parameters).
>
> The current way is best because it gives you the action author the power
to
> best decide what to use for the current situation :)
> -pete
>
> --
> peter royal -> proyal@managingpartners.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message