On 3/27/06, Chris Cheshire <[EMAIL PROTECTED]> wrote: > Hi, > > I have a design issue based around form submission, protecting against > resubmission etc. > > I have seen a couple of design "guidelines" that seem to conflict. > > 1) Use the session as little as possible (memory issues etc) > 2) Use forwards where possible as requests can be passed along, with > original information preserved, as well as speeding up communication. > > Now the only problem I face is after an action is complete, if I > forward to a JSP, that action is open to resubmission when the user > starts playing with the reload and back buttons on their browser. > Redirects, because of the URL changing, can help protect against this. > > So the solution seems to be to place the beans required by the JSP > page in displaying the result of the action in the session instead. So > now there is an issue of when do the objects for the action that was > just performed get removed from the session? > > Do I just put something in the start of each action to remove from the > session all objects not associated with that action?
I observe the common Struts pattern to "front" JSP pages with actions. I have a setup/render action that selects an appropriate JSP and forwards to it. I also have a submit action that handles the input. After submit action finished with input, it redirects to render action. So, I redirect from submit action to render action, but I forward from render action to a JSP page. You don't have to change URL in the address bar for redirect. Say, you have "showItem.do?id=1234" action that forwards to JSP and shows item form. You update item and submit it to "updateItem.do" action. It updates the database or if errors found, it generates errors, sticks them into session and redirects to "showItem.do?id=1234". Now you have the same URL in the browser again, with error messages in the form. Struts 1.2.6+ removes messages from session automatically after they were shown, but for anything else it is on you. Yes, controlling what is in session is a burden, and especially problematic if you allow a user to open several windows for one object. Then you cannot remove the object when the user returns to, say, a list of objects. This is a compromize. If you care about cleaner URLs and better user experience, use redirect and clean session yourself. Otherwise use Token object to prevent resubmits, but a user will still see POSTDATA message. Session-scoped data allows you to navigate to any action keeping application state, so you don't need to obey an artificial page flow. I think this is a benefit usage-wise. I prefer to use session-scoped ActionForms and to put everything related to an object into the form as nested properties. This seems easier to handle for me. Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
