JSF进程验证和@RequestScope问题

考虑以下用例。我正在使用

@RequestScoped

支持bean开发JSF表单。此外，我还使用了PrimeFaces，但它与问题没有多大关系

表单字段中的值通过复杂的业务逻辑相互关联。即，一个下拉列表中的值取决于另一个下拉列表中的值，或者一个字段的启用/禁用状态取决于另一个字段中的值。表的内容取决于某些隐藏字段中的视图参数或值

支持bean中的setter将值写入数据模型生成器，getter调用生成器的

build（）

方法，该方法以预定义的顺序应用值并返回不可变的数据模型

@RequestScoped

意味着在回发时（无论是AJAX还是常规请求），表单的支持bean需要从

null

重建。它发生在

更新模型值
阶段

当我们使用selectOneMenu（JSF selectOneMenu或PrimeFaces selectOneMenu-无所谓）或dataTable时，麻烦就开始了。因为在
PROCESS\u VALIDATIONS
阶段（在
UPDATE\u MODEL\u VALUES
之前发生），支持bean仍然没有设置值。上述组件无法通过内置验证，因为请求值与[still empty]集合中的任何值都不对应（为selectOneMenu或dataTable等提供内容）

我找到的一个解决方案是使用支持bean的
@PostConstruct
方法，我们可以手动读取必要的请求值并预先填充所需的集合。但这一解决方案似乎远远不够干净和优雅

此外，我还尝试应用自定义虚拟验证器，但它似乎无法替代内置验证器，因此这不起作用

考虑到我想坚持使用
@RequestScoped
，在这种情况下，专家的建议是什么

谢谢
 这正是
@ViewScoped
存在的原因

如果您不想通过
@ViewScoped
使用JSF的“自动”视图状态管理，那么在每次回发期间手动维护
@RequestScoped
bean的
@PostConstruct
中的视图状态是最好的选择。您最多可以通过
@ManagedProperty
插入参数。具有验证/转换支持的
，由于运行“太晚”，因此根本没有用处

如果您使用的是CDI托管bean，那么JSF实用程序库也有一个支持验证和转换的CDI，这与
@ManagedProperty
相反。这可能进一步减少
@PostConstruct
方法中的样板文件

另见：




谢谢，@BalusC，
@Param
已经完成了！我用
commandButton
传递
f:param
，然后在@PostConstruct中设置它。此外，我还去掉了
f:viewParam
和旧的JSFXML名称空间，这在一些旧的Mojarra版本中存在问题。