struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dakota Jack <dakota.j...@gmail.com>
Subject Re: ActionContext convenience methods
Date Thu, 31 Mar 2005 23:22:05 GMT
///;-)  

Truth is that I agree with Craig on most things, except JSF.  I have
been an admirer and a student of Craig for a long time.  That does not
mean I don't know how to disagree, however, as you so insightfully
note.  LOL

Jack


On Thu, 31 Mar 2005 17:07:48 -0500, Frank W. Zammetti
<fzlists@omnytex.com> wrote:
> 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 <craigmcc@gmail.com>
wrote:
> >
> >>On Thu, 31 Mar 2005 13:09:29 -0500 (EST), Frank W. Zammetti
> >><fzlists@omnytex.com> 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 <dakota.jack@gmail.com>
> >>>>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: dev-unsubscribe@struts.apache.org
> >>>>For additional commands, e-mail: dev-help@struts.apache.org
> >>>>
> >>>>
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>>For additional commands, e-mail: dev-help@struts.apache.org
> >>>
> >>>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >
> >
> >
> 
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
> 
> 


-- 
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message