I might have missed something. See below. ----- Original Message ----- From: "Jason Carreira" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, July 02, 2003 8:26 PM Subject: RE: [OS-webwork] WebWork2, here I come!
See below... > -----Original Message----- > From: Brock Bulger [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 02, 2003 6:47 PM > To: [EMAIL PROTECTED] > Subject: Re: [OS-webwork] WebWork2, here I come! > > > Here are my observations on the Action issue: > > From a framework standpoint it doesn't really matter if there > is an explicit > execute() method to call on the underlying object. The > default behavior is to call this method if no method is > specified. So I don't think we lose anything by changing the > return type on those methods to Object. > Umm... We're not talking about changing the return type... We're talking about removing the Action Interface. b: If you remove the Action interface you have to do something with the getAction() method on the ActionProxy, right? My test cases usually have to cast this object to ValidationAware, thus returning Object doesn't really change much (ie you're still going to have to cast it). > From a terminology standpoint and for consistency, I think > the Action interface should retain the execute() method. > Developers associate "action" objects as implementing a > specific interface and I think the framework should leverage > this association. And that to me implies that the > ActionSupport class should continue to implement the Action > interface and the associated execute() method. > > Now bear with me. > > Create a new class (or rename the BaseActionSupport) called > CommandSupport (for command driven actions mind you) that > implements everything in the current BaseActionSupport minus > the Action interface. This class will be subclassed by anyone > wanting to declare their own execution methods while > providing all the validation/locale support existing in ActionSupport. > > Then the only issue is the result types (success, error, etc) > which could be refactored into a separate interface that both > ActionSupport and CommandSupport implement. In the end you > would probably have something like: > > public interface ResultTypes { > // or another name that floats your boat > public static final String SUCCESS = "success"; > // etc > } > > public interface Action { > public String execute() throws Exception; > } > > public class CommandSupport implements ResultTypes, > ValidationAware, LocaleAware, Serializable { } > > public class ActionSupport extends CommandSupport implements > Action { } > > This should give most people the flexibility to do what they > want. Thoughts? > > - Brock > I don't see why we'd want to do this... If we don't remove the execute() method, there's no reason to create a separate interface without it. b: I thought that was the whole point?! You didn't want to tie your actions explicitly to the execute() method. I'm all in favor of leaving the Action class and ActionSupport as is! I was just suggesting a way to leverage the code in ActionSupport without mandating the use of execute(). I agree with your comment 100%. Jason ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
