I don't have any issue with actually providing implementations like this, although that wasn't my line of thinking. I was thinking more of changing method signatures in things like ActionContext to use Objects rather than the concrete class. So for example in ActionContext...replacing
void setAction(Action action); Action getAction() void setActionForm(ActionForm form); ActionForm getActionForm();
with something like...
void setExecutable(Object executable); Object getExecutable() void setFormBean(Object form); Object getFormBean();
I don't know... type safety and elimination of casts is one of the things I like most about ActionContext.
Now, why wouldn't you have void setExecutable(Actionable executable) (or whatever naming)
It seems like there are others here who will advocate even more strongly than I that using Objects everywhere is giving up valuable elements of rigor/clarity/predictability/etc. And even if they'll advocate more strongly, I'm inclined to go along with that.
Now, in my specific use case, I could change my subclass of CreateAction to something like CreateActionCommand instead of replacing the base CreateAction, and then later in the chain add my own "ExecuteActionCommand" and do all of this in my own code instead of in Struts. That's what I'll do for now if controversy continues to stir. I'm just looking for the real risks of having Action implement ActionCommand -- is this the thing which causes Jack to shiver? Do others share his concern about this being a slippery slope? I know I'm not the only one who had previously designed my own class to encapsulate all these things and passed it around in Struts:
At 9:23 AM +0100 3/16/05, Manfred Wolff wrote:
I think there is on little design problem in struts that depends on the history: It would be much better, if Action is an interface. So you would have all possibilites to use POJOs, it must only implement the new Action-Interface. Secondly it were also much better, when the execute-Method must only take a context interface. So you have more flexibility and you have no servlet-things at the paramater signature:
public interface Action { void execute(Context context); }
where Context is also an interface.
I have programmed this approach by myself (http://plstrutsit.sourceforge.net/architecture/index.html), but it were quite better, if this would be integrated in struts - with backwards compatibility to struts 1.1. You only need a new request-processor that can deal with such Action interfaces an can create such contexts.
Joe
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
