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

Question

昨天我看了一个关于Java Server Faces 2.0的演示，它看起来真的很不错，尽管我目前是一个快乐的ASP.NET MVC / jQuery开发人员。我最喜欢JSF的地方在于它拥有大量启用AJAX的UI组件，这似乎使得在AJAX-heavy的网站上开发比使用ASP.NET MVC更快。集成测试也看起来非常好。

由于演示只强调了JSF的优点，我想听听另一面的声音。

所以我的问题是：

• Java Server Faces 2.0的主要缺点是什么？
• 可能会让JSF开发者考虑使用ASP.NET MVC而不是JSF的原因是什么？

- Adrian Grigore

---

坦率地说，我们应该摆脱所有这些组件、Bean、“特性”等东西，回归正常编码。我不想要一个厚重的框架来尝试为我做所有事情（而且可能会做得很糟糕），并将我与底层实际发生的事情隔离开来。我建议看一下 TypeScript，并尝试找到与之配合并构建在其上的非常薄的代码层。JSF/PF和它们的朋友们有很多“特性”，但是你必须小心谨慎地绕过它们，并知道正确的魔术属性代码或树形布局来达到自己想要的效果。 - Andrew

Answer 1

JSF 2.0有哪些缺点？除了在基本Web开发（HTML/CSS/JS、服务器端与客户端等）和基本Java Servlet API（请求/响应/会话、转发/重定向等）方面没有坚实的背景知识时相对陡峭的学习曲线，我想不出任何严重的缺点。在当前版本中，JSF仍需要摆脱早期时代获得的负面形象，当时存在一些严重的缺点。

JSF 1.0（2004年3月）

这是最初的版本。它在核心和性能领域都有许多错误，你不想知道。你的Web应用程序并不总是按你直觉的预期工作。作为开发人员，你会跑得很远，并大声哭泣。

JSF 1.1（2004年5月）

这是一个错误修复版本，性能仍然没有得到很大改进。还有一个主要的缺点：无法在JSF页面中完美地嵌入HTML。所有普通的HTML都会在JSF组件树之前渲染。您需要将所有普通HTML包装在<f：verbatim>标签中，以便它们被包含在JSF组件树中。尽管这符合规范，但它受到了很多批评。另请参见JSF / Facelets：为什么不能将JSF / Facelets与HTML标记混合使用？ 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）唯一的严重缺点是在请求范围和会话范围之间缺少一个作用域，即所谓的“对话”作用域。这迫使开发人员使用隐藏的输入元素，不必要的数据库查询和/或滥用会话范围，以便在后续请求中保留初始模型数据，以成功处理验证、转换、模型更改和操作调用等更复杂的Web应用程序。可以通过采用第三方库来减轻痛苦，该库保留了在后续请求中所需的数据，例如MyFaces Tomahawk<t:saveState>组件，JBoss Seam对话范围和MyFaces Orchestra对话框架。

HTML/CSS纯粹主义者的另一个缺点是，JSF使用冒号:作为ID分隔符，以确保在生成的HTML输出中HTML元素id的唯一性，特别是当组件在视图中重复使用时（模板化、迭代组件等）。因为这是CSS标识符中的非法字符，所以你需要使用\来转义CSS选择器中的冒号，从而产生丑陋和奇怪的选择器，例如#formId\:fieldId {}或甚至#formId\3A fieldId {}。参见如何在CSS选择器中使用带有冒号“:”的JSF生成的HTML元素ID？ 然而，如果你不是一个纯粹主义者，请阅读默认情况下，JSF生成的ID无法使用，与Web标准的css部分不兼容。

此外，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?。

引入了Ajax功能，使用<f: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在标签处理程序中失败。这在JSF 2.2中得到了修复，并在Mojarra 2.1.18中进行了回溯。同时传递自定义属性，如HTML5 data-xxx不受支持。JSF 2.2通过新的直通元素/属性功能解决了这个问题。此外，JSF实现Mojarra有其自身的一套问题。其中相当多的问题与<ui:repeat>的行为有时不直观, 新的部分状态保存实现和闪存范围实现不佳有关。大部分问题都在Mojarra 2.2.x版本中得到了修复。

在 JSF 2.0 时代，基于 jQuery 和 jQuery UI 的 PrimeFaces 库被引入，成为最受欢迎的 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 vs 基于请求的 MVC

