Hoouzah, I could not agree more. Please listen to this. Jack
On Thu, 31 Mar 2005 10:57:45 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote: > 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] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
