jsf - 在 EL 表达式 : how to make it robust? 中将数据表对象 var 作为参数传递

Question

在Core JavaServer Faces我们找到以下从 DataTable 中删除行的示例，其中 tableData.names 是 Name 对象的列表:

<h:dataTable value="#{tableData.names}" var="name" ... />    
    <h:commandLink value="Delete" action="#{tableData.deleteRow(name)}" /> 
</h:dataTable>

它带有一个警告，如果我们使用请求范围并且列表在“表的呈现和响应的解码之间”发生变化，则这可能不会删除正确的行。

CAUTION: If the value of the data table has request scope, be sure that the data does not change between the rendering of the table and the decoding of the response (page 226 of the 3rd edition)

谁能用 JSF 生命周期来解释这句话？如果“呈现响应”是 JSF 生命周期的最后阶段，那么“解码响应”适合在哪里？它们是否意味着解码以下回发请求(发送生成的 ID，通过该 ID 来识别行，从而识别名称对象)？

并且:我们如何才能以更稳健的方式实现它？

Answer 1

方法表达式不会在显示表单的请求期间(如书中所述的编码步骤)评估，而是在处理表单提交的请求期间(如书中所述的解码步骤)评估。数据表行的输入和操作是根据表的行索引确定的。在处理表单提交期间，JSF 重新迭代数据模型以找到提交的值和调用的操作。

所以，如果 <h:dataTable value>绑定(bind)到请求范围的 bean，因此数据模型在每个请求的基础上重新初始化，那么您将面临 #{item} 的风险实际上在处理表单提交期间在错误的索引处引用项目，因为在显示表单和提交表单的请求之间，数据库可能已经检索到一个新项目，或者已经删除了另一个项目，这可能会将所需的项目移动到不同的索引。

为了避免这种情况，需要将 bean 放置在 View 范围内，以便在初始请求的(后)构造函数中初始化的完全相同的数据模型将在回传中保留，而无需在开始时重新初始化它每个请求，因此可能包含不同的项目或以不同的顺序。如果数据模型的加载与最终用户完全控制的特定请求参数相关联(如搜索查询)，影响会更大。

另一种替代方法，在这种特定的非幂等“删除此项”情况下实际上是一个坏的选择，但对于幂等的“编辑此项”情况来说是一个好的选择，将改为使用 GET 链接。所需的项目立即呈现为 <a> 的查询字符串参数元素。

<h:link value="Edit" outcome="edit">
    <f:param name="id" value="#{item.id}" />
</h:link>