有些人认为JSF的主要缺点是它允许对生成的HTML/CSS/JS进行非常少的精细控制。这不是JSF本身的问题，而是因为它是一个基于组件的MVC框架，而不是一个基于请求（动作）的MVC框架。如果在考虑MVC框架时，对HTML/CSS/JS的高度控制是您的主要需求，那么您应该已经不再寻找基于组件的MVC框架，而是寻找基于请求的MVC框架，如Spring MVC。您只需要考虑自己必须编写所有HTML/CSS/JS样板代码。另请参阅请求MVC和组件MVC之间的区别。

另请参阅：

• JSF、Servlet和JSP有什么区别？（只是为了了解基础知识）
• 使用JSF开发无表格CSS布局（关于JSF的另一个误解）
• JSF与纯HTML/CSS/JS/jQuery相比（当JSF不是正确选择时）
• Web应用程序中的设计模式（阐述MVC背后的思想）

- BalusC

---

关于作用域：在Java EE 6中，还可以使用跨越不同视图请求的作用域。这就是CDI对话作用域。虽然技术上不是JSF的一部分，但它与JSF集成得非常好，感觉就像是本地的JSF功能。 - Arjan Tijms

尽管如此，ui:repeat需要修复，并且在两种实现中，嵌套的h:dataTable + ajax的错误令人失望，这已经超过了一个版本年限。真遗憾，因为如果不是这两个问题，我会向任何人极力推荐JSF 2.0作为所有Web应用程序开发的解决方案。 - fdreger

不错的回答，但我认为缺少了一些关于测试的参数。 JSF 很难测试。ASP.NET MVC 是 TDD 准备好的。 - Guaido79

我有20年的JAVA/WEB开发经验，但我拒绝所有使用JSF框架的项目。请不要感到冒犯，我认为JSF是所有框架中最糟糕的一个，它违反了所有抽象规则，将CSS、HTML和Java混合在一起。与例如采用Spring MVC框架和ExtJS的项目相比，JSF项目的进展非常缓慢。在JSF中进行维护工作十分困难，简单的问题也会在其中变得非常复杂。根据我的经验，请不要使用JSF。不管是否标准，它都是一个糟糕的标准，甚至不应该成为标准。建议尝试VAADIM、Wicket或者ExtJS。 - Lawrence

它的一个很大的缺点是在eclipse IDE中集成一般，没有重构支持，不良的webfragment支持，糟糕的服务器集成，没有“点击以转到组件或包含”，没有组件/标记的依赖关系图表以及没有自己或第三方标记的菜单。我花了很多时间执行项目范围内的搜索，只为了理解组件或功能x在哪里被使用。 - djmj

Answer 2

在使用JSF 5年后，我认为我可以提出我的看法。

JSF的两个主要缺点：

1. 学习曲线陡峭。JSF很复杂，这是事实。
2. 组件化性质。基于组件的框架试图隐藏Web的真正本质，这带来了大量的复杂和灾难（例如，在近5年中不支持JSF中的GET）。
   在我看来，将HTTP请求/响应从开发人员的视野中隐藏起来是一个巨大的错误。根据我的经验，每一个基于组件的框架都会给Web开发增加抽象层，而该抽象层会导致不必要的开销和更高的复杂性。

我想到的其他一些小缺点：

1. 默认情况下，对象的ID由其父级ID组成，例如form1:button1。
2. 没有简单的方法注释掉不正确的页面片段。标签<ui:remove>需要语法上正确的内容，而这些内容无论如何都会被解析。
3. 低质量的第三方组件，例如在继续进行之前不检查isRendered()的processXxx()方法。
4. 集成LESS和Sencha较困难。
5. 与REST不太兼容。
6. 对于UX设计师来说并不容易，因为现成的组件有自己的CSS样式，需要进行重写。

别误会了。作为一个组件框架，JSF在2版本中非常好，但它仍然是基于组件的，而且一直都是...

请看看Tapestry、Wicket的低流行度以及经验丰富的JSF开发人员的低热情（这更具有意义）。相反，看看Rails、Grails、Django和Play！框架的成功——它们都是基于操作的，不会试图从程序员那里隐藏Web的真正请求/响应和无状态本质。

