Java Server Faces 2.0 的主要缺点是什么？

【问题标题】：What are the main disadvantages of Java Server Faces 2.0?Java Server Faces 2.0 的主要缺点是什么？
【发布时间】：2023-03-21 00:51:01
【问题描述】：

昨天我看到一个关于 Java Server Faces 2.0 的演示文稿，看起来确实令人印象深刻，尽管我目前是一名快乐的 ASP.NET MVC / jQuery 开发人员。我最喜欢 JSF 的是大量支持 AJAX 的 UI 组件，它们似乎使开发速度比使用 ASP.NET MVC 快得多，尤其是在 AJAX 重的网站上。集成测试看起来也很不错。

由于演示文稿只强调了 JSF 的优势，我也想了解另一面。

所以我的问题是：

  • Java Server Faces 2.0 的主要缺点是什么？
  • 是什么让 JSF 开发人员考虑使用 ASP.NET MVC 而不是 JSF？

【问题讨论】：

  • 坦率地说，我们应该摆脱所有这些组件，Bean，“功能”垃圾，回到正常编码。我不想要一个厚实的框架，它会试图为我做所有事情（而且做得很糟糕，我可能会补充）并使我远离下面实际发生的事情。我建议看一下 TypeScript，并尝试找到非常薄的代码层，可以使用它并建立在它之上。 JSF/PF 和朋友有很多“特性”，但你必须小心翼翼地绕过它们，知道正确的魔法属性代码或树布局来做你想做的事情等。

标签： asp.net-mvc jsf jsf-2


【解决方案1】：

JSF 2.0 的缺点？老实说，除了当你没有关于basic Web Development（HTML/CSS/JS，服务器端与客户端等）和basic Java Servlet API（请求/响应/会话，转发/重定向等），没有想到严重的缺点。 JSF 在其当前版本中仍然需要摆脱它在早期获得的负面形象，在此期间存在几个严重的缺点。

JSF 1.0（2004 年 3 月）

这是最初的版本。它在你不想知道的核心和性能领域都充满了错误。您的 Web 应用程序并不总是按照您的直觉预期工作。作为开发者的你会哭着跑掉。

JSF 1.1（2004 年 5 月）

这是错误修复版本。性能仍然没有太大改善。还有一个主要缺点：您不能在 JSF 页面中完美地内联 HTML。所有普通的普通 HTML 都在 JSF 组件树之前呈现。您需要将所有普通 vanilla 包装在 <f:verbatim> 标记中，以便它们包含在 JSF 组件树中。虽然这是按照规范，但受到了很多批评。另见 a.o. JSF/Facelets: why is it not a good idea to mix JSF/Facelets with HTML tags?

JSF 1.2（2006 年 5 月）

这是由 Ryan Lubke 领导的新 JSF 开发团队的第一个版本。新团队做了很多很棒的工作。规格也有变化。主要的变化是视图处理的改进。这不仅使 JSF 与 JSP 完全分离，因此可以使用与 JSP 不同的视图技术，而且它还允许开发人员在 JSF 页面中内联普通的普通 HTML，而无需使用 <f:verbatim> 标记。新团队的另一个重点是提高性能。在 Sun JSF 参考实现 1.2（自 2008 年左右构建 1.2_08 以来代号为 Mojarra）的生命周期中，几乎每个构建都附带了（主要）性能改进，以及通常的（次要）错误修复.

JSF 1.x（包括 1.2）唯一严重的缺点是在 request 和 session 范围之间缺少一个范围，即所谓的 对话范围。这迫使开发人员在想要在后续请求中保留初始模型数据以成功处理验证、转换、模型更改和操作调用时，不得不处理隐藏的输入元素、不必要的数据库查询和/或滥用会话范围复杂的网络应用程序。可以通过采用 3rd 方库来减轻痛苦，该库在后续请求中保留必要的数据，例如 MyFaces Tomahawk <t:saveState> 组件、JBoss Seam 对话范围和 MyFaces Orchestra 对话框架。

