jsf – 在呈现响应之前如何处理多个提交?

据测试报告说,如果响应速度不够快,可能会多次按下一个按钮,导致后端代码的几个调用,我们不想要.

应用程序是在Glassfish 3.1.1中使用JSF 2.0的Java EE 6 Web Profile.

我想知道应该如何妥善处理,并考虑了几种情况:

>提交应该在呈现响应时使用javascript禁用所有按钮.
>会话范围中的一个标志表示已经处于活动状态,因此敏感代码被跳过,只是转移到上次提交的响应的重新呈现.
>同步块延迟处理,直到先前的请求完成.那么应该检测到它已经被处理和跳过了.
>使用“新”范围之一,如转换来处理检测?

我直接的直觉是,最好的方法是将敏感的代码块变成原子,然后问题是渲染正确的响应.

我该怎么办?

解决方法

Submitting should disable all buttons using javascript while response is being rendered.

这是以通用方式实现的最简单的方法.如果你碰巧使用< f:ajax>专门地,您可以使用jsf.ajax.addOnEvent()以通用方式执行作业.另一种JavaScript方法是创建一种阻止UI的“加载”覆盖,以使最终用户无法再与基础页面进行交互.这基本上是绝对定位的< div>它跨越整个视口,具有一些不透明度(透明度).您可以在提交时显示它,并将其隐藏在渲染上.该技术的关键字是“modal dialog”.面向UI的JSF组件库至少具有这样的组件.例如. PrimeFaces<p:dialog modal="true">内部<p:ajaxStatus><p:blockUI>

唯一的缺点是,如果客户端禁用了JS或不使用它,它将不会起作用,因此不会阻止HTTP客户端双重提交.

A flag in the Session scope saying it is already active,so the sensitive code is skipped and just moves on to the re-rendering of the response for the prevIoUs submit.

这更被称为“synchronizer token pattern”,并且已经被spec issue 559要求的JSF,目前这是针对2.2的机票,但似乎没有任何活动.检测和阻塞部分在技术上很容易实现,但是如果希望最终用户最终检索由初始请求生成的响应,则同步响应处理部分不容易实现.异步响应处理很容易:只需不指定要更新的任何组件,即按PartialViewContext#getRenderIds()返回的集合清空.毕竟,这比使用JS禁用按钮或阻止UI更强大.

据我所知,Seam 2是唯一为<s:token>提供可重用的JSF组件的人.不过,我必须承认,这是一个新的OmniFaces组件的一个有趣的想法.也许我会亲自看看它.

A synchronized block delaying the processing until the prevIoUs request have finished. Then it should be detected that it has been already processed and skipped.

这一般不容易实现,这将需要更改所有操作方法以检查作业是否已经完成.如果webapp在多个服务器上运行,它也不会工作.同步器令牌更容易,因为它将在调用动作方法之前执行.同步器令牌也更便宜,因为您不会在队列中遇到多个只能花费线程/资源的请求.

Using one of the “new” scopes like conversion to handle the detection?

这个问题不能通过管理bean作用域来解决.托管bean作用域用于不同的用途:bean实例的生命周期.

相关文章

最近看了一下学习资料,感觉进制转换其实还是挺有意思的,尤...
/*HashSet 基本操作 * --set:元素是无序的,存入和取出顺序不...
/*list 基本操作 * * List a=new List(); * 增 * a.add(inde...
/* * 内部类 * */ 1 class OutClass{ 2 //定义外部类的成员变...
集合的操作Iterator、Collection、Set和HashSet关系Iterator...
接口中常量的修饰关键字:public,static,final(常量)函数...