对我来说，这是JSF的主要缺点。在我看来，JSF适用于某些类型的应用程序（如内部网络和表单密集型），但对于现实生活中的Web应用程序来说，并不是一个好的选择。

希望可以帮助有关前端选择的人。

- G. Demecki

---

+1 网络被设计为无状态，好或坏，没有人可以改变它（也没有理由这样做！） - Alireza Fattahi

它肯定可以处理大型网站，irctc.co.in是印度最大的电子商务网站之一，使用JSF技术。但是，使用JSF技术时，您对生成的用户界面没有太多控制权。 - Nirbhay Mishra

你能定义一下“真实的Web应用程序”是什么吗？此外，JSF隐藏了请求/响应的本质，这可能是真的，但程序员有责任了解在幕后发生的事情。如果您不知道HTTP如何工作，请在学习JSF或任何其他框架之前先学习它。 - Aritz

Answer 3

以下是我想到的一些缺点：

1. JSF是一个组件化的框架。 这有固有的限制，必须遵守组件模型。
2. AFAIK JSF只支持POST方法，所以如果你需要GET方法，就必须使用普通的servlet/JSP。
3. 大多数组件试图在关系数据库和前端JavaScript等领域提供抽象，这些抽象有时是"漏洞百出"的，并且非常难以调试。
4. 对于初级开发人员或不熟悉特定领域（如前端JavaScript）的人来说，这些抽象可能是一个很好的起点，但是对于性能优化来说非常困难，因为涉及到多个层次，并且大多数使用它们的人不太了解底层情况。
5. 通常与JSF一起使用的模板机制与Web设计师的工作无关。用于JSF的所见即所得编辑器很原始，在任何情况下，你的设计师会给你HTML/CSS，你将不得不花费很长时间进行转换。
6. 诸如EL表达式之类的东西没有静态检查，编译器和IDE都无法很好地找到错误，因此你最终会遇到必须在运行时捕获的错误。这对于像Ruby或PHP这样的动态类型语言来说可能很好，但如果我必须忍受Java生态系统的庞杂，我要求我的模板进行编写时进行类型检查。

总之：通过使用JSF避免编写JSP/servlet/bean样板代码所节省的时间，将花费10倍的时间来使其可扩展并做到完全符合你的要求。

- Kay Pale

---

他显然指的是JSF 1.x，并忽略了它是一个基于组件的MVC框架，而他所想的是一个基于请求的MVC框架。 - BalusC

1. 如果你不想要基于组件的MVC，为什么还要看JSF呢？
2. 自从JSF 2.0以后就不是这样了。
3. 关于域名部分是不正确的。JSF没有任何组件会这样做。至于JS实现中是否存在错误，那么Mojarra现在已经相当成熟了。
4. JSF确实有一个陡峭的学习曲线，但这并不一定代表它不好。
5. 可视化编辑器无论如何都很失败。同样，组件化和请求式MVC也很重要。
6. 这取决于选择正确的工具，而不是JSF本身的问题。Eclipse有插件，IntelliJ Ultimate则自带此功能。

- BalusC

如果我听起来不尊重，请原谅，但问题不在于JSF 1与JSF 2的比较，而您的回答看起来像是“JSF的历史”，这与问题无关。此外，您声称JSF没有“严重的缺点”，未能承认所有工具都有其局限性和在某些领域中表现优于其他方案的基本工程原则。 - Kay Pale

我认为学习历史非常重要，以了解JSF 2.0如何消除旧有的缺陷，因为正是这些缺陷导致了JSF在历史上产生了负面印象。至于剩下的部分，那么我们只是存在分歧。 - BalusC

老实说，我不理解你为什么把“组件化”列为缺点。这就好像说“http的缺点是无状态”一样。这应该进行编辑。当然，有时候http是无状态的事实很糟糕，但有时正是这个原因我们才使用它。JSF也是如此。 - arg20

Answer 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
• MyFaces
• ICEFaces
• EclipseLink（我的JPA提供商）
• Hibernate
• Weld

别忘了容器！以及那些配置文件：

• GlassFish（2、3等等）
• JBoss
• Tomcat

所以——这让它变得容易了吗？当你只想做最基本的网页和简单的交互时，JSF 2.0是“简单”的。简而言之，JSF 2.0是软件宇宙中最复杂和笨重的技术混合体，但我想不出还有什么比它更好用的了。