HTML/CSS 纯粹主义者的另一个缺点是 JSF 使用冒号 : 作为 ID 分隔符来确保生成的 HTML 输出中的 HTML 元素 id 的唯一性，尤其是当一个组件在视图（模板、迭代组件等）。因为这是 CSS 标识符中的非法字符，所以您需要使用 \ 来转义 CSS 选择器中的冒号，从而导致像 #formId\:fieldId {} 甚至 #formId\3A fieldId {} 这样的难看和奇怪的选择器。另请参阅 How to use JSF generated HTML element ID with colon ":" in CSS selectors? 但是，如果您不是纯粹主义者，请参阅 By default, JSF generates unusable ids, which are incompatible with css part of web standards。

此外，JSF 1.x 并没有提供开箱即用的 Ajax 工具。并不是真正的技术劣势，但由于那个时期的 Web 2.0 炒作，它变成了功能劣势。 Exadel很早就引入了Ajax4jsf，经过多年的彻底开发，成为JBoss RichFaces组件库的核心部分。另一个组件库也带有内置的 Ajax 功能，众所周知的是 ICEfaces。

在 JSF 1.2 生命周期的一半左右，引入了一种新的基于 XML 的视图技术：Facelets。这比 JSP 提供了巨大的优势，尤其是在模板领域。

JSF 2.0（2009 年 6 月）

这是第二个主要版本，以 Ajax 为流行语。有很多技术和功能上的变化。 JSP 被 Facelets 取代为默认视图技术，Facelets 扩展了使用纯 XML 创建自定义组件的功能（所谓的composite components）。另见Why Facelets is preferred over JSP as the view definition language from JSF2.0 onwards?

在<f:ajax> 组件的风格中引入了Ajax 功能，该组件与Ajax4jsf 有很多相似之处。 kill 尽可能详细的 faces-config.xml 文件中引入了注释和约定优于配置的增强功能。此外，默认命名容器 ID 分隔符 : 变得可配置，因此 HTML/CSS 纯粹主义者可以松一口气。您需要做的就是在web.xml 中将其定义为init-param，名称为javax.faces.SEPARATOR_CHAR，并确保您自己没有在客户端ID 中的任何位置使用该字符，例如-。

最后但同样重要的是，引入了一个新的范围，即 view 范围。如前所述，它消除了 JSF 1.x 的另一个主要缺点。您只需声明 bean @ViewScoped 以启用对话范围，而无需在后续（对话）请求中使用所有方法来保留数据。只要您随后提交并导航到同一个视图（独立于打开的浏览器选项卡/窗口！），@ViewScoped bean 就会存在，无论是同步还是异步（Ajax）。另见Difference between View and Request scope in managed beans 和How to choose the right bean scope?

尽管几乎消除了 JSF 1.x 的所有缺点，但 JSF 2.0 中的一些特定错误可能会成为一个大问题。 @ViewScoped fails in tag handlers 由于部分状态保存中的鸡蛋问题。这在 JSF 2.2 中得到修复，并在 Mojarra 2.1.18 中向后移植。也不支持passing custom attributes like the HTML5 data-xxx。这在 JSF 2.2 中通过新的传递元素/属性功能得到了修复。此外，JSF 实现 Mojarra 有 its own set of issues。其中相对较多的是与sometimes unintuitive behaviour of <ui:repeat>、new partial state saving implementation 和poorly implemented flash scope 有关。其中大部分已在 Mojarra 2.2.x 版本中修复。

在 JSF 2.0 前后，PrimeFaces 被引入，基于 jQuery 和 jQuery UI。它成为最流行的 JSF 组件库。

JSF 2.2（2013 年 5 月）

随着 JSF 2.2 的引入，HTML5 被用作流行语，尽管从技术上讲，所有旧 JSF 版本都支持它。另见JavaServer Faces 2.2 and HTML5 support, why is XHTML still being used。最重要的 JSF 2.2 新特性是对自定义组件属性的支持，从而打开了无限可能，例如 custom tableless radio button groups。

