I'm not sure I totally understand what you mean by "chaining actions". Currently, the application has one action per visual page, but each action handles the processing of the previous page and the setup of the next page. This seems wrong, as it requires me to write a whole new action to handle a similar but different situation: i.e. if I have an action that processes page X and then sets up page Y, I have to write a whole separate action that processes page Z and then sets up page Y.
If I already have three separate actions that process pages X & Z and set up page Y, I can join them together however I feel like using forwards, should I need to. Of course, that leads to my URL issue. Now granted, each of the execute() methods of the actions are relatively short since they are simply some parsing and then calls to business-model methods and so writing a new one doesn't take a lot of time, but it seems odd to write "ProcessXDisplayYAction" and "ProcessZDisplayYAction" classes. --Trevor -----Original Message----- From: Hubert Rabago [mailto:[EMAIL PROTECTED] Sent: January 26, 2005 11:14 AM To: Struts Users Mailing List Subject: Re: Action naming conventions and URL accuracy How big of an overhead is it? I've never felt an overhead, then again I've never attempted to measure it either. The "cost" of the redirect just never seemed like such a big deal to me. On the other hand, keep in mind that Struts doesn't recommend you chain actions the way you could be doing now. Hubert On Wed, 26 Jan 2005 11:07:34 -0500, Trevor Hill <[EMAIL PROTECTED]> wrote: > Hi all, first time poster here. > > I'm experiencing a bit of a conundrum here in trying to name my actions > appropriately. An example: > > I have a set of processes to execute, say A B C D, to be executed > sequentially (basically in wizard-style), and each page may need > pre-processing (page setup) and obviously post-processing (handling form > input). > > One way I've done things in the past is to have four actions: A, B, C, D, > each of which handles the preprocessing of the current page and also the > post-processing of the previous page (that is, action B handles form A's > submissions, as well as getting data assembled to display form B). This > works okay, except that inserting actions is a minor pain -- if I insert X > between B and C, then I have to move B's post-processing code to X (from C) > and put X's post-processing code into C. > > I've also attempted using DispatchActions with two or more methods: "display" > to display the form, "process" (or similar) to indicate that I'm processing > the form. So then I have a chain that looks like this: > > A.do?method=display -> > A.jsp (submits to) > A.do?method=process -> > B.do?method=display -> > B.jsp (submits to) > B.do?method=process -> > C.do?method=display ... and so on. > > The problem with this is that the forwards between A.do?method=process and > B.do?method=display leave the address bar indicating that we are on step A > when we're really on step B. I can circumvent this by turning that forward > into a redirect, but I'm not sure that having an 'accurate' URL is > necessarily a good reason to add the overhead of a redirect. > > Am I missing something? Is there a straightforward way to have your action > URLs reliably indicate which step of the process you are on without having to > play the switcheroo outlined in my first scenario? > > Thanks for your time, > --Trevor > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from your > system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be unlawful. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
