On Wed, 2005-07-20 at 08:43 +0200, Borislav Sabev wrote:
> a k wrote:
>
> >In the process of writing an Action class, I realized that it needs
> >some application functionality (not general utility kinda
> >functionality) that is already part of a method in a different Action
> >class.
> >
> >So,
a k wrote:
In the process of writing an Action class, I realized that it needs
some application functionality (not general utility kinda
functionality) that is already part of a method in a different Action
class.
So, Action MyAction1 needs to access method myMethod2 in Action
MyAction2. Here a
Forgot to CC the list!
-- Forwarded message --
From: Ed Griebel <[EMAIL PROTECTED]>
Date: Jul 19, 2005 9:45 AM
Subject: Re: Manually Instantiating Action classes
To: a k <[EMAIL PROTECTED]>
Well, I re-read my answer and it wasn't very clear at all. You ca
I am not sure I understand when you say:
Don't make them static
> if they depend on session or request state, as you'll shoot yourself
> in the foot due to the implicit threading in the app server.
Why can't I pass in a request object to a static method? As long as it
doesn't depend on other stat
On 7/18/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> I used to do a lot of this back when I wasn't as clear on why Actions
> shouldn't contain actual code (this started when I was using a custom
> framework my company build that had examples that didn't make it clear
> you shouldn't do this).
I am going with the helper classes.
Thanks to all who replied!
On 7/18/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> I used to do a lot of this back when I wasn't as clear on why Actions
> shouldn't contain actual code (this started when I was using a custom
> framework my company build that
I used to do a lot of this back when I wasn't as clear on why Actions
shouldn't contain actual code (this started when I was using a custom
framework my company build that had examples that didn't make it clear
you shouldn't do this).
One Action instantiating another I think is sometimes not a
> -Ursprüngliche Nachricht-
> Von: Michael Jouravlev [mailto:[EMAIL PROTECTED]
> Gesendet: Montag, 18. Juli 2005 23:36
> An: Struts Users Mailing List
> Betreff: Re: Manually Instantiating Action classes
>
> On 7/18/05, Leon Rosenberg <[EMAIL PROTECTED]> wro
> -Ursprüngliche Nachricht-
> Von: Michael Jouravlev [mailto:[EMAIL PROTECTED]
> Gesendet: Montag, 18. Juli 2005 23:36
> An: Struts Users Mailing List
> Betreff: Re: Manually Instantiating Action classes
>
> On 7/18/05, Leon Rosenberg <[EMAIL PROTECTED]> wro
On 7/18/05, Leon Rosenberg <[EMAIL PROTECTED]> wrote:
> First choice action hierarchy
> Second choice helper classes
> Or maybe a good combination of both :-)
Chaining? ;-)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For addition
In the process of writing an Action class, I realized that it needs
some application functionality (not general utility kinda
functionality) that is already part of a method in a different Action
class.
So, Action MyAction1 needs to access method myMethod2 in Action
MyAction2. Here are the options
a k wrote:
What is a better way in this scenario? In particular, is it bad to
manually instantiate Action classes?
I don't know if it's "bad" per se, but if it's shared functionality then
from an architectural standpoint I would think it'd better to move it
into a helper class.
Dave
--
Mailing List
> Betreff: Re: Manually Instantiating Action classes
>
> a k wrote:
>
> >What is a better way in this scenario? In particular, is it bad to
> >manually instantiate Action classes?
> >
> >
> I don't know if it's "bad" per
Mailing List
> Betreff: Re: Manually Instantiating Action classes
>
> a k wrote:
>
> >What is a better way in this scenario? In particular, is it bad to
> >manually instantiate Action classes?
> >
> >
> I don't know if it's "bad" per
14 matches
Mail list logo
