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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
