Dave, I'm not sure if you really read my message thoroughly. When I meant population, I meant for things like drop down lists, not for edit pages that come pre-populated with existing data to edit. If you always go back to the same page, then populating the drop down list has to be done whether you're going to the page directly or after an add/update, so that's why I was asking about redirecting, I thought you were doing the update then redirecting to the action that does the setup.
As for the two approaches I've been asking for comments on...they're not the one below, bu the ones at the end of my email: 1- Put the setup information in the ActionForm class itself (not very inclined to go for that one). 2- Using a MappingDispatchAction without action chaining. Put the setup code in common methods in the action class. Configure two mappings for the same action class that will call two different methods, e.g. prepare and add. In both methods, I would call the common setup method before going back to the page, so it's minimal duplicated code (although duplication is not completely eliminated), but at least it's less awkward than retieving the form from the request scope by hand. Of course in number 2 above, I don't mean that the actual database call is in the action, but the call to the service method. Thanks -----Original Message----- From: Dave Newton [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 03, 2006 10:17 PM To: Struts Users Mailing List Subject: Re: Is Action Chaining Strongly Discouraged? Tarek Nabil wrote: > Do you mean that you're doing a redirect after processing the post? > Who, me? If no, ignore the following. I'm not sure I understand the question. In a nutshell: for a GET I do whatever population/misc. stuff I need to do then return the input forward. For a POST I validate and return the input forward if there are errors, otherwise I return whatever forward is warranted. In practice by classes have become more cumbersome than that with methods designed to be overridden that do pre- and post-processing etc. > I've been thinking about this action chaining issue for some time > since I used it in my last project and it resulted in some code duplication. > Isn't that bass-ackwards? Even though I really dislike chaining shouldn't it have less code? > 1- A prepare action when the page is called directly (a form bean is > configured for that one). > 2- A page action when it's called from another action (no form bean is > configured to prevent resetting). > *shudder* If no other reason here's a strong reason to move that logic out of the actions and into service objects; at least then you're just making calls rather than duplicating the code. Unless I completely misunderstood you. > Would anyone care to comment on those two approaches? Does anyone have > a different approach that I can consider? > At first glance with no clue what you're trying to accomplish it sounds overly complicated. Dave ********************************************DISCLAIMER******************************************** This email and any files transmitted with it are confidential and contain privileged or copyright information. If you are not the intended recipient you must not copy, distribute or use this email or the information contained in it for any purpose other than to notify us of the receipt thereof. If you have received this message in error, please notify the sender immediately, and delete this email from your system. Please note that e-mails are susceptible to change.The sender shall not be liable for the improper or incomplete transmission of the information contained in this communication,nor for any delay in its receipt or damage to your system.The sender does not guarantee that this material is free from viruses or any other defects although due care has been taken to minimise the risk. ************************************************************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]