当我遇到这个SO 问题/答案时,我正在考虑在我的网络应用程序中使用显式页面导航规则,并从中摘录以下内容:
...由于新的“隐式导航”功能,导航规则自 JSF 2.0 以来已过时。
但是,我已经阅读了CoreServlets JSF 2.0 教程的大部分内容,其中有一节专门介绍显式页面导航,并且对此进行了积极的讨论。要么这违背了上述建议,要么我误解了某些东西。
我不想以过时的方式创建新的网络应用程序。任何人都可以解释一下吗?
当我遇到这个SO 问题/答案时,我正在考虑在我的网络应用程序中使用显式页面导航规则,并从中摘录以下内容:
...由于新的“隐式导航”功能,导航规则自 JSF 2.0 以来已过时。
但是,我已经阅读了CoreServlets JSF 2.0 教程的大部分内容,其中有一节专门介绍显式页面导航,并且对此进行了积极的讨论。要么这违背了上述建议,要么我误解了某些东西。
我不想以过时的方式创建新的网络应用程序。任何人都可以解释一下吗?
这有点主观,但是,唉,它归结为以下几点:
XML 中的导航规则是一个维护地狱。
使用导航规则表明有问题的 Web 应用程序存在“一个 URL 后面”问题,这会导致糟糕的用户体验(页面不可收藏)。
使用导航规则表明有问题的 Web 应用程序正在使用 POST 进行页面到页面导航,这不仅会导致糟糕的用户体验(页面不可收藏),还会导致糟糕的 SEO(机器人不索引 POST,因此 POST-navigated公共搜索引擎无法访问页面)。
从纯粹的技术角度来看,导航规则并没有过时,因为规范和任何 API 都没有将它们标记为过时、不推荐或需要修剪的候选者。
事实上,它们在 JSF 2.2 中通过可重用模块的 Faces Flow 特性得到了一定程度的复兴。
这在实践中说,当然当不使用 Faces Flow 功能时,我从未见过 XML 中的导航规则有太多用途。他们理论上会使维护更容易(IIRC 这是他们最初的设计目标之一),但实际上正如 BalusC 提到的那样,它只会导致维护地狱。
但正如 BalusC 也提到的,它是主观的。有些人实际上仍然喜欢主要定义托管 bean、注入(连接)、实体映射以及您在 XML 中而不是使用注释(并且仅使用 XML 作为可能的覆盖或全局事物)。
在我看来,导航规则主要反映了 JSF 最初尝试过多地从 HTTP 中抽象出来并呈现更高级别的类桌面编程模型。在该模型中,重定向到带有查询参数的 URL 并没有真正占有一席之地。一段时间以来(从 JSF 2.0 开始),JSF 已经进入了一个更加中间的模型,其中更容易接受普通的 GET 请求和 PRG(Post-Redirect-GET)。遵循这个新模型,您确实可以说导航规则没有地位,即实际上已经过时了。
你可以使用任何一个。
显式意味着在 xml 代码中,这导致:
更多开销,特别是在条件复杂的情况下(您必须将操作方法的结果与预期值相匹配)。
1b) 如果有错别字,隐式导航可能会导致 404。显式会导致错误页面。
您可以使用工具在 GUI 中绘制规则,然后生成faces-config.xml
.
稍后,更改规则意味着更改 XML(您不需要重新编译)。如果您更改 URL/JSF 页面名称,则无需重新编译。
我会说使用一个或另一个是一个偏好问题,我很高兴使用隐式导航。