On Thu, 31 Mar 2005 13:09:29 -0500 (EST), Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > How about just introducing something like an ActionContextUtils class? > Just a bunch of static methods for these kinds of utility functions? Make > it have no direct relationship to ActionContext itself, i.e., no > interfaces and no superclass...
Every single time I've created a static utilities class (and that includes things like Commons BeanUtils) I have regretted it, because users are stuck with the functionality you provide and cannot customize. I'd suggest that, if you want ActionContext to be an interface, keep it's signature related to the behavioral aspects, and put all your helper methods in the convenience base class. Besides keeping the interface lean and mean, the existence of the helper methods encourages the behavior you want, that users subclass the convenience base class and will suffer less from changes in the interface definition later. (Shale follows this advice with ViewController ... the basic interface is very small (four lifecycle events), but the standard base class has a bunch of helpers). Craig > > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > > On Thu, March 31, 2005 1:02 pm, Ted Husted said: > > On Thu, 31 Mar 2005 07:07:53 -0800, Dakota Jack <[EMAIL PROTECTED]> > > wrote: > >> I cannot think of "[m]any" or even "any" larger Sun interfaces that > >> include utility methods. Which ones do you have in mind? > > > > Map, for example, includes several optional operations. > > > > * http://java.sun.com/j2se/1.3/docs/api/java/util/Map.html > > > > Another strategy is to have two standard ActionContext > > implementations. One would contain only the operations required by the > > framework. The other, a subclass of the first, would also contain > > optional operations. > > > > Spring uses this approach to good effect with its ObjectFactory and > > ApplicationContext members. Likewise, we could have a CoreContext > > with only what Struts itself needs to get through the day. A larger > > ApplicationContext could include the other optional methods that we > > find useful when writing Struts applications. > > > > -Ted. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
