<h:dataTable/> <h:commandLink/> 的一种解决方案

当我们使用<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的解决代码是

@PostConstruct
public void checkControler()
{
     //首先是请求获得的资源viewId
     String viewId = .....
    //然后根据资源的viewId来获得我们pass的参数beanId
    //然后，我们根据这个beanId 从数据库或者缓存池中获得bean对象。对requestScope的bean对象进行了初始化。
   //然后我们在新的页面上进行显示edit，获得detail的数据
}

我的这种方案，只是解决了点击一个链接的问题，当然如果是一个在本页的操作，我们也是可以执行了，比如说delete操作，JSF在前几个周期的时候 仍然是可以接收到我们传来的beanId的值，但是,然后我们还是在那里将操作进行execute。
这只是我们解决方案，欢迎大家来讨论。毕竟这个<h:dataTable/> 和<h:commandLink/>结合的场景很是常见。