Re: subclassing frustrations
Here is how I have done actions, and yes they are an interface, repost
from user list:
From basicPortal, using disptaching (it also uses event object to
encsulate response,request, forward, formbean, etc.):
protected Object dispatchEvents(ActionEvent ae) {
String parm = ae.getReq().getParameter(DISPATCH_KEY);
if (parm == null)
parm = Default;
// start Dispatching
ActionForward retObj = new ActionForward();
try {
String methodName = on + parm + Exec;
try {
Class args[] = {
Class.forName(org.apache.commons.dispatch.ActionEvent) };
Method eventMethod =
this.getClass().getMethod(methodName, args);
Object objs[] = { ae };
retObj = (ActionForward)eventMethod.invoke(this, objs);
}
catch(NoSuchMethodException e) {
System.out.println(Could not find method +
methodName + (ActionEvent) to invoke.);
}
catch(Exception e) {
e.printStackTrace();
}
} catch (Exception e) {
log(e, this, *** DISPATCHING a + e.toString());
}
return (ActionForward) retObj;
}
David Graham wrote:
I agree that Struts needs more interfaces. I think some classes aren't
interfaces to force you into good design (ie. your form beans can't be
model classes). I disagree with that approach and find it somewhat
condescending to experienced programmers.
My approach would be to make many things interfaces with some standard
implementations to allow easier extensibility. This would also allow
people to design poor systems if they abused this freedom.
David
From: Erik Hatcher [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Subject: Re: subclassing frustrations
Date: Thu, 05 Dec 2002 15:55:16 -0500
Jason Rosenblum wrote:
Erik,
One simple hack is to layer your base Actions on top
of the pre-defined Actions. You could change your
Struts code such that LookupDispatchAction subclasses
BaseAction or BaseAdminAction. It's not convenient but
it should work.
I'm not sure I follow. To invert the inheritance (without modifying
Struts itself) would require me to copy LookupDispatchAction into my
code (and I did this, as BaseLookupDispatchAction) and have it
subclass from my primary base class, such as BaseAction.
Or are you suggesting something other than this?
Actually, it would be a nice feature if you could
supply Struts with the type of your Action class, but
i guess this would only work if there was an Action
interface and an Action factory to create different
implementations.
Yeah, there are lots of ways to accomplish this, but at the very least
an Action really should simply be an interface since its stateless and
the idea is to just implement execute() yourself anyway.
I haven't thought through how this should be done differently, just
that this situation is currently frustrating.
Erik
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
_
Tired of spam? Get advanced junk mail protection with MSN 8.
http://join.msn.com/?page=features/junkmail
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: subclassing frustrations
-Original Message-
From: Erik Hatcher [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 05, 2002 1:48 PM
To: [EMAIL PROTECTED]
Subject: subclassing frustrations
*everything should be an interface* :))
ARG... I'm having some frustrations with the built-in Struts Actions
(yeah, I know, I'm the author of one of them,
LookupDispatchAction, so
I'm guilty!)
I make it a standard practice to subclass Action to form a BaseAction
(using the template pattern, making execute final and calling a new
executeAction method). I then template this further with a
BaseAdminAction which all administrative actions subclass from. This
works all fine and dandy when all I want to do is plain actions.
But what about when I want to use DispatchAction or
LookupDispatchAction? I cannot easily do this. In my last project I
resorted to just cutting and pasting the LookupDispatchAction
code into
a new BaseLookupDispatchAction (which subclassed from my BaseAction),
and went around the very thing I created.
Do others have thoughts on this? Suggestions on how I can
handle this
such that I actually can use the real LookupDispatchAction within a
custom BaseAdminAction subclassed action?
I hope that Struts2 is more interface-centric such that I
don't have to
resort to messing with my inheritance hierarchy to play nicely with
Struts. How that plays out with form beans and the rationale
for them
being an actual class is still unclear to me, but in that case I'm ok
with creating my own BaseForm that extends from ValidatorForm (making
validate final so no developers can mess it up!) - so I
haven't run into
any form bean inheritance issues, only actions.
Thanks,
Erik
It seems to me that just making Action an interface wouldn't even solve
your problem. Your problem is that you want to use inheritance for the
template method pattern, but you also want to use inheritance to reuse
functionality from the LookupDispatchAction. The best solution I can
think of is to have your class subclass BaseAdminAction and delegate to
LookupDispatchAction.
for example
public class MyAction extends BaseAdminAction {
// this is whatever your non-final execute method is called
public ActionForward myExecute(ActionMapping mapping, ... ) {
return new LookupDispatchAction().execute(mapping, ... );
}
}
Even better, create a single LookupDispatchAction in the constructor and
reuse it across requests. I haven't tried anything like this, but I
can't think of any reasons off-hand why it shouldn't work. Any
comments?
--
Tim Moore / Blackboard Inc. / Software Engineer
1899 L Street, NW / 5th Floor / Washington, DC 20036
Phone 202-463-4860 ext. 258 / Fax 202-463-4863
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: subclassing frustrations
Tim Moore wrote:
It seems to me that just making Action an interface wouldn't even solve
your problem. Your problem is that you want to use inheritance for the
template method pattern, but you also want to use inheritance to reuse
functionality from the LookupDispatchAction. The best solution I can
think of is to have your class subclass BaseAdminAction and delegate to
LookupDispatchAction.
for example
public class MyAction extends BaseAdminAction {
// this is whatever your non-final execute method is called
public ActionForward myExecute(ActionMapping mapping, ... ) {
return new LookupDispatchAction().execute(mapping, ... );
}
}
Even better, create a single LookupDispatchAction in the constructor and
reuse it across requests. I haven't tried anything like this, but I
can't think of any reasons off-hand why it shouldn't work. Any
comments?
One reason it won't work this way... LookupDispatchAction is abstract :)
I've given your idea some thought in the past though, and it should work
as long as I create a subclass of LookupDispatchAction to delegate to.
Ugly, but at least it'd work with the existing Struts codebase rather
than me cutting and pasting.
Same situation would apply to DispatchAction too... you'd need to
implement the actual functionality in a separate subclass (or perhaps
anonymous inner classes if you wanted to get tricky with it).
So, your idea is a reasonable one, but its trickier in practice to pull off.
Erik
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: subclassing frustrations
Erik, One simple hack is to layer your base Actions on top of the pre-defined Actions. You could change your Struts code such that LookupDispatchAction subclasses BaseAction or BaseAdminAction. It's not convenient but it should work. Actually, it would be a nice feature if you could supply Struts with the type of your Action class, but i guess this would only work if there was an Action interface and an Action factory to create different implementations. ~Jason --- Erik Hatcher [EMAIL PROTECTED] wrote: *everything should be an interface* :)) ARG... I'm having some frustrations with the built-in Struts Actions (yeah, I know, I'm the author of one of them, LookupDispatchAction, so I'm guilty!) I make it a standard practice to subclass Action to form a BaseAction (using the template pattern, making execute final and calling a new executeAction method). I then template this further with a BaseAdminAction which all administrative actions subclass from. This works all fine and dandy when all I want to do is plain actions. But what about when I want to use DispatchAction or LookupDispatchAction? I cannot easily do this. In my last project I resorted to just cutting and pasting the LookupDispatchAction code into a new BaseLookupDispatchAction (which subclassed from my BaseAction), and went around the very thing I created. Do others have thoughts on this? Suggestions on how I can handle this such that I actually can use the real LookupDispatchAction within a custom BaseAdminAction subclassed action? I hope that Struts2 is more interface-centric such that I don't have to resort to messing with my inheritance hierarchy to play nicely with Struts. How that plays out with form beans and the rationale for them being an actual class is still unclear to me, but in that case I'm ok with creating my own BaseForm that extends from ValidatorForm (making validate final so no developers can mess it up!) - so I haven't run into any form bean inheritance issues, only actions. Thanks, Erik -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: subclassing frustrations
Jason Rosenblum wrote: Erik, One simple hack is to layer your base Actions on top of the pre-defined Actions. You could change your Struts code such that LookupDispatchAction subclasses BaseAction or BaseAdminAction. It's not convenient but it should work. I'm not sure I follow. To invert the inheritance (without modifying Struts itself) would require me to copy LookupDispatchAction into my code (and I did this, as BaseLookupDispatchAction) and have it subclass from my primary base class, such as BaseAction. Or are you suggesting something other than this? Actually, it would be a nice feature if you could supply Struts with the type of your Action class, but i guess this would only work if there was an Action interface and an Action factory to create different implementations. Yeah, there are lots of ways to accomplish this, but at the very least an Action really should simply be an interface since its stateless and the idea is to just implement execute() yourself anyway. I haven't thought through how this should be done differently, just that this situation is currently frustrating. Erik -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: subclassing frustrations
On Thu, 5 Dec 2002, Erik Hatcher wrote: *everything should be an interface* :)) Unless you want to add public methods in some future version -- that breaks all existing implementations of the interface :-)). ARG... I'm having some frustrations with the built-in Struts Actions (yeah, I know, I'm the author of one of them, LookupDispatchAction, so I'm guilty!) I make it a standard practice to subclass Action to form a BaseAction (using the template pattern, making execute final and calling a new executeAction method). I then template this further with a BaseAdminAction which all administrative actions subclass from. This works all fine and dandy when all I want to do is plain actions. But what about when I want to use DispatchAction or LookupDispatchAction? I cannot easily do this. In my last project I resorted to just cutting and pasting the LookupDispatchAction code into a new BaseLookupDispatchAction (which subclassed from my BaseAction), and went around the very thing I created. Do others have thoughts on this? Suggestions on how I can handle this such that I actually can use the real LookupDispatchAction within a custom BaseAdminAction subclassed action? I hope that Struts2 is more interface-centric such that I don't have to resort to messing with my inheritance hierarchy to play nicely with Struts. How that plays out with form beans and the rationale for them being an actual class is still unclear to me, but in that case I'm ok with creating my own BaseForm that extends from ValidatorForm (making validate final so no developers can mess it up!) - so I haven't run into any form bean inheritance issues, only actions. I'm sure that the interfaces versus convenience base classes versus define APIs as abstract classes in Struts2 will be a very lively discussion! There doesn't appear (to me) to be a perfect solution -- we'll need to pick the one(s) that best balance what we decide our goals are. Thanks, Erik Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