除了实现特定的错误和一些“烦人的小事”，例如无法在验证器/转换器中注入 EJB（已在 JSF 2.3 中修复）之外，JSF 2.2 规范中并没有真正的主要缺点。

基于组件的 MVC 与基于请求的 MVC

有些人可能会认为 JSF 的主要缺点是它几乎不能对生成的 HTML/CSS/JS 进行细粒度控制。那不是 JSF 自己的，那只是因为它是一个 基于组件的 MVC 框架，而不是一个基于请求（动作）的 MVC 框架。如果在考虑 MVC 框架时，对 HTML/CSS/JS 的高度控制是您的主要要求，那么您应该已经不再关注基于组件的 MVC 框架，而是关注基于请求的 MVC 框架，例如Spring MVC。您只需要考虑到您必须自己编写所有 HTML/CSS/JS 样板。另见Difference between Request MVC and Component MVC。

另见：

【讨论】：

  • 关于范围：在 Java EE 6 中，还可以使用将请求跨越到不同视图的范围。这是 CDI 对话范围。虽然在技术上不是 JSF 本身的一部分，但它与 JSF 集成得非常好，感觉就像一个原生 JSF 工具。
  • 尽管如此，ui:repeat 需要修复，并且在发布一年多之后，这两种实现中嵌套 h:dataTable + ajax 的错误都是可悲的。真的很遗憾，因为如果不是因为这两个问题，我会向 任何人 推荐 JSF 2.0 作为所有 Web 应用程序开发的 解决方案。
  • 不错的答案，但我认为错过了一些关于测试的论点。 JSF 很难测试。 ASP.NET MVC 已准备好 TDD。
  • 我有 20 年的 JAVA / WEB 经验，我拒绝所有像我一样使用 JSF 的项目，请不要生气，觉得 JSF 是所有框架中最可怕的。它违反了将 css、html 和 java 混合在一起的所有抽象规则。 JSF 项目的进展与例如相比是荒谬的。一个带有 Spring MVC 项目的 ExtJS。 JSF 中的维护是可怕的和简单的，否则直接的问题是 JSF 中的一个完整的集群。根据我的经验，不要使用 JSF。标准与否，这是一个糟糕的标准，甚至不应该成为标准。试试 VAADIM 或 wicket 或 ExtJS。
  • 最大的缺点是它在 Eclipse IDE 中的集成平庸，没有重构支持，糟糕的 webfragment 支持，糟糕的服务器集成，没有click and go to component or include，没有组件/标签的依赖关系图，也没有自己或第 3 方的菜单标签。我花了很多时间进行项目范围的搜索，只是为了了解组件或函数 x 的使用位置。
【解决方案2】：

在与 JSF 合作 5 年后，我想我可以加我的 2 美分。

两个JSF的主要缺点：

  1. 大学习曲线。 JSF 很复杂，这是真的。
  2. 它的组件性质。基于组件的框架试图隐藏 Web 的真实本质，这带来了大量的复杂性和灾难（比如在近 5 年内不支持 JSF 中的 GET）。
    恕我直言，向开发人员隐藏 HTTP 请求/响应是一个巨大的错误。根据我的经验，每个基于组件的框架都为 Web 开发添加了抽象，而这种抽象会导致不必要的开销和更高的复杂性。

我想到的次要缺点：

  1. 默认情况下，对象的 ID 由其父 ID 组成，例如 form1:button1。
  2. 没有简单的方法来注释掉不正确的页面片段。标签<ui:remove> 需要语法正确的内容，无论如何都要解析。
  3. 低质量的第 3 方组件，例如在继续之前，不要在 processXxx() 方法中检查 isRendered()。
  4. 合并 LESS 和煎茶很难。
  5. 不能很好地与 REST 配合使用。
  6. 对于 UX 设计师来说并不容易，因为现成的组件有自己的 CSS 样式，需要被覆盖。

