struts的重复提交问题

《struts的重复提交问题》由会员上传分享，免费在线阅读，更多相关内容在行业资料-天天文库。

1、重复提交、重复刷新、防止后退的问题以及处理方式两种方法都是可行的1.使用token2.forward设置redirect=true一。前言你在任何一个比较专业的BBS都会看到这样的问题，即使你Google一下，也会发现有很多的人在关注和询问，但大家给出的解决方法却都是千差万别，（有的人主张采用脚本来解决;有的则想重定向到别的页面;有的则将此问题提升到Token的角度）为什么会有如此大的差异呢？二。问题场景首先，我们应该先了解为什么要处理这样的问题？或者专业一点就是它适合的场景是什么？（似乎只有人来问没有人

2、来解释）1。重复提交、重复刷新的场景重复提交、重复刷新都是来解决系统重复记录的问题。也就是说某个人在多次的提交某条记录（为什么？也许是闲了没有事情干的;最有可能是用户根本就不知道自己的提交结果是否已经执行了？！）。但出现了这样的问题并不见得就必须处理，要看你所开发的系统的类别而定。比如你接手的是某个资源管理系统，系统本身从需求的角度根本就不允许出现"重复"的记录，在这样需求的约束条件下，去执行重复的提交动作只会引发“业务级异常”的产生，根本就不可能执行成功也就无所谓避免不避免的问题了。 2。防止后退的场景

3、了解了重复刷新、重复提交的场景，我们来了解一下"防止后退"操作的原因是什么？比如你在开发某个投票系统，它有很多的步骤，并且这些步骤之间是有联系的，比如第一步会将某些信息发送给第二步，第二步缓存了这些信息，同时将自身的信息发送给了第三步。。。。。等等，如果此时用户处在第三步骤下，我们想象一下某个淘气用户的用户点击了后退按钮，此时屏幕出现了第二步骤的页面，他再次的修改或者再次的提交，进入到下一个步骤（也就是第三步骤），错误就会在此产生？！什么错误呢？最为典型的就是这样的操作直接导致了对于第一个步骤信息的丢失！

4、（如果这样的信息是依靠Request存放的话，当然你可以存放在Session或者更大的上下文环境中，但这不是个好主意！关于信息存放的问题，下次在就这个问题详细的讨论）三。如何处理的问题当然很多的系统（比如订票系统从需求上本身是允许个人重复订票的）是必须要避免重复刷新、重复提交、以及防止后退的问题的，但即使是这样的问题，也要区分如何处理以及在哪里处理的（网上只是告诉你如何处理，但很少去区分在哪里处理的），显然处理的方式无非是客户端或者服务器端两种，而面对不同的位置处理的方式也是不同的，但有一点要事先声明：任

5、何客户端（尤其是B/S端）的处理都是不可信任的，最好的也是最应该的是服务器端的处理方法。客户端处理：面对客户端我们可以使用Javascript脚本来解决，如下1。重复刷新、重复提交WaysOne：设置一个变量，只允许提交一次。   varcheckSubmitFlg=false;   functioncheckSubmit(){     if(checkSubmitFlg==true){        returnfalse;     }     

6、checkSubmitFlg=true;     returntrue;  }  document.ondblclick=functiondocondblclick(){   window.event.returnValue=false;  }  document.onclick=functiondoconclick(){      if(checkSubmitFlg){        window.event.returnValue=false;      }  }

7、action="myAction.do"method="post"onsubmit="returncheckSubmit();">WayTwo:将提交按钮或者image置为disable    

8、gif"border="0"/>  2。防止用户后退这里的方法是千姿百态，有的是更改浏览器的历史纪录的，比如使用window.history.forward()方法;有的是“用新页面的URL替换当前的历史纪录，这样浏览历史记录中就只有一个页面，后退按钮永远不会变为可用。”比如使用javascript:location.replace(this.href);event.returnValue=false;