带有POJO和Converter的selectOneMenu的选择选项错误 [英] Wrong selected option for selectOneMenu with POJOs and Converter
问题描述
在我们公司中，我们遇到了一个严重的问题，如果这是正常现象，我们认为这是JSF规范的一个严重设计缺陷.
in our company we're hitting a serious problem which we think is a serious design flaw of the JSF spec, if it is the normal behavior.
这是我们的用例:
- SelectOneMenu(标准的JSF或素词，没关系，相同的行为)
- SelectItems，其值为数据库实体，字符串为标签
- 一个转换器(通过selectOneMenu上的属性)，将实体转换为其ID(getAsString)，并从ID转换为实体(getAsObject)
只要使用与selectItems内部的实体相同的entityManager来加载selectOneMenu的 value 属性内的实体，一切都会按预期进行.我们具有相同的POJO，因此具有相同的哈希码(Object#equals()返回true).但是，只要其中一个实体是通过不同的entityManager加载的，因此具有不同的哈希码，我们就永远无法获得匹配项来生成选择项的预期 selected 属性(HTML<选项/>).
Everything works as expected as long as the entity inside the value attribute of the selectOneMenu is loaded using the same entityManager as the entities inside the selectItems. We have the same POJOs and therefore the same hashcode (Object#equals() returns true). But as soon as one of the entities is loaded via a different entityManager and therefore has a different hashcode, we are never able to get a match to generate the expected selected attribute of an select item (HTML <option /> ).
此行为的原因是，JSF-impl和质数词都在调用中使用了POJO
The cause of this behavior is, that the JSF-impl and primefaces both use the POJOs in the call
boolean selected = isSelected(context, menu, itemValue, valuesArray, converter);
用于itemValue和valuesArray. isSelected 的实现依赖于POJO的Object#equals().我认为，如果我们有Converter，则应始终使用Converter#getAsString的值并将其传递给 isSelected .这也是POST请求的行为.在这里，我们获得了selectOneMenu的SubmittedValue，它与POJO的转换后的值(Converter#getAsString)进行了比较.
for itemValue and valuesArray. The implementation of isSelected relies on Object#equals() for POJOs. In my opinion it should always use the value of Converter#getAsString if we have a Converter and pass it to isSelected. This is also the behavior for a POST request. Here we got a submittedValue for the selectOneMenu which is compared to the converted value of the POJO (Converter#getAsString).
现在是问题 : 这是规范中描述的预期行为吗?转换器的输出不是处理这种比较的更好方法吗?现在，我们必须修改实体类并覆盖equals方法，以便能够使用此构造.
Now the question: Is this the expected behavior as it's described in the spec? Isn't the output of the converter the better way to handle this comparision? Now we have to modify our entity classes and overwrite the equals method to be able to use this construct.
推荐答案
您的错误是您忘记实施/自动生成equals()(和hashCode())方法以符合合同规定.这是JSF无法控制的.将指责的手指指向JSF没有任何意义.
Your mistake is that you forgot to implement/autogenerate equals() (and hashCode()) method conform the contract. This is beyond control of JSF. Pointing the accusing finger to JSF isn't making any sense.
拥有一个基础实体很方便，您的所有实体都从该实体延伸而来，因此您无需在所有实体上重复该任务(即使普通的IDE/工具可以轻松地自动生成它们).您可以在第二个另请参阅"链接中找到详细的示例.
It's handy to have a base entity where all your entities extend from so that you don't need to repeat the task over all entities (even though the average IDE/tool can easily autogenerate them). You can find an elaborate example in 2nd "See also" link.
- Validation Error: Value is not valid
- Implement converters for entities with Java Generics
这篇关于带有POJO和Converter的selectOneMenu的选择选项错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
