You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by a k <st...@gmail.com> on 2005/07/18 22:59:56 UTC
Manually Instantiating Action classes
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 that I could think of:
1. Instantiate the MyAction2 class manually and access the myMethod2.
2. Create a Helper class and move the funcationality there so that
both the classes could use it.
I cannot put this in a separate parent class and extend MyAction1 and
MyAction2 from it because I already have another Action class that all
Actions extend from and I would like to adhere to it...if possible.
What is a better way in this scenario? In particular, is it bad to
manually instantiate Action classes?
Thanks!
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Manually Instantiating Action classes
Posted by a k <st...@gmail.com>.
I am going with the helper classes.
Thanks to all who replied!
On 7/18/05, Frank W. Zammetti <fz...@omnytex.com> 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).
>
> One Action instantiating another I think is sometimes not a bad idea
> even today... why incur the overhead of rerunning the request processing
> cycle again?
>
> That being said, I absolutely echo what everyone else said... moving it
> to another class is the first, best solution.
>
> Frank
>
> 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 are the options that I could think of:
> >
> > 1. Instantiate the MyAction2 class manually and access the myMethod2.
> > 2. Create a Helper class and move the funcationality there so that
> > both the classes could use it.
> >
> > I cannot put this in a separate parent class and extend MyAction1 and
> > MyAction2 from it because I already have another Action class that all
> > Actions extend from and I would like to adhere to it...if possible.
> >
> > What is a better way in this scenario? In particular, is it bad to
> > manually instantiate Action classes?
> >
> > Thanks!
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
> >
> >
> >
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Fwd: Manually Instantiating Action classes
Posted by Ed Griebel <ed...@gmail.com>.
Forgot to CC the list!
---------- Forwarded message ----------
From: Ed Griebel <ed...@gmail.com>
Date: Jul 19, 2005 9:45 AM
Subject: Re: Manually Instantiating Action classes
To: a k <st...@gmail.com>
Well, I re-read my answer and it wasn't very clear at all. You can
definitely pass instance variables into a static method without a
problem. The point I was trying to make is that one needs to be
careful with static fields in the class because it is multithreaded.
In most cases, this multithreading can be ignored, but this is one
time where it can't. Sorry about any confusion.
-ed
On 7/19/05, a k <st...@gmail.com> wrote:
> 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 static members that may change I should be ok,
> right?
>
> I decided to go with the helper class but I am curious about this
> static method and request/session object relation that you mentioned.
>
> Thanks!
>
>
> On 7/18/05, Ed Griebel <ed...@gmail.com> wrote:
> > On 7/18/05, Frank W. Zammetti <fz...@omnytex.com> 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).
> > >
> >
> > Exactly what I've ran into as well! Most of the time I end up
> > refactoring almost all non-trivial logic into separate classes because
> > I have needed them elsewhere.
> >
> > What the original poster may be able to get away with is making the
> > method public static in the action. It's a hack, but it will get you
> > running quickly. Once you get it tested and working it's easy to move
> > the method(s) to a helper class, espcially if you are using an IDE
> > that supports refactoring like Eclipse or IDEA. 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.
> >
> > Good luck!
> > -ed
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Manually Instantiating Action classes
Posted by a k <st...@gmail.com>.
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 static members that may change I should be ok,
right?
I decided to go with the helper class but I am curious about this
static method and request/session object relation that you mentioned.
Thanks!
On 7/18/05, Ed Griebel <ed...@gmail.com> wrote:
> On 7/18/05, Frank W. Zammetti <fz...@omnytex.com> 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).
> >
>
> Exactly what I've ran into as well! Most of the time I end up
> refactoring almost all non-trivial logic into separate classes because
> I have needed them elsewhere.
>
> What the original poster may be able to get away with is making the
> method public static in the action. It's a hack, but it will get you
> running quickly. Once you get it tested and working it's easy to move
> the method(s) to a helper class, espcially if you are using an IDE
> that supports refactoring like Eclipse or IDEA. 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.
>
> Good luck!
> -ed
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Manually Instantiating Action classes
Posted by Ed Griebel <ed...@gmail.com>.
On 7/18/05, Frank W. Zammetti <fz...@omnytex.com> 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).
>
Exactly what I've ran into as well! Most of the time I end up
refactoring almost all non-trivial logic into separate classes because
I have needed them elsewhere.
What the original poster may be able to get away with is making the
method public static in the action. It's a hack, but it will get you
running quickly. Once you get it tested and working it's easy to move
the method(s) to a helper class, espcially if you are using an IDE
that supports refactoring like Eclipse or IDEA. 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.
Good luck!
-ed
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Manually Instantiating Action classes
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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 bad idea
even today... why incur the overhead of rerunning the request processing
cycle again?
That being said, I absolutely echo what everyone else said... moving it
to another class is the first, best solution.
Frank
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 are the options that I could think of:
>
> 1. Instantiate the MyAction2 class manually and access the myMethod2.
> 2. Create a Helper class and move the funcationality there so that
> both the classes could use it.
>
> I cannot put this in a separate parent class and extend MyAction1 and
> MyAction2 from it because I already have another Action class that all
> Actions extend from and I would like to adhere to it...if possible.
>
> What is a better way in this scenario? In particular, is it bad to
> manually instantiate Action classes?
>
> Thanks!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
AW: Manually Instantiating Action classes
Posted by Leon Rosenberg <st...@anotheria.net>.
> -----Ursprüngliche Nachricht-----
> Von: Michael Jouravlev [mailto:jmikus@gmail.com]
> Gesendet: Montag, 18. Juli 2005 23:36
> An: Struts Users Mailing List
> Betreff: Re: Manually Instantiating Action classes
>
> On 7/18/05, Leon Rosenberg <st...@anotheria.net> wrote:
> > First choice action hierarchy
> > Second choice helper classes
> > Or maybe a good combination of both :-)
>
> Chaining? ;-)
Sure, why not, but I think this is an implementation detail;
first he has to decide which way to go, then, how to get there :-)
Regards
Leon
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Manually Instantiating Action classes
Posted by Michael Jouravlev <jm...@gmail.com>.
On 7/18/05, Leon Rosenberg <st...@anotheria.net> wrote:
> First choice action hierarchy
> Second choice helper classes
> Or maybe a good combination of both :-)
Chaining? ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Manually Instantiating Action classes
Posted by Leon Rosenberg <st...@anotheria.net>.
Agreed with dave,
But maybe another point,
You said you already have a class all actions extend, right?
Is it said somewhere that the actions can extend one class only? I mean, if
it's needed by the architecture, you can create a whole action hierarchy...
And if you'd need multiple inheritance - use delegates :-)
As to you another option, I know different people on this list like to
instantiate actions directly, but as for me,
it's forbidden in my team, because it brings a lot of problems with
ressource sharing if you count to instantiate an action once, and do it
multiple times.
So in my opinion:
First choice action hierarchy
Second choice helper classes
Or maybe a good combination of both :-)
Regards
Leon
> -----Ursprüngliche Nachricht-----
> Von: Dave Newton [mailto:newton@pingsite.com]
> Gesendet: Montag, 18. Juli 2005 23:18
> An: Struts Users 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 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
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Manually Instantiating Action classes
Posted by Dave Newton <ne...@pingsite.com>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Manually Instantiating Action classes
Posted by Leon Rosenberg <st...@anotheria.net>.
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, Action MyAction1 needs to access method myMethod2 in Action
> >MyAction2. Here are the options that I could think of:
> >
> >
> IMHO this breaks OO principle: a class to have one and only one purpose.
> So instantiate MyAction2 just to use one of it's methods is a bad practice.
>
It is a bad practice, but it DOES NOT break the OO principle, that's why
OO is an obsolescent model.
If you look into component-oriented or responsibility (contract) -
oriented architectures, you would find this principle :-)
regards
Leon
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Manually Instantiating Action classes
Posted by Borislav Sabev <b....@eventsoft.de>.
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 are the options that I could think of:
>
>
IMHO this breaks OO principle: a class to have one and only one purpose.
So instantiate MyAction2 just to use one of it's methods is a bad practice.
>1. Instantiate the MyAction2 class manually and access the myMethod2.
>2. Create a Helper class and move the funcationality there so that
>both the classes could use it.
>
>I cannot put this in a separate parent class and extend MyAction1 and
>MyAction2 from it because I already have another Action class that all
>Actions extend from and I would like to adhere to it...if possible.
>
>
So why not to put this myMethod2 in this base class. But there is other
good rule of thumb: composition instead of inheritance, so I'm
definitely for option 2 - helper class.
>What is a better way in this scenario? In particular, is it bad to
>manually instantiate Action classes?
>
>Thanks!
>
>
>
Regards
Borislav
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org