- AlanObject

---

这大部分也适用于其他任何Web框架。JSF需要你掌握jQuery才能高效使用，这怎么能归咎于JSF呢？ - Adrian Grigore

JSF只是视图层。现在你似乎在暗示，使用其他技术不需要了解所有这些，你能否告诉我们具体是哪些技术？ - arg20

尽管这些技术是开源的，但它们与维护它们的私人组织紧密相关。也许对您来说专有这个词不太合适，但它们可能就是如此。 - AlanObject

我想为@AlanObject辩护...我认为他所说的专有可能是指所有开源项目实际上都是由某个人“拥有”的事实。以MySQL为例，当他们被Oracle收购时，他们真的赚了大钱。Java也是如此！因此，许多开源项目，即使它们是开放使用/编辑/贡献的，仍然受到每个当前正在使用的开源工具固有规格的限制。因为它们是由某个人“拥有”的。你不能忽略使用它们所必需的规格。并不是说这是件坏事 :) - CA Martin

我开始学习Java时使用了Swing库，感觉很好。我想用Java进行Web编程，在经历了漫长的研究之后，我深入研究了Primefaces...不用说，那是一场灾难！就框架而言，似乎在不妨碍生产力的前提下管理复杂性很难，而引入可理解的复杂性以赋予开发人员更多的权力则更加困难！无论如何，不断学习是这个行业的默认状态。 - Afroid1000

Answer 5

1. 经验不足的开发者通常会创建应用程序，这些应用程序运行缓慢，代码难看且难以维护。虽然开始看起来简单，但如果你想编写好的程序，则实际上需要一些学习投入。
2. 至少在开始阶段，你经常会在某些问题上“卡住”，花费更多时间阅读 balusc 的文章而非真正工作 :) 过一段时间后，这种情况会越来越少，但仍可能很烦人。
3. 当你发现问题不是由于你缺乏知识/错误而是实际上是一个 bug 时，甚至更烦人。Mojarra（是吗？）相当有 bug，另外一层组件增加了更多问题。Richfaces 是有史以来最烂的软件 :) 不知道现在版本 4 怎么样。我们有 Primefaces，它更好，但是你仍然会遇到 bug 或缺少功能，特别是在使用更奇特的组件时。现在你需要为 Primefaces 更新付费。所以我会说它很有 bug，但它正在变得更好，特别是 2.2 版本修复了规范中的一些问题之后。框架变得更加成熟，但仍远非完美（也许 MyFaces 更好？）。
4. 我并不认为它特别灵活。通常，如果你需要非常定制化的东西，并且没有组件可以做到这一点-那将有点痛苦。再次强调，我是从普通开发人员的角度来看的-那些有截止日期、快速阅读教程并在遇到问题时搜索 StackOverflow 的人，因为没有时间学习实际上如何工作 :) 通常某些组件似乎已经“接近”你想要的，但不完全符合要求，有时你可能会花费太多时间使其做某些你想要的事情 :) 需要仔细评估是否更好创建自己的组件或折磨现有组件。实际上，如果你正在创建真正独特的东西，我不建议使用 JSF。

所以简而言之，我的缺点是：复杂性、开发进展不够顺畅、有 bug、不灵活。

当然也有优点，但这不是你问的。无论如何，这是我对框架的经验，其他人可能持有不同的观点，所以最好只需尝试一段时间，以确定它是否适合你（只是更复杂的东西-不是天真的例子-JSF 在那里真的很出色 :) 我认为 JSF 最好的使用案例是业务应用程序，如 CRM 等...

- Koks Skirtumas

Answer 6

"JSF 会生成视图层的 HTML 和 JavaScript，如果不进入控制器代码，您无法控制或更改这些内容。"

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

- Cagatay Civici

Answer 7

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

我们尽量使用核心JSF，如果需要组件，则使用PrimeFaces。

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

该网站有两种用例：

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

我们发现：