不要误会我的意思。作为组件框架，JSF 在版本 2 中确实不错，但它仍然是基于组件的，并且永远是...

请看看 Tapestry、Wicket 的低人气和经验丰富的 JSF 开发人员的低热情（这更有意义）。 相比之下，看看 Rails、Grails、Django、Play 的成功！框架 - 它们都是基于操作的，不会试图向程序员隐藏真正的请求/响应和网络的无状态性质。

对我来说，这是 JSF 的主要缺点。恕我直言，JSF 可以适合某些类型的应用程序（Intranet、表单密集型），但对于现实生活中的 web 应用程序，这不是一个好方法。

希望它能帮助某人选择前端。

【讨论】：

  • +1 网络被设计成无状态的，无论好坏，没有人可以改变它（也没有理由这样做！）
  • 它肯定可以处理大型网站 irctc.co.in 在印度最大的电子商务网站 jsf 中。 . .但是是的，使用 JSF，您对生成的 UI 没有太多控制权。
  • 你能定义什么是real-life web application吗？ JSF 还隐藏了请求/响应的性质，这可能是真的，但程序员有责任了解幕后真正发生的事情。如果您不知道 HTTP 的工作原理，请在 JSF 或任何其他框架之前学习它。
【解决方案3】：

突然想到的一些缺点：

  1. JSF 是一个基于组件的框架。 这具有固有的限制，即 与服从有关 组件模型。
  2. AFAIK JSF 只支持 POST，所以如果你想在某个地方获得 GET 做一个普通的 servlet/JSP。
  3. 大多数组件都尝试提供对域的抽象，例如 关系数据库和前端 JavaScript，很多时候这些 抽象是“有漏洞的”并且很难调试。
  4. 这些抽象对于初级开发人员或不熟悉特定领域（例如前端 JavaScript）的人来说可能是一个很好的起点，但很难优化性能，因为涉及多个层，而且大多数人使用它们的人几乎不了解幕后发生的事情。
  5. 通常与 JSF 一起使用的模板机制与 Web 设计者的工作方式无关。 JSF 的 WYSIWYG 编辑器是原始的，无论如何，您的设计师会为您提供 HTML/CSS，您必须花费很长时间进行转换。
  6. EL 表达式之类的东西不是静态检查的，编译器和 IDE 都不能很好地发现错误，因此您最终会遇到必须在运行时捕获的错误。这对于像 Ruby 或 PHP 这样的动态类型语言来说可能很好，但如果我必须承受 Java 生态系统的极度膨胀，我需要为我的模板输入类型。

总结一下： 使用 JSF 节省的时间，从避免编写 JSP/servlet/bean 样板代码到您将花费 10 倍的时间来使其可扩展并完全按照您的意愿行事想要这样做。

【讨论】：

  • 他显然指的是 JSF 1.x，并忽略了它是一个基于组件的 MVC 框架同时考虑到一个基于请求的 MVC 框架这一事实。
  • 1) 如果您不想要基于组件的 MVC，您为什么要看 JSF？ 2) 自 JSF 2.0 起不再存在。 3) 域部分不真实。 JSF 组件都没有这样做。 impl 中的 JS 错误，嗯，有吗？到目前为止，Mojarra 已经相当成熟了。 4) JSF 确实有一个陡峭的学习曲线，但这并不一定是坏事。 5) 无论如何，可视化编辑器都是史诗般的失败。同样，基于组件与基于请求的 MVC 很重要。 6) 这是正确工具的问题，而不是 JSF 的问题。 Eclipse 有插件，而 IntelliJ Ultimate 开箱即用。
  • @BalusC 如果我听起来不尊重，请原谅我，但问题不是 JSF 1 与 JSF 2，您的答案读作“JSF 的历史”是无关紧要的。此外，您声称 JSF“没有严重的缺点”也未能承认基本工程原则，即所有工具都有其局限性以及它们在执行其他解决方案的领域。
  • 我认为历史与了解 JSF 2.0 如何消除旧的缺点非常相关，因为正是这些缺点使 JSF 在历史上留下了负面形象。至于残余，那么我们只是有分歧。
  • 老实说，我不明白您为什么将“基于组件”列为劣势。这就像说“http的缺点是它是无状态的”..应该编辑。当然，有时 http 是无状态的事实很糟糕，但有时这正是我们使用它的原因。 JSF 也是如此。
