带有 POJO 和转换器的 selectOneMenu 的错误选择选项答案

【问题标题】：Wrong selected option for selectOneMenu with POJOs and Converter带有 POJO 和转换器的 selectOneMenu 的错误选择选项
【发布时间】：2013-12-06 11:47:15
【问题描述】：

在我们公司，我们遇到了一个严重的问题，如果这是正常行为，我们认为这是 JSF 规范的严重设计缺陷。

这是我们的用例：

SelectOneMenu（标准 JSF 或 primefaces，无所谓，行为相同）
SelectItems 以数据库实体为值，以字符串为标签
转换器（通过 selectOneMenu 上的属性）将实体转换为其 ID (getAsString) 并将 ID 转换为实体 (getAsObject)

只要 selectOneMenu 的 value 属性内的实体使用与 selectItems 内的实体相同的 entityManager 加载，一切都会按预期工作。我们有相同的 POJO，因此也有相同的哈希码（Object#equals() 返回 true）。但是一旦其中一个实体通过不同的 entityManager 加载并因此具有不同的哈希码，我们就永远无法获得匹配以生成选择项的预期 selected 属性（HTML ）。

这种行为的原因是，JSF-impl 和 primefaces 都在调用中使用 POJO

boolean selected = isSelected(context, menu, itemValue, valuesArray, converter);

对于 itemValue 和 valuesArray。 isSelected 的实现依赖于 POJO 的 Object#equals()。在我看来，如果我们有一个 Converter 并将它传递给 isSelected，它应该始终使用 Converter#getAsString 的值。这也是 POST 请求的行为。在这里，我们得到了 selectOneMenu 的提交值，它与 POJO 的转换值（Converter#getAsString）进行了比较。

现在的问题：这是规范中描述的预期行为吗？转换器的输出不是处理这种比较的更好方法吗？现在我们必须修改实体类并覆盖 equals 方法才能使用此构造。

【问题讨论】：

标签： jsf-2 primefaces mojarra

【解决方案1】：

您的错误是您忘记实现/自动生成equals()（和hashCode()）方法符合合同。这是 JSF 无法控制的。将指责的手指指向 JSF 没有任何意义。

拥有一个基础实体非常方便，您的所有实体都从该基础实体扩展，这样您就无需对所有实体重复该任务（即使一般的 IDE/工具可以轻松地自动生成它们）。您可以在第二个“另见”链接中找到详细示例。

另见：

【讨论】：

谢谢。我仍然相信，在这两种情况下使用转换器是更好的方法，因为它更一致。我们已经实现了覆盖作为这个问题的“解决方案”，但我对这种行为并不满意。
如果没有它，您还会在其他任何被用作“javabean”的地方遇到麻烦，例如在Set<E> 中收集。
我目前正在测试您的方法并实现了 equals()/hashCode() 但现在我们遇到了一个新问题。当调用其中一种方法并且未加载（外部）实体时，我们遇到了延迟初始化异常。对此有何建议？我们使用 hibernate 4.1.6.Final 作为 JPA 提供者。
@grubi：对于实体，最好按类+PK而不是所有字段进行比较。有关具体示例，另请参见最后一个“另见”链接。
@grubi：我从未见过这个问题。你最好问一个针对 Hibernate/JPA 人员的新问题。

【解决方案2】：

我相信这是正确的行为。在 Java 端，组件和选择的值是 POJO。您可以完全控制它们相等的逻辑等。它如何转换为 UI 显示并返回无关紧要。作为组件用户，您不必费心去了解 POJO 是如何显示的。作为文本、图标、颜色等等。组件的 Java 端不了解并与 POJO 通信

   YOUR CODE ----------> JAVA COMPONENT --------> CONVERTER ----------> HTML

另外我猜想依赖实体的引用相等是一条通往问题的道路。设置 equals/hashCode 使用实际 ID 是最好的方法。

【讨论】：