struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: subclassing frustrations
Date Fri, 06 Dec 2002 02:54:50 GMT

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

> Thanks,
> 	Erik


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message