【解决方案4】：

对我而言，JSF 2.0 的最大缺点不仅在于 JSF 的学习曲线，还在于您必须使用组件库才能使其完成有用的工作。考虑一下您所处理的数量惊人的规范和标准，才能真正精通：

  • 各种形式的 HTML。不要假装你不需要知道。
  • HTTP -- 当你不知道发生了什么时，你必须打开 Firebug 看看。为此，您需要了解这一点。
  • CSS——不管你喜不喜欢。确实还不错，至少有一些不错的工具。
  • XML -- JSF 可能会是您在这种程度上首先使用命名空间的地方。
  • Servlet 规范。迟早你会在这个包中调用方法。除此之外，您还必须知道您的 Facelets 是如何变成 XHTML 或其他什么的。
  • JSP（主要是为了让您知道为什么在 JSF 中不需要它）
  • JSTL（再次强调，主要是为了应对遗留框架）
  • 各种形式的表达式语言 (EL)。
  • ECMAScript、JavaScript 或任何您想调用的名称。
  • JSON -- 即使你不使用它，你也应该知道这一点。
  • AJAX。我会说 JSF 2.0 在向您隐藏这一点方面做得不错，但您仍然需要知道发生了什么。
  • DOM。以及浏览器如何使用它。请参阅 ECMAScript。
  • DOM 事件 -- 一个完全独立的主题。
  • Java 持久性架构 (JPA)，如果您希望您的应用程序具有任何后端数据库。
  • Java 本身。
  • JSEE 当你在它的时候。
  • 上下文依赖注入规范 (CDI) 及其与 JSF 2.0 的冲突和使用方式
  • JQuery -- 我希望看到你在没有它的情况下也能相处。

现在，一旦您完成了这些，您就可以继续使用专有规范，即您将在此过程中使用的组件库和提供程序库：

  • PrimeFaces（我选择的组件库）
  • RichFaces
  • 我的面孔
  • ICEFaces
  • EclipseLink（我的 JPA 提供程序）
  • 休眠
  • 焊接

别忘了容器！以及所有这些配置文件：

  • GlassFish（2、3 等）
  • JBoss
  • 雄猫

那么——这很容易吗？当然，只要您想做的只是最基本的网页和最简单的交互，JSF 2.0 就是“简单”的。

简而言之，JSF 2.0 是当今软件世界中最复杂、最繁琐的技术组合。而且我想不出我更愿意使用的任何东西。

【讨论】：

  • 这大部分也适用于任何其他 Web 框架。你必须了解 jQuery 才能高效地使用它，这是 JSF 的错吗？
  • JSF 只是视图层。现在您似乎在暗示使用其他技术您不需要了解所有这些，您能告诉我们哪些吗？
  • 虽然这些技术是开源的，但它们与维护它们的私人组织密切相关。也许专有这个词不适合您，但他们也可以。
  • 我想为@AlanObject 辩护......我觉得他的意思可能是专有的，因为所有开源项目实际上都是由某人“拥有”的。 . 以 MySQL 为例。当他们卖给甲骨文时，他们真的得分很高。 Java 也一样！！因此，很多时候开源项目，即使它们可以被使用/编辑/贡献，仍然受制于您当前使用的每个开源工具的固有规范。因为被某人“拥有”。您不能忽略使用它们所必需的规范。并不是说这是一件坏事:)
  • 我开始使用 Swing 库学习 Java，生活很美好。我想用 Java 进行 Web 编程，经过大量研究后，我深入研究了 Primefaces..不用说这是一场灾难！ 就框架而言，管理复杂性而不妨碍生产力似乎很困难，而引入可理解的复杂性以赋予开发人员更多的权力则更加困难！ 无论哪种方式，不断学习都是最重要的这个行业的默认状态。
