James/Brian I have thought of another way of doing this but please correct me if I'm wrong Take a case I have a prepare1Action which forwards it to ABC.jsp prepare2Action also forwarding it to ABC.jsp Then ABC.jsp submits it to ProcessAction
Now in some way need to get the path of the previously called Action(prepare1Action or prepare2Action) If in our base form we have a property called inputAction And we populate that with mapping.getPath() in prepare1Action and prepare2Action And in our ABC.jsp we can store that as a hidden field called inputpath. And when we face any errors in processAction we can forward it to the inputpath which we get after submiting the jsp. It was just a thought which came to me, I have not tested or implemented this.... Please get back I would really like to hear from you Regards Anant In our action classes we can get mapping.getPath(). Store this path in each and every form bean And when we get any errors we can redirect it to -----Original Message----- From: James Mitchell [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 10, 2004 12:20 AM To: Struts Users Mailing List Subject: Re: Supporting a back button without JavaScript On Mon, 9 Feb 2004, Brian Ivey wrote: > Dear List, > > I have to give my application users a way to navigate to the previous > page without using the browser back button. Program constraints > prevent me from using JavaScript to solve this. Because many JSP > pages use the same Actions I am unable to simply hard code the > referring page to navigate back to. > > Any thoughts would be appreciated. BTW, I am inclined to believe that > I can extract the referring page from one of the attributes sent to > the Action (mapping, request, ...) and then cache this value as either > a parameter or as an attribute. Does anyone think this could work? I recently completed a mechanism for doing this. It supports back (previous) and cancel actions for you. Basically, I keep 2 stacks in the session, one for standard navigation and one for exception flows which simply are pointers the standard nav stack. In my base action, I call super.execute (I use DispatchAction, use an abstract doExecute or whatever if you are going stock) with a custom wrapped ActionMapping that takes (and manages) the request on the constructor so that all calls to findforward are added to the stack. What is boils down to is for normal flow of my application, I don't have to do anything. In the case where the user 'jumps' off the normal flow of things, the app needs to provide a cancel that takes them back on flow where they left off. (all the while remember the back or previous page). The only problem with our implementation is that all lists (drop down collections) are retrieved via a caching mechanism that is invoked from our dto getters (not my design), which allows our simple design to work so fuently. >From there, all the developers have to do is: - remeber to call addCancelAction() from any action that takes the user off of the normal flow - use an <%page include...%> which renders the previous or cancel button Anyway, I can't indulge in all the details, but I hope you can get a couple of ideas from that. > > Thanks, > Brian Ivey > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- James Mitchell Software Developer / Struts Evangelist http://www.struts-atlanta.org --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or [EMAIL PROTECTED] immediately and destroy all copies of this message and any attachments. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
