Re: Post/re-post problems
Bear wrote:
Craig,
At 10:28 AM 1/24/2001 -0800, you wrote:
* Tell my users "deal with it -- this is a web application, not a
web site, and the URL that you see is totally irrelevant."
I'm perfectly comfortable with this regarding the displayed URL. But what
about the refresh problem? Is there anyway to elegantly handle that?
thanks
bear
see the following post in the archives for another view/solution
to this issue:
http://www.mail-archive.com/struts-user@jakarta.apache.org/msg01823.html
e
--
___
Elod Horvath ('e') / ITFAIS Records (http://www.itfais.com/)
Re: Post/re-post problems
Right now I'm "forwarding" to a JSP that does nothing but redirects to the URL I want them to see (basically what you said). I would love to hear better solutions as well. Bear wrote: I'm just in the process of re-vamping my web app to use the Struts framework (moving from a Model 1 to a Model 2 architecture) and have come across what I see as a fundamental problem that I'm sure is just something I must be missing. The result of an action submission from a form is obviously a post operation. When the resulting JSP page shows the result of the action, the URL still shows the "command.do" form of the URL. That's not the problem though. If the user then refreshes the page, he/she gets the "do you want to repost" message (annoying), but worse, the post operation is resubmitted. For a destructive operation (like a delete) this could cause lots of problems for my app. Aside from forcing the ActionForward to be a redirect rather than a forward, how have y'all handled this situation? thanks, bear
Re: Post/re-post problems
Bear wrote:
Craig,
At 10:28 AM 1/24/2001 -0800, you wrote:
* Tell my users "deal with it -- this is a web application, not a
web site, and the URL that you see is totally irrelevant."
I'm perfectly comfortable with this regarding the displayed URL. But what
about the refresh problem? Is there anyway to elegantly handle that?
Isn't that part of "deal with it"? Why is the user pressing the Reload button
(or the Back button to return to a previously displayed page)? Those are the
actions that you want to train them to avoid, and teach them to use only the
navigation controls you have provided within your pages.
NOTE: Technology was recently added to Struts so that your application can
detect a duplicate post that was actually submitted. It involves setting a
command token (whose current value is saved in the user's session) that must be
returned with the next submit. If no such value (or a different value) is
returned, this can be detected by your Action and you can do the appropriate
thing (such as *not* add an item to the shopping cart twice).
This is used in the Struts example app on the registration page. In the
EditRegistrationAction (that sets up the beans for registration.jsp) you will
see the call:
saveToken(request);
down at the bottom. Then, in SaveRegistrationAction (which processes the
submitted form) you see:
if (!isTokenValid(request)) {
... deal with the error ...
}
resetToken(request);
Using this technique, the app will catch the case where the user presses Save on
the registration page, then presses the back arrow, then presses Save again.
No changes are needed to the JSP pages themselves -- the html:form tag
generates a hidden field automatically if needed.
thanks
bear
Craig
RE: Post/re-post problems
You can specify that a forward be handled by a redirect instead of a jsp:forward by doing this: forward name="success" path="/home.jsp" redirect="true"/ -Original Message- From: George Lessmann [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 24, 2001 2:31 PM To: [EMAIL PROTECTED] Subject: Re: Post/re-post problems The technical reason this happens is that RequestDispatcher.forward() (or jsp:forward) happens only on the server side -- the browser has no clue what is going on, and only displays the URL it submitted to -- not the URL of the page you called to create the response. As a Lurker hoping to add his application framework to Struts... I separate doGet() and doPost() requests so that doGets use forward() and doPosts use redirects. I would like to hear why Struts decided to use forward exclusively. On a tangent, I would also like to hear why Struts maps actions at the form level rather than the input level as in traditional cgi programs. thanks, George Lessmann Ponvia Technology, Inc
Re: Post/re-post problems
George Lessmann wrote: The technical reason this happens is that RequestDispatcher.forward() (or jsp:forward) happens only on the server side -- the browser has no clue what is going on, and only displays the URL it submitted to -- not the URL of the page you called to create the response. As a Lurker hoping to add his application framework to Struts... I separate doGet() and doPost() requests so that doGets use forward() and doPosts use redirects. As Hal points out, you can tell a Forward entry to use sendRedirect() instead if you want to. This was one of the very early enhancement requests. I would like to hear why Struts decided to use forward exclusively. Forwards are the default for two reasons: * You can use request attributes to forward information to the page that is ultimately displayed. Using a sendRedirect, you're stuck passing stuff in hidden variables in the form, or as session attributes. (In particular, the ActionForm bean can often be passed as a request attribute, which reduces memory occupancy on your server). * Forwards will generally be faster, because they avoid a second round trip across the network. This doesn't matter a lot on a 100mbps intranet, but it can make a big difference if your client is at the end of a 56k modem somewhere across the world. On a tangent, I would also like to hear why Struts maps actions at the form level rather than the input level as in traditional cgi programs. I'm not sure I understand what you mean by the "input level". Could you describe it further? thanks, George Lessmann Craig Ponvia Technology, Inc
Re: Post/re-post problems
"Deadman, Hal" wrote: You can specify that a forward be handled by a redirect instead of a jsp:forward by doing this: Ack! "You could have gone home anytime by clicking your shoes together." - to Dorothy. Guess I should read the dtd a little more closely... Thanks.
Re: Post/re-post problems
George Lessmann wrote: I'm not sure I understand what you mean by the "input level". Could you describe it further? First, my understanding of Struts is that actions happen at the form level, such that a form action is further inspected to determine what needs to be done. In my system, I go to the lower level of granularity to the actual input events. Yes, that is pretty much the case (Struts currently being form oriented). Your first level of granularity is the action URL that the form is submitted to, and that action can (if it chooses to) dispatch to a "sub-action" dependent on some fields that were submitted. In the example app, for example :-), the "action" field is used to distinguish sub-actions that are handled very similarly, but with just a few differing details, by the same action. Let's say I have a form. On that form I can do a few actions, namely Update, Add, and Delete. In my architecture, I have it like so: input type="submit" name="formname.update" value="Update" input type="submit" name="formname.add" value="Add" input type="submit" name="formname.delete" value="Delete" The form is posting to: form name="formname" action="/AppServlet" method="post" One option would be to use JavaScript event handlers on the three submit buttons, and change where the submit would actually go to. Right now, those actions are separate objects but I'm not to sure I like that, but I'm also not a fan of runtime introspection. You probably will not like the way that ActionForm beans work, then :-). My goal, though, is to remove most, if not all, switch-like logic. Also, I'm trying to get my application flow to become as far removed as possible, since one of my goals is to make an application mapping app. On the TODO list for 1.1 is to look at how a finer-grained "workflow" type model might fit into the overall framework. In addition, there's been some discussion of handling events finer-grained than a submit -- everything from clientside JavaScript field validations to interacting with the host "in the middle of" a page. But that's all in the future ... present day Struts 1.0 is very much form-oriented (using your terminology). Anyway, I hope this makes some sort of sense. Getting an understanding of the motives of Struts while trying to keep what I like about my stuff is a prescription for headaches. Yah, that makes a lot more sense. Like any framework, Struts expects you to "buy in" to the design philosophies that it is based on. People that do find it to be tremendously helpful. People that don't are going to select something different. (And, for a wide range of the middle ground, there is also room to customize the details of how Struts works by subclassing, but it's probably not going to be easily to make fundamental changes by following this route). George Lessmann Ponvia Technology, Inc Craig