【解决方案5】：
  1. 没有经验的开发人员通常会创建非常缓慢的应用程序，并且代码会非常难看且难以维护。上手看似简单，但如果您想编写好的程序，实际上需要在学习上进行一些投资。
  2. 至少在开始时，您经常会“卡”在一些问题上，并且会花更多时间在互联网上阅读 balusc 帖子而不是实际工作 :) 一段时间后它会越来越少，但它仍然可能很烦人.
  3. 当您发现问题不是由于您缺乏知识/错误而实际上是一个错误时，就更烦人了。 Mojarra 是（是？）相当多的错误，另一层组件增加了更多问题。 Richfaces 是有史以来最大的垃圾软件 :) 不知道它现在在第 4 版上如何。我们有更好的 Primefaces，但您仍然会遇到错误或缺乏功能，尤其是使用更多奇特的组件。现在您需要为 Primefaces 更新付费。所以我会说它有问题，但它变得更好，特别是在 2.2 版本修复了一些规范问题之后。框架越来越成熟，但仍远未达到完美（也许 myfaces 更好？）。
  4. 我觉得它不是特别灵活。通常，如果您需要非常定制的东西并且没有组件可以做到这一点 - 这会有点痛苦。我再次从普通开发人员的角度谈论 - 有截止日期、快速阅读教程和在卡住时搜索 stackoverflow，因为没有时间了解它是如何工作的 :) 通常某些组件似乎“几乎”有你需要的东西，但是不完全是，有时您可能会花费太多时间来让它做您想做的事情:) 需要谨慎评估是否更好地创建自己的组件或折磨现有组件。实际上，如果您要创建一些真正独特的东西，我不会推荐 JSF。

所以简而言之，我的缺点是：复杂，开发进度不是很顺利，有缺陷，不灵活。

当然也有优点，但你问的不是这个。无论如何，这是我对框架的经验，其他人可能有不同的意见，所以最好的方法是尝试一段时间看看它是否适合你（只是一些更复杂的东西 - 不是天真的例子 - JSF 真的在那里闪耀:) 恕我直言，最好的用例JSF 是业务应用程序，如 CRM 等...

