You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Dakota Jack <da...@gmail.com> on 2005/03/06 05:36:05 UTC
Re: How Strategy Relates to CoR
I gave you a specific, but you did not respond, Joe. Can you tell me why?
On Wed, 23 Feb 2005 09:13:57 -0800, Dakota Jack <da...@gmail.com> wrote:
> Presently, the actions follow the Template Method pattern (GoF). This
> pattern is as previously indicated but now referenced specifically
> with struts-chain:
>
> 1. TEMPLATE METHOD FOR POPULATING THE ACTION FORM IN 1.3
>
> ABSTRACT TEMPLATE
>
> public abstract class AbstractPopulateActionForm implements Command {
> public boolean execute(Context context) throws Exception {
> // do stuff
> reset(actionCtx, actionConfig, actionForm);
> populate(actionCtx, actionConfig, actionForm);
> handleCancel(actionCtx, actionConfig, actionForm);
> return (false);
> }
>
> protected abstract void reset(ActionContext context,
> ActionConfig actionConfig,
> ActionForm actionForm);
>
> protected abstract void populate(ActionContext context,
> ActionConfig actionConfig,
> ActionForm
> actionForm) throws Exception;
>
> protected String trimParameterName(ActionConfig actionConfig, String name) {
> // do stuff
> return stripped;
> }
>
> protected void handleCancel(ActionContext context,
> ActionConfig actionConfig,
> ActionForm actionForm)
> throws Exception {
> // do stuff
> }
> }
>
> IMPLEMENTATION OF TEMPLATE
>
> public class PopulateActionForm extends AbstractPopulateActionForm {
> private static final Log log = LogFactory.getLog(PopulateActionForm.class);
>
> protected void populate(ActionContext context,
> ActionConfig actionConfig,
> ActionForm actionForm) throws Exception {
> // do stuff
> }
>
> protected void reset(ActionContext context,
> ActionConfig actionConfig,
> ActionForm actionForm) {
> // do stuff
> }
> }
>
> 2. STRATEGY WAY TO POPULATE FORM IN 1.3
>
> public class PopulateActionForm implements Command {
> private Helper helper;
>
> public void setHelper(Helper helper) {
> this.helper = helper;
>
> public boolean execute(Context context) throws Exception {
> // do stuff
> helper.trimParameterName(actionCtx, actionConfig, actionForm);
> helper.handleCancel(actionCtx, actionConfig, actionForm);
> helper.reset(actionCtx, actionConfig, actionForm);
> helper.populate(actionCtx, actionConfig, actionForm);
> helper.handleCancel(actionCtx, actionConfig, actionForm);
> return (false);
> }
> }
>
> I think you would find that implementing this difference would solve
> most of your problems with conditionals without having to make
> sophisticated "hacks", over-complicate the API, etc. Just a
> suggestion. Maybe I'm all wet.
>
> Jack
>
> On Wed, 23 Feb 2005 08:39:19 -0600, Joe Germuska <Jo...@germuska.com> wrote:
> > At 12:15 AM -0800 2/23/05, Dakota Jack wrote:
> > >In an attempt to simplify an answer to a question by Joe about how
> > >Strategy relates to the questions asked about conditionals and CoR,
> > >here goes..... Hope this is useful.
> > >
> > >CoR is also called "recursive delegation" for obvious reasons, or if
> > >not obvious, easily discovered reasons ala googling. Delegation is a
> > >way of making Composition as powerful for reuse as inheritance (GoF).
> > >Strategy delegates work while making the strategies for handling
> > >identical state various and invisible to the calling class, where the
> > >delegate is an interface with the implementation not revealed to the
> > >parent. The recursive implementation of a Strategy pattern, then,
> > >gives you conditional strategies taking advantage of polymorphism
> > >within a composite pattern. This is, I think, ideal.
> >
> > Agreed -- but can you say specifically where you think we could
> > beneficially apply it to Struts 1.3.x?
> >
> > Joe
> >
> > --
> > Joe Germuska
> > Joe@Germuska.com
> > http://blog.germuska.com
> > "Narrow minds are weapons made for mass destruction" -The Ex
> >
> > ---------------------------------------------------------------------
> > 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~
>
--
"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
Re: How Strategy Relates to CoR
Posted by Dakota Jack <da...@gmail.com>.
This was really helpful, Ted. I would never have guessed this was the
case. Thanks. This explains a lot to me.
On Sun, 6 Mar 2005 19:37:16 -0500, Ted Husted <te...@gmail.com> wrote:
> Just to clarify the process ...
>
> We never "decided" to use Template versus Strategy. Craig started
> coding up one way of doing the request processor as a chain, then Joe
> and others picked up the ball and ran with it.
>
> Absolutely ALL of the routihne development conversations happen here.
>
> The one and only time a "decision" is every really made is when
> somebody commits code.
>
> So far, the code people have written for Struts Chain could be cast as
> using the "Template" pattern. If someone coughs up another working
> implementation that would be easier to extend and support, I'm sure
> we'd be eager to consider the donation.
>
> BUT -- we don't decide in advance that we are going to do this or that
> and then shut the door. People do it, and THEN we decide if we're
> going to keep it.
>
> Right now, the real advantage to the Template is that we already got
> one. The only way that will change is if someone takes the initiative
> and writes another working implementation.
>
> -Ted.
>
--
"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
Re: How Strategy Relates to CoR
Posted by Dakota Jack <da...@gmail.com>.
The helper, for purposes of comparison, just has the abstract methods
that the abstract class requires. You have other options, of course,
but that is the basic idea. This seemingly small difference makes all
the difference, however. The basic problems with the Template Method
that chain fights could be gotten rid of without chain by using
Strategy. However, since the decision has been made to solve the
Template Method problems with chain, you can really clear the air and
use Strategy with chain. There is no need to keep the problem that
chain solves just because you had it before. This make sense to you?
Particulars follow. The basic "drill" out *there* among framework
architects on the differences is as follows, I think:
The only real advantage to the Template Method pattern is that you can
make the template, abstarct class work simply by instantiating a
concrete subclass. You don't have to manage a relationship between
the class and business objects. First, this advantage is irrelevant
when running in an IoC container, so down the road the Template Method
pattern hopefully would not have a single advantage. Second, the
advantages of the Strategy pattern are considerable in contrast:
a. The strategy can be changed at runtime. Concrete inheritance is
defined statically and is inflexible. Composition is better.
b. Multiple strategies might be necessary. With concrete inheritance
all of them are linked. The strategy approach allows them to be mixed
in any combination. I think the Struts developers with v1.3 are
running into these difficulties and it is creating a real problem, if
I am not mistaken.
c. The same strategy interface can be used in multiple classes. A
single use of an expensive instance of a class can be used for
multiple objects' state.
d. You can test it with mock objects.
Jack
On Sun, 6 Mar 2005 16:43:48 -0500, Bill Siggelkow
<bi...@bellsouth.net> wrote:
> One thing that I see is that the PopulateActionForm you supplied is
> essentially the same as the Abstract one -- that is, it defines the
> algorithm in the template -- the difference, of course, being that the
> method implementations are delegated to a Helper instead of left up to
> a concrete subclass (composition vs inheritance). Still, however, the
> methods in Helper must be specified by an interface (which you don't
> show). What would be the scope of this helper? Would it something like
> an interface named PopulateActionFormHelper with a default impl
> provided by Struts or would you propose a more generalized Struts
> Helper? Likewise, how do you propose to set the Helper in the
> PopulateActionForm -- a plug-in or IoC or something else? Furthermore,
> couldn't someone implement this thing pattern anyway by creating their
> own subclass of AbstractPopulateActionForm and delegating from their?
> After all, the implementation has to belong somewhere.
>
> On 2005-03-06 14:12:52 -0500, Dakota Jack <da...@gmail.com> said:
>
> > Hi, Joe,
> >
> > Thanks for the response.
> >
> > This is what you asked for last time. I assume this means that what I
> > provided is not enough to talk about? That sort of surprises me,
> > because I thought that showed how you can do the same thing without
> > any backward compatibility issues? Didn't it? How does the use of
> > Strategy I suggested do anything inconsistent with code that already
> > exists?
> >
> > I guess I don't see where the incompatibility lies. That is why I
> > gave the example of an actual class (the popluate class) in the
> > present work on the chain supplanting the RequestProcessor. I guess I
> > don't understand what you are saying there because there was what I
> > thought was a clear showing of how you could use the Strategy pattern,
> > avoiding the difficulties of the Template Method pattern, without
> > incurring any costs. Didn't the code show that?
> >
> > If the code did not show that, could you please tell me why? I
> > thought that is just what it showed. That is why I gave it to you in
> > response to your question. Certainly your question was more than
> > legitimate. I just thought I had answered it. If you mean that to
> > suggest alternatives I have to code all of Struts rather than suggest
> > and show how it could be done to open conversations, then I don't
> > understand. I am sure you don't mean that/
> >
> >
> >
> >
> > On Sun, 6 Mar 2005 12:30:00 -0600, Joe Germuska <Jo...@germuska.com> wrote:
> >> At 8:36 PM -0800 3/5/05, Dakota Jack wrote:
> >>> I gave you a specific, but you did not respond, Joe. Can you tell me why?
> >>
> >> OK, ready to reply.
> >>
> >> Basically, we're aiming to release a version of Struts 1.3.0 which is
> >> completely backwards compatible with Struts 1.2.x. At this point,
> >> the template method works and provides backwards compatibility;
> >> furthermore, the nature of the ComposableRequestProcessor is such
> >> that people who are ready to press forward with new designs can do so
> >> with minimal impact to the released codebase and with whatever level
> >> of concern for backwards compatibility is appropriate.
> >>
> >> In short, if you want to use the Strategy method, please, feel free.
> >> If you want to put up some web pages explaining to people how to use
> >> it and perhaps providing code, I think that would be very nice. Over
> >> time, it may make sense to change the way that the Struts core code
> >> works to use the Strategy pattern. Or, it may not.
> >>
> >> For example, look at Hubert's FormDef project. He had an idea for a
> >> different way to use Struts; he put it together and made it available
> >> to people. People who are ready to use it can do so.
> >>
> >> Joe
> >>
> >> --
> >> Joe Germuska
> >> Joe@Germuska.com
> >> http://blog.germuska.com
> >> "Narrow minds are weapons made for mass destruction" -The Ex
>
> ---------------------------------------------------------------------
> 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
Re: How Strategy Relates to CoR
Posted by Bill Siggelkow <bi...@bellsouth.net>.
One thing that I see is that the PopulateActionForm you supplied is
essentially the same as the Abstract one -- that is, it defines the
algorithm in the template -- the difference, of course, being that the
method implementations are delegated to a Helper instead of left up to
a concrete subclass (composition vs inheritance). Still, however, the
methods in Helper must be specified by an interface (which you don't
show). What would be the scope of this helper? Would it something like
an interface named PopulateActionFormHelper with a default impl
provided by Struts or would you propose a more generalized Struts
Helper? Likewise, how do you propose to set the Helper in the
PopulateActionForm -- a plug-in or IoC or something else? Furthermore,
couldn't someone implement this thing pattern anyway by creating their
own subclass of AbstractPopulateActionForm and delegating from their?
After all, the implementation has to belong somewhere.
On 2005-03-06 14:12:52 -0500, Dakota Jack <da...@gmail.com> said:
> Hi, Joe,
>
> Thanks for the response.
>
> This is what you asked for last time. I assume this means that what I
> provided is not enough to talk about? That sort of surprises me,
> because I thought that showed how you can do the same thing without
> any backward compatibility issues? Didn't it? How does the use of
> Strategy I suggested do anything inconsistent with code that already
> exists?
>
> I guess I don't see where the incompatibility lies. That is why I
> gave the example of an actual class (the popluate class) in the
> present work on the chain supplanting the RequestProcessor. I guess I
> don't understand what you are saying there because there was what I
> thought was a clear showing of how you could use the Strategy pattern,
> avoiding the difficulties of the Template Method pattern, without
> incurring any costs. Didn't the code show that?
>
> If the code did not show that, could you please tell me why? I
> thought that is just what it showed. That is why I gave it to you in
> response to your question. Certainly your question was more than
> legitimate. I just thought I had answered it. If you mean that to
> suggest alternatives I have to code all of Struts rather than suggest
> and show how it could be done to open conversations, then I don't
> understand. I am sure you don't mean that/
>
>
>
>
> On Sun, 6 Mar 2005 12:30:00 -0600, Joe Germuska <Jo...@germuska.com> wrote:
>> At 8:36 PM -0800 3/5/05, Dakota Jack wrote:
>>> I gave you a specific, but you did not respond, Joe. Can you tell me why?
>>
>> OK, ready to reply.
>>
>> Basically, we're aiming to release a version of Struts 1.3.0 which is
>> completely backwards compatible with Struts 1.2.x. At this point,
>> the template method works and provides backwards compatibility;
>> furthermore, the nature of the ComposableRequestProcessor is such
>> that people who are ready to press forward with new designs can do so
>> with minimal impact to the released codebase and with whatever level
>> of concern for backwards compatibility is appropriate.
>>
>> In short, if you want to use the Strategy method, please, feel free.
>> If you want to put up some web pages explaining to people how to use
>> it and perhaps providing code, I think that would be very nice. Over
>> time, it may make sense to change the way that the Struts core code
>> works to use the Strategy pattern. Or, it may not.
>>
>> For example, look at Hubert's FormDef project. He had an idea for a
>> different way to use Struts; he put it together and made it available
>> to people. People who are ready to use it can do so.
>>
>> Joe
>>
>> --
>> Joe Germuska
>> Joe@Germuska.com
>> http://blog.germuska.com
>> "Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: How Strategy Relates to CoR
Posted by Dakota Jack <da...@gmail.com>.
Hi, Joe,
Thanks for the response.
This is what you asked for last time. I assume this means that what I
provided is not enough to talk about? That sort of surprises me,
because I thought that showed how you can do the same thing without
any backward compatibility issues? Didn't it? How does the use of
Strategy I suggested do anything inconsistent with code that already
exists?
I guess I don't see where the incompatibility lies. That is why I
gave the example of an actual class (the popluate class) in the
present work on the chain supplanting the RequestProcessor. I guess I
don't understand what you are saying there because there was what I
thought was a clear showing of how you could use the Strategy pattern,
avoiding the difficulties of the Template Method pattern, without
incurring any costs. Didn't the code show that?
If the code did not show that, could you please tell me why? I
thought that is just what it showed. That is why I gave it to you in
response to your question. Certainly your question was more than
legitimate. I just thought I had answered it. If you mean that to
suggest alternatives I have to code all of Struts rather than suggest
and show how it could be done to open conversations, then I don't
understand. I am sure you don't mean that/
On Sun, 6 Mar 2005 12:30:00 -0600, Joe Germuska <Jo...@germuska.com> wrote:
> At 8:36 PM -0800 3/5/05, Dakota Jack wrote:
> >I gave you a specific, but you did not respond, Joe. Can you tell me why?
>
> OK, ready to reply.
>
> Basically, we're aiming to release a version of Struts 1.3.0 which is
> completely backwards compatible with Struts 1.2.x. At this point,
> the template method works and provides backwards compatibility;
> furthermore, the nature of the ComposableRequestProcessor is such
> that people who are ready to press forward with new designs can do so
> with minimal impact to the released codebase and with whatever level
> of concern for backwards compatibility is appropriate.
>
> In short, if you want to use the Strategy method, please, feel free.
> If you want to put up some web pages explaining to people how to use
> it and perhaps providing code, I think that would be very nice. Over
> time, it may make sense to change the way that the Struts core code
> works to use the Strategy pattern. Or, it may not.
>
> For example, look at Hubert's FormDef project. He had an idea for a
> different way to use Struts; he put it together and made it available
> to people. People who are ready to use it can do so.
>
> Joe
>
> --
> Joe Germuska
> Joe@Germuska.com
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction" -The Ex
>
--
"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
Re: How Strategy Relates to CoR
Posted by Joe Germuska <Jo...@Germuska.com>.
At 8:36 PM -0800 3/5/05, Dakota Jack wrote:
>I gave you a specific, but you did not respond, Joe. Can you tell me why?
OK, ready to reply.
Basically, we're aiming to release a version of Struts 1.3.0 which is
completely backwards compatible with Struts 1.2.x. At this point,
the template method works and provides backwards compatibility;
furthermore, the nature of the ComposableRequestProcessor is such
that people who are ready to press forward with new designs can do so
with minimal impact to the released codebase and with whatever level
of concern for backwards compatibility is appropriate.
In short, if you want to use the Strategy method, please, feel free.
If you want to put up some web pages explaining to people how to use
it and perhaps providing code, I think that would be very nice. Over
time, it may make sense to change the way that the Struts core code
works to use the Strategy pattern. Or, it may not.
For example, look at Hubert's FormDef project. He had an idea for a
different way to use Struts; he put it together and made it available
to people. People who are ready to use it can do so.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: How Strategy Relates to CoR
Posted by Joe Germuska <Jo...@Germuska.com>.
At 8:36 PM -0800 3/5/05, Dakota Jack wrote:
>I gave you a specific, but you did not respond, Joe. Can you tell me why?
Because I have been busy.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org