You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by "Melzer, Steven" <St...@Paymentech.com> on 2002/07/18 13:34:06 UTC

extending Action issue

Our company has been using struts for about a year now.  We have subclassed
Action and created our own BaseAction to support some additional
functionality and to create an abstraction between changes to Action in the
future and our existing code.  We have done the same with most core Struts
classes.

With 1.1, a new subclass of Action, DispatchAction has been created.  Since
DispatchAction subclasses Action, BaseAction and DispatchAction are at the
same "level".  In order to use DispatchAction and keep the functionality of
BaseAction I have thought of two ways to do it, but neither is optimal.

1) Subclass DispatchAction and put the functions from BaseAction into a
BaseDispatchAction.  The problem is maintaining the same code in two
seperate classes.

2) Turn BaseAction into a composite class and add an Action as a property of
the class.  This would allow the most flexibility since any Action object
could then be used.  The problem is that this would require some sort of
change to either the struts-config.xml and/or to the ActionServlet.  This is
because somewhere after the new BaseAction gets instantiated, an Action
would need to get passed in.

Does anyone have any thoughts on how to solve this problem?

Thanks,
steve 

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: extending Action issue

Posted by Andrew Hill <an...@gridnode.com>.
I tried using your first suggested approach and got tired of it rather
quickly.
I found a third approach was the best bet.
This is to copy and paste the source for struts DispatchAction into a new
class in your application (you could call it BaseDispatchAction or something
like this.) The only difference between this and the original is that this
extends your BaseAction instead of directly extending Action. Your dispatch
actions then extend this class instead of DispatchAction.
It may be a bit crude, but its very quick to implement and works well. Of
course if you upgrade your version of struts and there are changes to
dispatch actions you wont pick them up, and if you import DispatchAction
classes from other apps you will need to modify them to extend your class
and recompile, but if those arent big issues to you, then this is probably
the simplest approach.

-----Original Message-----
From: Melzer, Steven [mailto:Steven.Melzer@Paymentech.com]
Sent: Thursday, July 18, 2002 19:34
To: 'Struts Users Mailing List'
Subject: extending Action issue


Our company has been using struts for about a year now.  We have subclassed
Action and created our own BaseAction to support some additional
functionality and to create an abstraction between changes to Action in the
future and our existing code.  We have done the same with most core Struts
classes.

With 1.1, a new subclass of Action, DispatchAction has been created.  Since
DispatchAction subclasses Action, BaseAction and DispatchAction are at the
same "level".  In order to use DispatchAction and keep the functionality of
BaseAction I have thought of two ways to do it, but neither is optimal.

1) Subclass DispatchAction and put the functions from BaseAction into a
BaseDispatchAction.  The problem is maintaining the same code in two
seperate classes.

2) Turn BaseAction into a composite class and add an Action as a property of
the class.  This would allow the most flexibility since any Action object
could then be used.  The problem is that this would require some sort of
change to either the struts-config.xml and/or to the ActionServlet.  This is
because somewhere after the new BaseAction gets instantiated, an Action
would need to get passed in.

Does anyone have any thoughts on how to solve this problem?

Thanks,
steve

--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>