One of the advantages of the Command Pattern is that it's considered
relatively easy to implement "UNDO" functionality into.
Any thoughts on how this might be done using this approach?
Maybe have a session attribute that is an ordered collection of past
Commands? This would also allow you to present a "Command History" easily.
"Molitor, Stephen" <[EMAIL PROTECTED]> on 06/07/2002 02:54:05 PM
Please respond to "Struts Users Mailing List"
<[EMAIL PROTECTED]>
To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
cc: (bcc: Kevin Bedell/Systems/USHO/SunLife)
Subject: RE: [Struts Tips] #2 - Template Method Dispatch Action?
Makes sense; sounds like a very good approach. Thank you for taking the
time to explain this.
Steve Molitor
-----Original Message-----
From: Ted Husted [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 07, 2002 12:37 PM
To: Struts Users Mailing List
Subject: Re: [Struts Tips] #2 - Template Method Dispatch Action?
Yes. With the help of decent framework Action and a standard result
object, it's not hard to take the command pattern one step farther. This
can get all the business tier code out of the Actions. Actions are a
great and necessary class, but they are hard to reuse, even within the
same application. While it's entirely possible to forward control from
one Action another, it ain't pretty. In practice, many operations can be
aggregated from smaller operations. A move is a copy and a delete. This
is not a lot of fun with Actions, but no sweat at all with a business
bean.
-T.
"Molitor, Stephen" wrote:
>
> That was my understanding of Ted's emails. Ted, is this correct?
>
> This approach would seem to have the usual advantages and disadvantages
of
> the Command pattern. With the command pattern, you turn what would be
> individual methods of one class into separte command classes. Since the
> commands are now objects, you can do object oriented things with them,
like
> inheritance, composition, store them in a list, have a controller that
pre
> and post processes the command objects. The disadvantage of course is
that
> you have lots of little classes.
>
> Steve Molitor
>
> -----Original Message-----
> From: Robert Taylor [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 06, 2002 2:25 PM
> To: Struts Users Mailing List
> Subject: RE: [Struts Tips] #2 - Template Method Dispatch Action?
>
> So if I had an XXXXAction that handled the following operations on an
> account:
>
> -createAccount
> -retrieveAccount
> -updateAccount
> -deleteAccount
>
> instead of having these 4 methods defined, in a single action class, you
> would define a business bean in the action mapping and something similar
to
> the following operations would take place in sequence when the XXXXAction
> was invoked.
>
> -The XXXXAction class accesses business bean (creates or retrieves).
> -The XXXXAction class converts (directly or indirectly) user input into
> expected business input arguments .
> -The XXXXAction class invokes business bean hotspot method with business
> arguments.
> -The business bean processes input and performs the appropriate command
> logic.
> -The business bean returns a business bean return object.
> -The XXXXAction class processes the business bean return object to
determine
> the ActionForward.
> -The XXXXAction class returns ActionForward to the web controller.
>
> So you might end up having business beans/delegates like
> CreateAccountCommand, RetrieveAccountCommand, UpdateAccountCommand, and
> DeleteAccountCommand, instead of separate XXXXAction classes or a single
> XXXXAction class with the four methods. Each of the four business beans
> might then delegate to a common business service called something like
> IAccountService to handle or delegate processing.
>
> Did I interpret that correctly?
>
> robert
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <
mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <
mailto:[EMAIL PROTECTED]>
---------------------------------------------------------------------------
This e-mail message (including attachments, if any) is intended for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt from
disclosure. If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited. If you have received this communication in error,
please notify the sender and erase this e-mail message immediately.
---------------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
