-Original Message-
From: Dakota Jack [mailto:[EMAIL PROTECTED]
====
I have no idea why Craig would say that the RequestProcessor is
somehow related to the Template Method pattern. It just isn't.
====
Ithink that the request processor defines a set of method to
process
TEMPLATE! METHOD! TEMPLATE! METHOD! TEMPLATE METHOD! Scheesch! Help!
The RequestProcessor is NOT difficult to understand. It is a java
CLASS, neither an abstract class nor an interface, which has one
principal public method, viz. process(...) which involves a lot of
code which is further
Here I go, exposing my ignorance of patterns. (No, I have not read
the Gang of Four book on patterns or any other such scriptural
reference.)
Jack --
Exactly what would have to change in the current RequestProcessor for
you to consider it a Template pattern?
-- Jeff
On Wed, 9 Mar 2005
Hi, Jeff,
I am going to say some really intelligent things here, so listen up. ///;-)
The Template Method, not Template merely, pattern is really clear,
well understood, a matter of public record, and not really a subject
of debate. What I think is really irrelevant.
The RequestProcessor is
Well maybe other than the singleton pattern :)
snip
I don't know, in fact, if a single class can have a pattern. I think
that most, if not all, of the patterns only make sense in combination
with other classes.
/snip
-
To
- pre·scrip·tive·ly adverb
G'day!
Jack
On Wed, 9 Mar 2005 14:28:37 -0500, Jeff Beal [EMAIL PROTECTED] wrote:
Accidentally replied to only Jack.
-- Forwarded message --
From: Jeff Beal [EMAIL PROTECTED]
Date: Wed, 9 Mar 2005 14:23:35 -0500
Subject: Re: Why Template Method instead
On Mar 09, 2005, at 23:11, Jeff Beal wrote:
For anybody still interested in knowing whether or not we are allowed
to call the Struts RequestProcessor an example of Template Method
Pattern.
Arguing about one design cult versus another :P
On the diffusion of Christopher Alexander's 'A Pattern
Jeff,
Not to rain on the parade but the parenthetical abstract to me doesn't
mean optional but it is a definition of the style of class. Its sort
of like: we need a (male) soldier to join the infantry. Male is not
optional - it is a description of the type of soldier. (my old military
sense
On Wed, 9 Mar 2005 23:13:41 +0100, Leon Rosenberg
[EMAIL PROTECTED] wrote:
Just to clarify things:
Gamma et all Design Pattern page 326:
Behavioral patterns | template method
By defining some of the steps of an algorithm using _abstract_ operations...
Which implies abstract class in
And implies what in JavaScript? (that does not have
'abstract' anything)
JavaScript isn't a programming language, it's a disease, so design patterns
do not apply here.
(-: Leon :-)
-
To unsubscribe, e-mail: [EMAIL
And implies what in JavaScript? (that does not have
'abstract' anything)
JavaScript isn't a programming language, it's a disease, so design patterns
do not apply here.
(-: Leon :-)
-
To unsubscribe, e-mail: [EMAIL
LOL And, it also does not imply abstract class in C, nag nab it!
On Wed, 9 Mar 2005 17:26:10 -0500, Jeff Beal [EMAIL PROTECTED] wrote:
On Wed, 9 Mar 2005 23:13:41 +0100, Leon Rosenberg
[EMAIL PROTECTED] wrote:
Just to clarify things:
Gamma et all Design Pattern page 326:
Behavioral
Just so you know, Jeff, your references come from
http://home.earthlink.net/~huston2/dp/patterns.html
which is really useful. I really don't care how you use the term. Go
ahead and mean anything you like.
On Wed, 9 Mar 2005 17:26:10 -0500, Jeff Beal [EMAIL PROTECTED] wrote:
On Wed, 9 Mar
I have no idea why Craig would say that the RequestProcessor is
somehow related to the Template Method pattern. It just isn't.
Are you talking about org.apache.struts.action.RequestProcessor?
Even if its not a shining textbook example of Template, it most
certainly is related to that pattern.
Hi, Joe,
The RequestProcesser could have been but is not related at all to the
Template Method pattern. More on that below.
The real reason for this discussion is the following. It is fine that
we are temporarily using the Template Method with CoR from
commons-chain to solve the problems
C'mon man, for all intesive purposes its a Template -- it defines an
algorithm that subclasses can override. As far as a way to specific
alternative implementations -- there is, the controller element. But
to me this whole conversation is moot. IMO, chain alleviates theses
issues ... if you
Joe Germuska wrote:
I have no idea why Craig would say that the RequestProcessor is
somehow related to the Template Method pattern. It just isn't.
Are you talking about org.apache.struts.action.RequestProcessor? Even
if its not a shining textbook example of Template, it most certainly
is
With all due respect, Bill, I don't think this is quibbling. The
actual use of these patterns has far-reaching consequences and this
loose way of talking about them IMHO is not helpful. For example,
if the RequestProcessor were a template, it would have *had* to have
been plugged into the
Michael -- I mean Dakota -- whatever ... as long as you continue
publish baiting posts like this my guess is that people won't want to
give you the time of day.
On 2005-03-05 23:34:06 -0500, Dakota Jack [EMAIL PROTECTED] said:
I inquired why the Template Method pattern is being used with
You are probably right, Bill. How to approach this has been a mystery
to me. But, I do think you are right about this and probably this is
really ineffective.
Jack
On Sun, 6 Mar 2005 17:00:41 -0500, Bill Siggelkow
[EMAIL PROTECTED] wrote:
Michael -- I mean Dakota -- whatever ... as long as
Dakota Jack wrote:
You are probably right, Bill. How to approach this has been a mystery
to me.
Everything good in the world starts with a desire to see others succeed.
Erik
But, I do think you are right about this and probably this is
really ineffective.
Jack
On Sun, 6 Mar 2005 17:00:41 -0500,
I think it's probably usually good to question Template when the
realization of it comes via class inheritance.
However, I'm confused. I read Bill's article (first pass anyway -- and
I'm new to Commons Chain), and I'm still not seeing where exactly
Template is implemented in Commons Chain. He
I think I stated the problem badly, Eric. If you look at the
implementations of commons-chain you will see the implementations tend
to use Template Method. The chain is used to solve the rather
troublesome problems with that pattern, and yet the people who go to
all the trouble to change to
I guess I focused on the backward compatibility issue, which I did
not understand at all. Thanks.
On Sun, 6 Mar 2005 19:09:45 -0500, Ted Husted [EMAIL PROTECTED] wrote:
Joe and Bill did respond.
* http://www.mail-archive.com/dev%40struts.apache.org/msg07346.html
I don't think anyone is
I guess here's a way I can restate my question.
I'm with you on choosing composition rather than inheritance when it's
possible and sensible. But it's not always obvious where and how
inheritance can be replaced by composition. I find it to be a
challenging part of programming. So that's why I
On Sat, 5 Mar 2005 20:34:06 -0800, Dakota Jack [EMAIL PROTECTED] wrote:
I inquired why the Template Method pattern is being used with Commons
Chain instead of Strategy, but never got an answer.
Back in town (for at least one day), and snipping off the flamebait
:-), it's worth philosophizing
The answer to your question, Eric, is that neither pattern is in
commons-chain, as you suggest. The commons chain is a Chain of
Responsibility pattern. My concern was with the Struts classes, and I
think that I have received an answer on my inquiry, viz. that a
refactoring to a Strategy pattern
I think Eric is too modest. This is much deeper than the sugar and
vinegar he gives himself credit for. This is positively Sid Hartha!
///;-)
On Sun, 6 Mar 2005 23:36:00 +0100, Leon Rosenberg
[EMAIL PROTECTED] wrote:
Everything good in the world starts with a desire to see
others
28 matches
Mail list logo