【讨论】：

    【解决方案6】：

    “JSF 将输出视图层 HTML 和 JavaScript，如果不进入控制器代码，您将无法控制或更改。”

    实际上，JSF 为您提供了灵活性，您可以使用标准/第三方组件或创建您自己的组件，您可以完全控制呈现的内容。它只是您使用 JSF 2.0 创建自定义组件所需的一个 xhtml。

    【讨论】：

      【解决方案7】：

      我们使用 JSF 开发了一个示例项目（这是一个为期三周的研究，所以我们可能会丢失一些东西！）

      我们尝试使用核心jsf，如果需要组件我们使用PrimeFaces。

      该项目是一个带导航的网站。单击菜单时，应通过 ajax 加载每个页面。

      该网站有两个用例：

      1. 带有网格的页面。网格是通过 ajax 加载的，应该支持排序和分页
      2. 三步向导页面。每个页面都有客户端验证（用于简单验证）和服务器端 ajax 基础验证（用于复杂验证）。任何服务器异常（来自服务层）都应显示在向导的同一页面上，而无需导航到下一页。

      我们发现：

      1. 您需要使用来自 omniFaces 的一些技巧来修复 JSF 视图状态。当您通过 ajax 相互包含页面时，JSF 状态将被破坏。这似乎是 JSF 中的一个错误，可能会在下一个版本中修复（不是 2.3）。
      2. JSF 流无法与 ajax 一起正常工作（或者我们无法使其工作！）我们尝试使用 primeface 向导组件，但客户端验证似乎不受支持，这意味着它不是标准的 JSF 流标准。李>
      3. 当使用jqGird等一些jQuery组件，并且需要加载JSON结果时，建议使用纯servlet，JSF不会为你做任何事情。因此，如果您使用这些类型的组件，您的设计将不适合 JSF。
      4. 当 ajax 由ajaxComplete 完成时，我们尝试执行一些客户端脚本，我们发现 PF 4 已经实现了自己的 ajax 事件。我们有一些 jQuery 组件，我们需要更改它们的代码。

      如果您将上述示例更改为非 Ajax 项目（或至少更少的 ajax 项目），您将不会遇到上述很多问题。

      我们将我们的研究总结为：

      JSF 在完全基于 ajax 的网站中运行不佳。

      当然，我们在 JSF 中发现了许多不错的特性，这些特性在某些项目中可能非常有用，因此请考虑您的项目需求。

      请参考 JSF 技术文档来回顾 JSF 的优势，在我看来 JSF 的最大优势是来自@BalusC 的完整和巨大的支持 ;-)

      【讨论】：

        【解决方案8】：

        我根本不是 Java Server Faces 专家。但恕我直言，主要缺点是它是服务器端。我厌倦了学习和使用服务器端 Web 表示层框架，如 ASP.NET Web 窗体、ASP.NET MVC、Java Server Faces、Struts、php 框架和 ruby​​ on rails 框架。我向他们所有人告别，向 Angularjs 和 TypeScript 打招呼。我的表示层在浏览器上运行。不管它是由运行 php 或 ASP.NET 的 Windows IIS 提供服务，还是由在 Linux 上运行的 Apache Web 服务器提供服务。我只需要学习一个适用于任何地方的框架。

        只要我的两分钱。

        【讨论】：

        • 并且不要忘记每个客户端框架都需要一个客户端对应的安全性、验证等。
        • 是的，当然。不仅用于安全和验证，还用于后端和业务逻辑。全部通过 restfull 网络服务完成。这里的重点是避免在服务器端生成html。
        • JSF 和 Primefaces 成熟且非常稳定。 JSF 为客户端处理提供了许多替代方案（也接受安全方面）。
        【解决方案9】：

        对我来说，JSF 的最大缺点是对以编程方式（动态）生成的页面的支持很差。
        如果您想从 java 代码动态构建您的页面（创建页面组件模型）。例如，如果您正在使用所见即所得的网页构造函数。此用例的充分文档通常不可用。有很多地方您必须进行试验，而开发过程非常缓慢。很多事情并不像你期望的那样工作。但通常它可能会以某种方式破解它。
        好消息是这在 JSF 的哲学或体系结构上都不是问题。只是不够详细（据我所知）。

        JSF 2 带来了复合组件，它应该使组件开发变得容易，但是它们对动态（程序化）构造的支持很差。如果您克服了动态复合组件构建的安静复杂且几乎未记录的过程，您会发现如果您将几个复合组件嵌套得更深一些，它们就会停止工作，并引发一些异常。

        但是 JSF 社区似乎意识到了这个缺点。从这两个错误中可以看出，他们正在努力解决这个问题
        http://java.net/jira/browse/JAVASERVERFACES-1309
        http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-599

        至少如果我们谈论规范的话，JSF 2.2 的情况应该会更好。

        【讨论】：

          【解决方案10】：

          评论我过去几个月的 Primefaces/JSF 经验：

          • 如果您可以使用“现成的”组件，我想这并不可怕。
          • 但是，一旦您走出去并需要自定义 UI，它就不能很好地发挥作用。 - 例如，我们需要为我们的项目使用 Twitter 的引导程序。 （不是 primefaces 引导程序）。
            • 现在我们的页面工作如下：
              • 页面加载。
              • 用户与具有 ajax 功能的 Primefaces 交互
              • Bootstrap 的 javascript 绑定中断
              • 我们运行额外的 javascript 来重新绑定所有内容

          JSF 避免编写 javascript 的承诺变成了编写比不使用 Primefaces 时更多的 javascript——而该 javascript 修复了 Primefaces 破坏的问题。

          这是一个时间槽——除非你再次使用“现成”的东西。必须使用 Selenium 时也非常难看（Primefaces）。这一切都可以完成——但同样——时间有限。

          如果您正在与 UX/设计团队合作，并且需要快速迭代 UI，请务必避免这种情况——您可以通过学习 jquery/编写直接 HTML 或查看 react/angular 来节省时间。

          【讨论】：

          • 不，您选择结合 bootstrap 和 primefaces 导致您编写的 javascript 超出了需要。使用 bootfaces 或 PF 响应。使用硒有什么难看的？请详细说明。
          • 这是一个硒的例子。 HTLM 复选框：<input type="checkbox" name="versionsTab" value="version1"> Primefaces 复选框：<div class="ui-chkbox ui-widget"> <div class="ui-helper-hidden-accessible"> <input type="checkbox" name="datasetForm:tabView:versionsTable_checkbox"> </div> <div class="ui-chkbox-box ui-widget ui-corner-all ui-state-default"> <span class="ui-chkbox-icon ui-c"></span> </div> </div> Selenium 找不到隐藏的实际复选框。例如我可以通过选择器/编码/等找到它，但技术不高的 QA 团队找不到
          • 你的意思是串联的名字？美在旁观者的眼中。如果你学了一点xpath，就可以轻松绕过它。这不是一个特别的 PF 事情。而关于设计团队的事情。让他们设计模板，其余的则遵循 jquery-ui 指南。非常适合我们...
          • 我后来加入了这个项目，但与这个演示文稿类似的问题是，项目从 bootfaces 开始，但确实需要完整的 bootstrap（+ primefaces）：oracleus.activeevents.com/2014/connect/…
          • 该应用程序有效--Primefaces 无论如何都不是表演的终结者--但有（并且将继续存在）额外的时间槽。例如尤其是与使用 Play 和 Django 等框架的同事相比。 （同意你的另一点，我认为如果需要，QA 应该能够使用 xpath——我给了他们工作脚本）
          【解决方案11】：

          JSF 有很多优点，缺点的问题让我补充几点。

          在一个时间框架内实施网络项目的实际场景中，您需要关注以下因素。

          • 您的团队中是否有足够多的资深成员可以提出最佳建议 适合每个场景的控件？

          • 您是否有足够的带宽来适应初始学习曲线？

          • 您的团队中是否有足够的专业知识来审核 JSF
            开发者生产的东西？

          如果您对这些问题的回答是“否”，那么您最终可能会进入一个不可维护的代码库。

          【讨论】：

            【解决方案12】：

            JSF只有一个缺点：在开始“JSF”开发之前，你应该清楚地了解Web开发、核心java和前端架构。

            如今“新”JavaScript 框架只是尝试复制/粘贴“JSF”基于组件的模型。

            【讨论】：

              【解决方案13】：

              在 Spring MVC、Wicket、Tapestry 等所有“主流”框架中，Java EE 的 JSF 及其复合组件是提供的最精细的表示层和面向组件的技术。与 HybridJava 提供的解决方案相比，它有点繁琐和不完整。

              【讨论】：

                猜你喜欢
                • 1970-01-01
                • 2013-09-17
                • 2010-12-15
                • 2011-06-30
                • 1970-01-01
                • 2010-09-30
                • 2014-02-09
                • 1970-01-01
                • 1970-01-01
                相关资源
                最近更新 更多
                热门标签
                Java Python linux javascript Mysql C# Docker 算法 前端 SpringBoot Redis Vue spring 设计模式 .net core .net kubernetes c++ 数据库 数据结构 大数据 js 机器学习 微服务 Android Go 程序员 面试 JVM ASP.net core 云原生 人工智能 后端 PHP git CSS golang k8s Nginx Django mybatis 深度学习 多线程 React 架构 devops 爬虫 云计算 Spring Boot LeetCode