Hi Leon.
I did what you mentioned as the second approach and used a token (precisely: locking mechanism, because in my case it's not "delete" but "edit") to avoid F5 problems. But I'm not happy with that, because, you already said that, the user sees "edit.do" in the URL and not "view.do", but "view.do" is the currrent action, and not "edit.do", so it does not come up to user's expectations and that's the major point, I think. Please let me know if you find a appropriate solution.
Bernd
Leon Rosenberg schrieb:
Hi,
I have a problem which I think is common to many of the developers one the list, and where I'd like to hark to your opinions / solutions.
I think it's a common use case in web applications, where you have to present a list of something, lets say a list of bikes. You have normally some common functionality, like ShowList, Edit/New (presents a dialog), Create/Update and a Delete operation. Now my problem is, that after delete,create or update I normally show the updated list, by actually executing the Show action.
I know about two ways to implement this derive the delete action from show
action, and call super.execute(), or send a redirect from delete action to the show action.
Example:
<action path="/bikesShow" type="net.anotheria.bikes.action.ShowBikesAction" scope="request"> <forward name="success" path="/net/anotheria/bikes/jsp/Bikes.jsp"/> </action> <action path="/bikeDelete" type="net.anotheria.bikes.action.DeleteBikeAction" scope="request"> <forward name="success" path="/net/anotheria/bikes/jsp/Bikes.jsp"/> </action>
After bikeDelete has been called, it calls the super.execute from
ShowBikesAction it's extending, and the updated list is presented. Works
fine ... until the user hits the refresh button. Since the url in the
browser is bikeDelete and not bikesShow the delete action will be called again. It's getting even worser with create action
which then would actually create a second record.
Now, I could avoid creating second object or trying to delete already deleted object by inserting an execute-once-tokens, but it feels like fixing a bad design, so I'd like to avoid it.
Another approach I know of, is to define the delete action without a forward and actually send a redirect after the deletion is complete. This would solve the F5 problem, but produces an additional request from browser to server, and makes the whole app slower.
Do you know any other solutions? I have searched for an opportunity to solve
this problem with a tricky js, actually replacing the url of the current document in the browser without request, but i found
none :-(
Any other ideas, options?
Thanx in advance
Regards Leon
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
