Jsf 关闭SelectOneMenu内部验证

我有一个由列表驱动的SelectOne菜单，每个菜单包含一个对象值和一个字符串标签，以及一个转换器。一切都相当标准。我最初得到这个错误是因为equals方法中的一个输入错误，但是快速搜索如何修复它会带来另一个问题：

在这种情况下，我的理解是否正确

在菜单中选择一个项目

这将向服务器发送一个字符串值

转换器用于将字符串值转换为对象

JSF检查对象是否存在于项目列表中

setter方法被称为传递对象

如果是，那么我可以禁用步骤4吗？如果值无效，我的转换器将抛出ConverterException，因此对我来说，第二次列表遍历完全没有必要

干杯

---

巴尼这是设计的。这是标准的网站攻击预防措施之一。你不能把它关掉

---

只需将bean放在视图范围内（这样就不会在每次请求时都对其进行重新访问），或者如果它让您感到不安，可以寻找一个不太安全的MVC框架。

这是出于设计。这是标准的网站攻击预防措施之一。你不能把它关掉

---

只要把bean放在视图范围内（这样它就不会在每次请求时都被重新提取，如果这样的话），或者找一个不太安全的MVC框架，如果它困扰你的话。

“你不能关闭它”：是的，这就是我担心的。“…或者寻找一个不太安全的MVC框架…”：对不起，我完全不同意这样的说法，即使此验证成为可选的将使框架更不安全。在检查列表之前，我已经有两次机会验证数据（自定义验证器和转换器）。如果没有其他检查存在，我可以将其视为默认检查，但我仍然认为没有理由强迫我执行完全冗余的验证。要在托管bean中重新创建视图的状态，我们需要与正在“验证”的表单参数完全相同的表单参数，并且JSF阻止这些表单参数进入托管bean。在我看来，这不是一个聪明的设计。“你不能关掉它”：是的，这就是我害怕的。“…或者寻找一个不太安全的MVC框架…”：对不起，我完全不同意这样的说法，即使此验证成为可选的将使框架更不安全。在检查列表之前，我已经有两次机会验证数据（自定义验证器和转换器）。如果没有其他检查存在，我可以将其视为默认检查，但我仍然认为没有理由强迫我执行完全冗余的验证。要在托管bean中重新创建视图的状态，我们需要与正在“验证”的表单参数完全相同的表单参数，并且JSF阻止这些表单参数进入托管bean。在我看来这不是一个聪明的设计。