[size=medium]当我们使用<h:dataTable/> 里面嵌入<h:commandLink/>的时候,我们会发现当我们点击commandlink的时候是响应后台的方法的。这是什么原因呢?这还要从JSF的六个生命周期来说起。而罪魁祸首就是JSF前面几个周期惹的祸。当我们点击commandLink的时候,他是会提交表单的,但是你的dataTable里的迭代的值,我想JSF应该不能那么聪明的把每个值重新部署回到你的后台的一个List的容器中。反向操作太难了。在前几个阶段,如果你manageBean是RequestScope的阶段。那么他会重新初始化一个view视图,这个时候,如果你的dataTable并不是初始就加载的话。那里么是不能显示的。那么这个<h:comamndLink/>就不能被解析,尽管我们之前已经提交了一个action,但是到更新模型值的时候,你就不能解析到这个控件。所以你看到的就是一个重新刷新的页面。该怎么解决?
一种方案是说把 requestScope 变成 sessionScope 这个确实很简单。而且按照我上面讲的原理也能解释为什么sessionScope能够被执行。但是如果在JSP/Servlet 时候,我们就是只是用一个param就解决问题了。如果我们的所有的数据都是放在sessionScope下,我感觉服务器的负载会很大。
可以说也许很多人会对JSF的周期很是愤怒,很是无可奈何?但是成也萧何,败也萧何。我的解决方案,恰恰是在JSF周期进行解决。但是前提是我们的控制逻辑要写好
解决方案:
假设我们的场景是,每一行的数据都有一个edit的link和一个detail的link
我们要做的就是将<h:comamndLink/> 改为<h:link/> outcome 里面加上我们要加载的数值。然后后台bean的解决代码是[/size]
[size=medium]我的这种方案,只是解决了点击一个链接的问题,当然如果是一个在本页的操作,我们也是可以执行了,比如说delete操作,JSF在前几个周期的时候 仍然是可以接收到我们传来的beanId的值,但是,然后我们还是在那里将操作进行execute。
这只是我们解决方案,欢迎大家来讨论。毕竟这个<h:dataTable/> 和<h:commandLink/>结合的场景很是常见。[/size]
一种方案是说把 requestScope 变成 sessionScope 这个确实很简单。而且按照我上面讲的原理也能解释为什么sessionScope能够被执行。但是如果在JSP/Servlet 时候,我们就是只是用一个param就解决问题了。如果我们的所有的数据都是放在sessionScope下,我感觉服务器的负载会很大。
可以说也许很多人会对JSF的周期很是愤怒,很是无可奈何?但是成也萧何,败也萧何。我的解决方案,恰恰是在JSF周期进行解决。但是前提是我们的控制逻辑要写好
解决方案:
假设我们的场景是,每一行的数据都有一个edit的link和一个detail的link
我们要做的就是将<h:comamndLink/> 改为<h:link/> outcome 里面加上我们要加载的数值。然后后台bean的解决代码是[/size]
@PostConstruct
public void checkControler()
{
//首先是请求获得的资源viewId
String viewId = .....
//然后根据资源的viewId来获得我们pass的参数beanId
//然后,我们根据这个beanId 从数据库或者缓存池中获得bean对象。对requestScope的bean对象进行了初始化。
//然后我们在新的页面上进行显示edit,获得detail的数据
}
[size=medium]我的这种方案,只是解决了点击一个链接的问题,当然如果是一个在本页的操作,我们也是可以执行了,比如说delete操作,JSF在前几个周期的时候 仍然是可以接收到我们传来的beanId的值,但是,然后我们还是在那里将操作进行execute。
这只是我们解决方案,欢迎大家来讨论。毕竟这个<h:dataTable/> 和<h:commandLink/>结合的场景很是常见。[/size]