///;-)
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
<[EMAIL P
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
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 ActionContextU
I don't think this is comparable. Map has those methods in relation
to its basic operations. They are not utilities.
On Thu, 31 Mar 2005 13:02:34 -0500, Ted Husted <[EMAIL PROTECTED]> wrote:
> On Thu, 31 Mar 2005 07:07:53 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote:
> > I cannot think of "[m]a
D'oh! Didn't see the obvious before. Is it Friday already because my
brain apparently thinks it is! :)
Frank
Craig McClanahan wrote:
On Thu, 31 Mar 2005 15:06:05 -0500 (EST), Frank W. Zammetti
<[EMAIL PROTECTED]> wrote:
On Thu, March 31, 2005 1:57 pm, Craig McClanahan said:
Every single time I'
On Thu, 31 Mar 2005 15:06:05 -0500 (EST), Frank W. Zammetti
<[EMAIL PROTECTED]> wrote:
> On Thu, March 31, 2005 1:57 pm, Craig McClanahan said:
> > Every single time I've created a static utilities class (and that
> > includes things like Commons BeanUtils) I have regretted it, because
> > users ar
On Thu, 31 Mar 2005 15:06:05 -0500 (EST), Frank W. Zammetti
<[EMAIL PROTECTED]> wrote:
> On Thu, March 31, 2005 1:57 pm, Craig McClanahan said:
> > Every single time I've created a static utilities class (and that
> > includes things like Commons BeanUtils) I have regretted it, because
> > users ar
On Thu, March 31, 2005 1:57 pm, Craig McClanahan said:
> 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 don't follow... isn't the
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.
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...
--
Frank W. Zammetti
Founder and Chief Software Archi
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/doc
On Thu, 31 Mar 2005 05:55:27 -0500, Ted Husted <[EMAIL PROTECTED]> wrote:
>
> So long as people follow our advice, and extend the base class, they
> will be protected from changes to the API. If someone chooses to
> implement the interface from scratch, then they will have some more
> work to
I, for one, am of one mind with Hubert on these questions. I
particularly favor the one context option.
Jack
On Tue, 29 Mar 2005 16:36:56 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote:
> At 3:15 PM -0600 3/29/05, Hubert Rabago wrote:
> >I think the bigger question is, what happens in the future
I think we would want to strongly recommend that people use the
ActionContext as a base class, as Joe is doing in his application.
Just as is done with the Commons Chain members.
So long as people follow our advice, and extend the base class, they
will be protected from changes to the API. If some
> -Original Message-
> From: Joe Germuska [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 30, 2005 9:46 AM
> To: [EMAIL PROTECTED]; dev@struts.apache.org
> Subject: RE: ActionContext convenience methods
>
>
> At 8:23 AM -0600 3/30/05, <[EMAIL PROTECTED]&g
At 8:23 AM -0600 3/30/05, <[EMAIL PROTECTED]> wrote:
> -Original Message-
From: Joe Germuska [mailto:[EMAIL PROTECTED]
Sent: Monday, March 28, 2005 10:21 PM
To: dev@struts.apache.org
Subject: ActionContext convenience methods
I'd like some opinions from the community h
> -Original Message-
> From: Joe Germuska [mailto:[EMAIL PROTECTED]
> Sent: Monday, March 28, 2005 10:21 PM
> To: dev@struts.apache.org
> Subject: ActionContext convenience methods
>
>
> I'd like some opinions from the community here. As I get back to
Perhaps, although I think it's more about preventing people from
implementing interfaces on classes which really do something else.
In any case, the common approach in many APIs is to strongly
encourage people to implement ActionContext by extending
ActionContextBase, and maybe that's reason en
At 3:15 PM -0600 3/29/05, Hubert Rabago wrote:
I think the bigger question is, what happens in the future when we
decide we need to make changes to the ActionContext interface? I
don't have an answer right now, but I felt like I needed to ask the
question.
I think this is one of the reasons Craig
I think the bigger question is, what happens in the future when we
decide we need to make changes to the ActionContext interface? I
don't have an answer right now, but I felt like I needed to ask the
question.
I think this is one of the reasons Craig often cites when asked about
the use of superc
I'd like some opinions from the community here. As I get back to
building out an app based around Struts 1.3, I find myself adding
some familiar convenience methods to my local subclass of
ActionContext.
I can totally understand where some folks would not want
ActionContext to get too weighed
21 matches
Mail list logo
