I'd be careful about undoing changes to the persistent store. Could be messy. Plus, if another user started putting records in that referenced records that you are trying to delete as part of an undo operation, then you'd have referential integretity constraint errors and what not. Might work if the data being edited was very user-specific. Still, I would think that this 'undo' functionality would be most useful where the user was storing a bunch of stuff in a multi-page form, stored in session. They could undo one page's entries. Once they finished everything and said 'Save', and answered yes to 'Are you sure, this can't be undone anymore', then it would save to the database, permanently.
Steve Molitor -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, June 07, 2002 4:15 PM To: Struts Users Mailing List Subject: RE: [Struts Tips] #2 - Template Method Dispatch Action? Yes - If each Command could "undo()" just the action that it took, you could step through them and walk back as far as needed. Define your Commands as implementing an Interface requiring a "public void undo();" (and maybe a "public boolean undoable();" to see if it is a command that can be undone). Then code each undo() to inspect the property values it contains and then undo itself - even if it means modifying a persistent store. The Command objects would retain their property values as long as they are not modified. In addition, before each Command was executed to initially, it could query the persistent store and retrieve the values of anything it was going to change - then it could "undo" changes to the persistent store as well. Just thinking - Kevin "Molitor, Stephen" <[EMAIL PROTECTED]> on 06/07/2002 05:01:57 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? Sounds interesting. Wouldn't be practical if the business actions save persistent state to a database. Also, you might have to restore the state of the ui (the web page) with each undo operation, so it couldn't just be a collection of business beans; they'd have to include some ui info. A collection of undoable Actions? Steve Molitor -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, June 07, 2002 2:56 PM To: Struts Users Mailing List Subject: RE: [Struts Tips] #2 - Template Method Dispatch Action? 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]> -- 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