1. 您需要使用OmniFaces中的一些技巧来使JSF视图状态固定。当您通过ajax在彼此之间包含页面时，JSF状态将被破坏。这似乎是JSF中的一个错误，并可能在下一个版本中得到修复（不是2.3版）。
2. JSF流程在ajax中无法正常工作（或者我们无法使它正常工作！）我们尝试使用primeface向导组件，但客户端验证似乎不受支持，同时它也不符合标准JSF流程标准。
3. 当使用一些jQuery组件（如jqGird）并且需要加载JSON结果时，建议您使用纯servlet。JSF对此无能为力。因此，如果您使用这些类型的组件，则设计将不适用于JSF。
4. 我们尝试通过ajaxComplete完成一些客户端脚本，并发现PF 4已经实现了自己的ajax事件。我们有一些jQuery组件，需要更改它们的代码。

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

我们总结了我们的研究：

在完全基于ajax的网站中，JSF的表现并不好。

当然，在某些项目中，JSF提供了许多有用的功能，因此请考虑您的项目需求。

请参考JSF技术文档以审查JSF的优点，而在我看来，JSF最大的优势是来自@BalusC的完整和强大支持;-)

- Alireza Fattahi

Answer 8

我并不是Java Server Faces的专家，但我认为它的主要缺点是它是服务器端的。我已经厌倦了学习和使用服务器端web展示层框架，如ASP.NET Web Forms、ASP.NET MVC、Java Server Faces、Struts、php框架和ruby on rails框架。我和它们说再见，并对Angularjs和TypeScript说Hello。我的展示层在浏览器上运行。无论它是由运行php或ASP.NET的Windows IIS提供还是由运行在Linux上的Apache web服务器提供，都没有关系。我只需要学习一个能够在任何地方工作的框架即可。

仅仅是我的个人意见。

- Jesús López

---

不要忘记，每个客户端框架都需要一个服务器端的配对来确保安全性、验证等。 - Kukeltje

当然可以。这不仅涉及到安全和验证，还包括后端和业务逻辑。所有操作都通过RESTful Web服务完成。这里的重点是避免在服务器端生成HTML。 - Jesús López

JSF和Primefaces非常成熟和稳定。JSF提供了许多客户端处理的替代方案（同时考虑安全方面）。 - Cristian Florescu

Answer 9

对我最近几个月的Primefaces/JSF经验进行评论：

• 如果您可以使用“现成”的组件，那么我想这并不可怕。
• 然而，一旦您走出去需要自定义UI，它就表现不佳。例如，我们需要在项目中使用Twitter的bootstrap（而不是primefaces bootstrap）。
• 现在我们的页面如下工作：
  • 页面加载。
  • 用户与具有ajax功能的Primefaces交互。
  • Bootstrap的javascript绑定断开。
  • 我们运行额外的javascript来重新绑定所有内容。

JSF的承诺是避免编写javascript，但实际上我们编写的javascript比不使用Primefaces还要多，并且该javascript是为了修复Primefaces引起的问题。

这是一个时间浪费 - 除非再次使用“现成”的东西。当使用Selenium时，也非常丑陋（Primefaces）。虽然所有这些都可以完成 - 但再次强调 - 时间有限。

如果您正在与UX/design团队合作并需要快速迭代UI，请务必避免使用此选项 - 您可以通过学习jquery /编写纯HTML或查看react/angular来节省时间。

- rprasad

---

不，你选择结合Bootstrap和PrimeFaces导致你编写了比所需更多的JavaScript。要么使用BootFaces或PF响应性。另外，它与Selenium一起工作为什么很丑陋？请详细说明。 - Kukeltje

这是一个Selenium示例。HTML复选框：<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团队却找不到。 - rprasad

你是指连接的名称吗？美在观者的眼中。如果你学一点xpath，就可以轻松地绕过它。这不是特别的PF事情。关于设计团队的事情。让他们设计模板，其他方面遵循jquery-ui指南。对我们来说完美地解决了问题... - Kukeltje

我后来加入了这个项目，但类似于这个演示文稿的问题，项目最初使用了bootfaces，但实际上需要完整的bootstrap（+primefaces）：https://oracleus.activeevents.com/2014/connect/sessionDetail.ww?SESSION_ID=5475&tclass=popup - rprasad

这个应用程序可以正常工作——Primefaces并不是什么阻碍因素——但是它需要额外的时间成本。例如，与使用Play和Django等框架的同事相比，特别明显。（我同意你的另一个观点，我认为QA应该能够在需要时使用xpath——我已经给他们提供了可用的脚本） - rprasad

Answer 10

对我来说，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情况应该会更好。

- Ondrej Bozek