I guess it is easier to repost, than to explain how to search mailing list. Rick, Leon, you already have read this ;)
=== cut here === Tokens are better solution than nothing, but not the best. Token works *after* POST request has been resubmitted. It can help to prevent *data resubmission* on business/persisntence layer, but it does nothing to prevent browser message: "Do you want to resend POSTDATA?" What? What is POSTDATA? I don't care what it is, and I don't know do I want to resend it or not, just show the damn page. The simple "send POST, get page" approach results in horrible UI, like I had to go through when I was ordering parts for my car. Car make->POST form. Model->POST form. Year->POST form. Suspension part->POST form. Struts (no put intended)->POST form -> (looking for Tokico struts, don't see any). Go Back. "Do you want to resend POSTDATA?" - No -> I see the same page. Back again. "Do you want to resend POSTDATA?" - Yes -> The previous page is reloaded with the same POST, running the same query on the server. Same happens three or four more times. I wanted to strangle the programmer who desinged that. Right, if pages were cachable, it would help. Or if I used Opera. But this is only one example of many. In other cases Opera caching does not help, it gets in the way. Another example. You want to log in. You enter name, it is incorrect, it is redisplayed. Again, and again, and again. You decided to drop the idea, and to return back. How many times you need to click Back? Also, token knows nothing about your business data. You are shopping in the online store. You selected item, clicked "Add to cart", it was added, and you forwarded to another page. Then you realised that you need two of them. You click Back, see the same item again and click "Add to cart". Now it tells you that you cannot do this, because you are resubmitting the same request, apparently by mistake. Your webapp can prove it to you, it has the freaking token. But it is not a mistake, you actually want to add the same item again. So, tokens better than nothing, like Yugo comparing to bike. But it is still a Yugo. === cut here === Michael On 7/14/05, Yaroslav Novytskyy <[EMAIL PROTECTED]> wrote: > Hello! > > I would advise to use synchronization via Session tockens. (I'm working > at this process' automation at the moment). Struts' Action already has, > what is needed for this are saveToken() and isTokenValid() methods. > > This technique makes it imposible to execute an action more then once > (if not on purpouse) exclueding double-submits, refreshes, > by-bookmark-visits. > > Read the doc and check if that is what you need. And if yes, you can > take look in my two days old message titled "synchronization strategies" > - I beleave most answers (along with some questions :) ) are there. > > Yaroslav Novytskyy > > Leon Rosenberg wrote: > > before Michael jumps on the train :-) > > > > simply send a redirect after executing create action to the list action > > again? > > > > regards > > Leon > > > > On Thu, 2005-07-14 at 14:24 +0530, senthil Kumar wrote: > > > >>Hi All., > >> > >>In our application, I hava a list of tasks. Each task have a chech box and > >>once checked the check box and click "AddAlert" button, alert for the > >>checked task is created. > >> > >>Up to this functionality working fine for me. > >> > >> My problem is once creating alert and unfortunately click F5 button, again > >> the alert is created for the same task i.e the same alert action(.do) > >> calling again. > >> > >> > >>How to avoid it. > >>any one help me. > >> > >> > >>Thanks in advance. > >> > >> > >>Regs., > >>Senthil S > >> > >> > >> > >> > >>This e-mail and any files transmitted with it are for the sole use of the > >>intended recipient(s) and may contain confidential and privileged > >>information. If you are not the intended recipient or received it in error, > >>please contact the sender by reply e-mail and destroy all copies of the > >>original message. Please do not copy it for any purpose or disclose its > >>contents. > >> > >>Copyright Tarang Software Technologies Pvt. Ltd. 2004. All rights Reserved > > > > > > > > > > --------------------------------------------------------------------- > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
