Wow, Jack agrees with Craig about something?!?
I guess I can book that ski trip to Hades now :)
Frank
Dakota Jack wrote:
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]
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
