You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Erik Hatcher <ja...@ehatchersolutions.com> on 2002/12/05 19:47:45 UTC
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
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: subclassing frustrations
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: subclassing frustrations
Posted by Jason Rosenblum <ja...@yahoo.com>.
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
<ja...@ehatchersolutions.com> 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:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: subclassing frustrations
Posted by "Craig R. McClanahan" <cr...@apache.org>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>