JSF隐式与显式导航

我正在考虑在我的Web应用程序中使用显式的页面导航规则，当我来到这个 SO问题/答案，以下摘录它：

自JSF 2.0以来，导航规则已经过时，这要归功于新的“隐式导航”function。

不过，我已经阅读了大部分的CoreServlets JSF 2.0教程 ，并且有一个专门讨论显式页面导航的小节，并且对此进行了有益的讨论。 要么这是违背上述build议，还是我误解了一些东西。

我不想以过时的方式创build一个新的Web应用程序。 任何人都可以摆脱任何光？

Answer 1

这是有点主观的，但阿拉，它归结为以下几点：

1. XML中的导航规则是一个维护地狱。

2. 使用导航规则表明，有问题的Web应用程序遭受导致不良用户体验（页面不可collections）的“背后的一个URL”问题。

3. 使用导航规则表明，有问题的Web应用程序使用POST进行页面到页面导航，这不仅导致不良的用户体验（页面不可collections），而且还导致不好的SEO（机器人不索引POST，因此POST导航公共search引擎无法访问网页）。

也可以看看：

• 如何在JSF中导航？ 如何使URL反映当前页面（而不是以前的页面）
• 可collections性通过查看参数function
• 什么时候应该使用h：outputLink而不是h：commandLink？
• JSF 2.0中的通信 – 隐式导航

Answer 2

从纯粹的技术angular度来看，导航规则并不是过时的，因为既没有规范也没有任何API标记为过时，不赞成使用，或者修剪候选人。

事实上，他们已经在JSF 2.2中获得了一些复兴，并且具有面向可重用模块的Faces Flowfunction。

这在实践中肯定地说，当脸部stream动function没有使用时，我从来没有看到太多的用于导航规则的XML。 他们理论上会使维护更容易（IIRC，这是他们最初的devise目标之一），但在实践中，因为BalusC提到它只会导致维护地狱。

但是BalusC也提到，这是主观的。 有些人仍然喜欢主要定义托pipe的bean，注入（布线），实体映射以及XML中的哪些内容，而不是注释（以及只有尽可能覆盖XML或用于全局事物）。

在我看来，导航规则主要反映了JSF最初尝试从HTTP中抽象得太多，并呈现更高层次的类似桌面的编程模型。 在那个模型中redirect到一个带有查询参数的URL，并没有一个真正的地方。 一段时间以来（从JSF 2.0开始）JSF已经进入了一个更加中等的模式，在这个模式中，普通的GET请求和PRG（Post-Redirect-GET）更受欢迎。 遵循这个新的模型，你的确可以说导航规则没有地方，即有效的过时。

Answer 3

你也可以使用。

在xml代码中显式的意思是，这导致：

1. 更多的开销，特别是如果条件复杂（你必须匹配操作方法的结果与期望值）。

   1b）如果有拼写错误，隐式导航可能会导致404错误。显式会导致错误的页面。

2. 您可以使用工具在GUI中绘制规则，以后生成faces-config.xml 。

3. 在后期，更改规则意味着更改XML（您不需要重新编译）。 如果您更改了URL / JSF页面名称，则不需要重新编译。

我会说使用一个或另一个是一个偏好的问题，我很高兴使用隐式导航。