由于该演示只强调了JSF的优点，因此我也想听听另一面的信息。
所以我的问题是：
Java Server Faces 2.0的主要缺点是什么？
是什么使JSF开发人员考虑使用ASP.NET MVC而不是JSF？
#1 楼
JSF 2.0的缺点？老实说，除了您对基础Web开发（HTML / CSS / JS，服务器端与客户端等）和基本Java Servlet API（请求/响应/会话）没有扎实的背景知识以外，相对的学习曲线比较陡峭，转发/重定向等），就不会出现严重的不利影响。当前版本的JSF仍需要摆脱早期获得的负面印象，在此期间存在一些严重的缺点。JSF 1.0（2004年3月）
>这是初始版本。您不希望知道的核心和性能方面的错误使它杂乱无章。您的Web应用程序并非总是能如您所愿地工作。
JSF 1.1（2004年5月）
这是bugfix版本。性能仍然没有太大提高。还有一个主要缺点：您不能完美地在JSF页面中内联HTML。所有普通的原始HTML都在JSF组件树之前呈现。您需要将所有普通香草包装在
<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的生命周期内（自从1.2_08版开始，大约在2008年，其代号为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 {}甚至#formIdA fieldId {}的丑陋而奇怪的选择器。另请参见如何在CSS选择器中将JSF生成的HTML元素ID与冒号“：”一起使用？但是，如果您不是纯粹主义者，则也请阅读默认情况下，JSF会生成不可用的ID，这些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创建自定义组件（所谓的复合组件）的功能。另请参见为什么从JSF2.0起，Facelets比JSP更受首选为视图定义语言？
在
<f:ajax>组件的风格中引入了Ajax功能，该组件与Ajax4jsf有很多相似之处。引入了注释和基于约定的增强功能，以尽可能消除冗长的faces-config.xml文件。同样，默认的命名容器ID分隔符:也可以配置，因此HTML / CSS纯粹主义者可以放心使用。您需要做的就是在init-param中将其定义为web.xml，名称为javax.faces.SEPARATOR_CHAR，并确保您自己不在客户端ID的任何地方使用该字符，例如-。最后但并非最不重要的是，引入了一个新的范围，即视图范围。如前所述，它消除了JSF 1.x的另一个主要缺点。您只需要声明bean
@ViewScoped即可启用对话范围，而无需花费所有方法在后续（对话）请求中保留数据。只要您随后以同步或异步方式（Ajax）提交并导航到同一视图（独立于打开的浏览器选项卡/窗口！），即可使用@ViewScoped bean。另请参见托管bean中的View和Request范围之间的区别以及如何选择正确的bean范围？虽然实际上消除了JSF 1.x的所有缺点，但仍有一些JSF 2.0特定的错误可能会变成排行榜。由于部分状态保存中的鸡蛋问题，
@ViewScoped在标记处理程序中失败。这已在JSF 2.2中修复，并在Mojarra 2.1.18中向后移植。同样不支持传递自定义属性，例如HTML5 data-xxx。这在JSF 2.2中已通过新的直通元素/属性功能修复。此外，JSF的实现Mojarra有其自身的问题。相对而言，许多问题与<ui:repeat>有时不直观的行为，新的部分状态保存实现以及Flash范围执行不佳有关。其中大多数已在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和HTML5支持，为什么仍在使用XHTML。 JSF 2.2最重要的新功能是对自定义组件属性的支持，从而开辟了无限可能，例如自定义无表单选按钮组。
除了实现特定的错误和一些“烦人的小事情”（例如无法在验证器/转换器中注入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样板文件。另请参见请求MVC和组件MVC之间的区别。
另请参见：
JSF，Servlet和JSP有什么区别？ （只是为了了解基本知识）
使用JSF开发无表CSS布局（关于JSF的另一个神话）
JSF与普通HTML / CSS / JS / jQuery（当JSF是错误的选择）
Web应用程序中的设计模式（说明了MVC背后的思想）
评论
关于范围：在Java EE 6中，也可以使用将请求扩展到不同视图的范围。这是CDI对话范围。尽管从技术上讲，它不是JSF的一部分，但它与JSF集成得很好，以至于感觉像是本机JSF设施。
– Arjan Tijms
2010-12-19 22:58
尽管如此，ui：repeat需要修复，并且在超过一年的发布之后，两个实现中都嵌套有h：dataTable + ajax的错误是可悲的。真的很可惜，因为如果没有这两个问题，我会向任何人推荐JSF 2.0作为所有Web应用程序开发的解决方案。
–fdreger
2011年1月12日在22:38
很好的答案，但我认为错过了一些有关测试的争论。 JSF很难测试。 ASP.NET MVC已准备好TDD。
– Guaido79
2014-09-17 23:01
我有20年的JAVA / WEB经验，我拒绝使用JSF的所有项目，请不要感到生气，因为JSF是所有框架中最可怕的。它违反了将CSS，HTML和Java混合在一起的所有抽象规则。与例如JSF相比，JSF项目的进展是荒谬的。一个带有Spring MVC项目的ExtJS。 JSF中的维护非常恐怖和简单，否则直接问题将成为JSF中的一个完整集群。以我的经验，不要使用JSF。是否标准，这是一个糟糕的标准，甚至不应该成为标准。尝试使用VAADIM或wicket或ExtJS。
–劳伦斯
2014年10月20日14:15
最大的缺点是它在eclipse IDE中的集成程度中等，没有重构支持，不良的Webfragment支持，不良的Server集成，没有单击和转到组件或包含项，没有组件/标签的依赖图以及没有用于自己或第三方标签的菜单。我花费大量时间执行项目范围的搜索，只是为了了解在何处使用了组件或函数x。
– djmj
2015年4月21日在2:03
#2 楼
在与JSF一起工作了5年之后，我认为我可以多付2美分。JSF的两个主要缺点：
学习曲线很大。 JSF很复杂，这是正确的。
它的组件性质。基于组件的框架试图隐藏Web的真实本质，这带来了大量的复杂性和灾难（例如将近5年不支持JSF中的GET）。
IMHO向开发人员隐藏HTTP请求/响应是一个巨大的错误。根据我的经验，每个基于组件的框架都将抽象添加到Web开发中，这种抽象导致不必要的开销和更高的复杂性。
我想到的还有一些小缺点：
默认情况下，对象的ID由其父母的ID组成，例如form1 ：button1。
没有简单的方法可以注释掉不正确的页面片段。标签
<ui:remove>需要语法正确的内容，无论如何仍要对其进行解析。低质量的第三方组件，例如在继续之前，请不要在
isRendered()方法中检查processXxx()。合并LESS和Sencha很难。
与REST配合不好。
对于UX设计人员而言，这并不是一件容易的事，因为现成的组件具有自己的CSS样式，需要重写。
别误会我的意思。作为第2版中的组件框架，JSF确实不错，但是它仍然是基于组件的，并且将永远...
请看一下Tapestry，Wicket的低普及性以及对Windows的低热情经验丰富的JSF开发人员（更有意义）。
作为对比，请看一下Rails，Grails，Django和Play的成功！框架-它们都是基于动作的，不会试图向程序员隐藏真正的请求/响应和Web的无状态本质。
对我来说，这是JSF的主要缺点。 IMHO JSF可以适合某些类型的应用程序（内部网，表单密集型），但是对于实际的Web应用程序来说，这不是一个好方法。
希望它可以帮助某人选择与前端有关的内容。
评论
+1网络的设计宗旨是无状态的（好或坏），没有人可以更改它（没有理由！）
– Alireza Fattahi
2014年4月30日在7:18
它肯定可以处理大型网站irctc.co.in在jsf中，后者是印度最大的电子商务网站。 。 。但是是的，对于JSF，您对生成的UI没有太多控制。
– Nirbhay Mishra
2014-09-12 11:45
您能否定义什么是现实生活中的Web应用程序？同样，JSF隐藏了请求/响应的本质，这也许是正确的，但是程序员的责任是了解幕后的实际情况。如果您不知道HTTP的工作原理，请先学习JSF或任何其他框架。
– Xtreme Biker
2014-09-22 6:59
#3 楼
突然想到一些缺点：JSF是基于组件的框架。
它具有固有的限制，
必须遵守
component-model。
AFAIK JSF仅支持POST，因此，如果要在某个地方进行GET
做一个简单的servlet / JSP。
大多数组件都尝试在诸如
关系数据库和前端
JavaScript，很多时候这些抽象都是“泄漏的”并且很难调试。
对于初级开发人员而言，这些抽象可能是一个很好的起点。或对特定领域不满意的人（例如前端JavaScript），但是由于涉及多个层次而很难对其性能进行优化，并且大多数使用它们的人几乎不了解幕后情况。
JSF中通常使用的模板机制与Web设计器的工作方式无关。 JSF的WYSIWYG编辑器是原始的，无论如何，您的设计师都会为您提供HTML / CSS，您将不得不花费很多时间进行转换。
不会静态检查EL表达式之类的东西，而不会编译编译器和IDE在发现错误方面做得很好，因此您最终会遇到在运行时必须捕获的错误。这对于像Ruby或PHP这样的动态类型化语言来说可能很好，但是如果我不得不承受Java生态系统的巨大膨胀，我需要为我的模板进行类型化。
总结：花费的时间使用JSF可以避免编写JSP / servlet / bean样板代码，因此可以花10倍的钱使其扩展并完全按照自己的意愿进行操作。
评论
他显然是在指JSF 1.x，并忽略了它是基于组件的MVC框架的事实，同时牢记了基于请求的MVC框架。
– BalusC
2011年1月12日在20:26
1）如果您不希望基于组件的MVC，为什么要使用JSF？ 2）从JSF 2.0开始不存在。 3）域部分不正确。没有JSF组件可以做到这一点。隐含的JS错误，是吗？截至目前，Mojarra的产品已经相当成熟。 4）JSF确实具有陡峭的学习曲线，但这并不一定会使它变糟。 5）可视编辑器无论如何都是史诗般的失败。同样，基于组件的vs基于请求的MVC很重要。 6）这是正确工具的问题，而不是JSF的问题。 Eclipse有插件，而IntelliJ Ultimate则是开箱即用的。
– BalusC
2011年1月12日20:34
@BalusC请原谅我听起来不敬，但问题不是JSF 1 vs. JSF 2，您的回答如“ JSF的历史”一样无关紧要。同样，您声称JSF“没有严重的劣势”的说法也没有承认基本的工程原理，即所有工具都有其局限性，并且在执行其他解决方案的领域也存在局限性。
–凯·帕莱
2011年1月12日在21:05
我认为历史与学习JSF 2.0如何消除旧的缺点非常相关，因为正是这些缺点给JSF带来了负面的历史印象。关于剩余部分，那么我们之间只有一个分歧。
– BalusC
2011年1月12日在21:12
老实说，我不明白为什么您将“基于组件”列为缺点。这就像说“ http的缺点是它是无状态的”。应该进行编辑。当然，http是无状态的事实确实很烂，但是有时这正是我们使用它的原因。与JSF相同。
–arg20
13年2月21日在16:10
#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提供程序）
休眠
焊接
不要忘记容器！以及所有这些配置文件：
GlassFish（2、3等）
JBoss
Tomcat
所以-这就是问题容易吗？当然，只要您要做的就是交互最简单的最基本的Web页面，JSF 2.0就是“轻松”的。
简单地说，JSF 2.0是当今软件世界中最复杂，最繁琐的胶合技术。而且我想不出什么我愿意使用的东西。
评论
其中大多数也适用于任何其他Web框架。您必须了解jQuery才能生产JSF是怎么回事？
– Adrian Grigore
2011-09-20 15:11
JSF只是视图层。现在，您似乎在暗示，使用其他技术，您不需要了解所有这些信息，您能告诉我们哪些吗？
–arg20
13年2月21日在16:13
尽管这些技术是开源的，但它们与维护它们的私人组织紧密相关。也许专有一词不适合您，但也可能正确。
– AlanObject
2014年11月30日22:29
我想为@AlanObject辩护...我觉得他可能是说专有的，因为事实上所有开放源代码项目实际上都是某人“拥有”的。例如MySQL。当他们卖给甲骨文时，他们确实取得了不错的成绩。同样，Java！因此，许多开放源代码项目，即使它们是开放使用/编辑/贡献的，也仍然受您当前使用的每个开放源代码工具固有的规范的约束。因为被某人“拥有”。您不能忽略使用它们所必需的规范。并不是说这是一件坏事:)
–CA Martin
16-4-16的0:04
#5 楼
没有经验的开发人员通常会创建速度非常慢的应用程序，并且代码将非常难看且难以维护。它看似简单，但是如果您想编写好的程序，实际上需要在学习上投入一些资金。
至少在开始时，您经常会“卡在”某些问题上，并且会花更多的时间在互联网上阅读栏杆文章实际起作用：)一段时间后，它会越来越少，但是仍然很烦人。
当您发现问题不是由于您缺乏知识/错误而引起的，而是更加烦人的时候错误。 Mojarra确实是越野车，另外一层组件增加了更多问题。 Richfaces是有史以来编写的最大的废话软件：)不知道它在第4版中的情况如何。我们拥有更好的Primefaces，但是您仍然会遇到bug或缺少功能，尤其是使用更多奇特的组件时。现在，您将需要为Primefaces更新付费。因此，我想说它的错误，但尤其是在2.2版本修复了规范方面的某些问题之后，它变得越来越好。框架变得越来越成熟，但还远远不够完美（也许我的面孔更好吗？）。
我觉得它并不特别灵活。通常，如果您需要非常非常定制的东西，而没有任何组件可以做到这一点-会很痛苦。再次，我从普通开发人员的角度进行讨论-具有截止日期，快速阅读教程以及在卡住时搜索stackoverflow的观点，因为没有时间了解它的真正工作原理：)通常某些组件似乎“几乎”具有了您所需要的，但是可能不完全正确，有时您可能会花费太多时间来使它做您想做的事情：)需要谨慎评估它是创建自己的组件还是折磨现有组件是否更好。实际上，如果您要创建真正独特的东西，我不建议您使用JSF。
总之，我的缺点是：复杂性，开发进度不是很顺利，越野车，缺乏灵活性。
当然也有优势，但这不是您要的。无论如何，根据我在框架方面的经验，其他人可能会有不同的看法，所以最好的方法是试一会儿，看看它是否适合您（只是更复杂-不是天真的示例-JSF确实在这里闪耀：） IMHO最佳用例JSF是业务应用程序，例如CRM等。
#6 楼
“ JSF将输出您无法控制或更改的View层HTML和JavaScript，而无需进入Controller代码。”实际上，JSF为您提供了灵活性，您可以使用标准/第三方组件或创建您自己可以完全控制呈现的内容。这只是使用JSF 2.0创建自定义组件所需的一种xhtml。
#7 楼
我根本不是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服务器提供服务。我只需要学习一个可以在任何地方使用的框架即可。我只需花两分钱。
评论
并且不要忘记，每个客户端框架都需要一个用于安全性，有效性等方面的对等方。
–库克尔特耶
15年7月26日在15:02
当然是。不仅用于安全性和验证，还用于后端和业务逻辑。所有这些都通过restfull Web服务完成。这里的重点是避免在服务器端生成html。
–耶苏斯·洛佩斯（JesúsLópez）
15年7月27日在7:11
#8 楼
我们用JSF开发了一个示例项目（这是一个为期三周的研究，所以我们可能会失去一些东西！）我们尝试使用核心jsf，如果需要组件，我们使用PrimeFaces。
该项目是一个带有导航功能的网站。单击菜单时，应通过ajax加载每个页面。
该站点有两个用例：
带有网格的页面。网格是通过ajax加载的，并且应该支持排序和分页
三步向导页面。每个页面都有客户端验证（用于简单验证）和服务器端ajax基本验证（用于复杂验证）。任何服务器异常（来自服务层）都应显示在向导的同一页上，而无需导航到下一页。
我们发现：
您需要使用omniFaces的一些技巧来修复JSF视图状态。当您通过ajax相互包含页面时，JSF状态将被破坏。这似乎是JSF中的错误，并且可能会在下一发行版中修复（不在2.3中修复）。
JSF Flow无法与ajax一起正常工作（否则我们无法使其工作！）我们尝试改用primeface向导组件但是客户端验证似乎不受支持，这意味着它不是标准的JSF流标准。
当使用jqGird之类的jQuery组件时，您需要加载JSON结果，那么建议您使用纯servlet，JSF将什么都不为你做。因此，如果使用这些类型的组件，则您的设计将不适合JSF。
当
ajaxComplete完成ajax时，我们尝试做一些客户端脚本，并且我们发现PF 4已经实现了自己的ajax事件。我们有一些jQuery组件，我们需要更改其代码。如果将上述示例更改为非Ajax项目（或至少是较少的ajax项目），您将不会遇到很多上述问题。 br />
我们将研究总结为：
JSF在完全基于ajax的网站上无法正常工作。
当然，我们在JSF中发现了许多不错的功能，这些功能在某些项目中可能会非常有用，因此请考虑您的项目需求。
请参阅JSF技术文档以回顾JSF的优势，我认为JSF的最大优势是@BalusC的COMPLETE AND HUGE支持；-)
#9 楼
对我来说，JSF的最大缺点是对以编程方式（动态）生成的页面的支持不佳。如果要从Java代码动态构建页面（创建页面组件模型）。例如，如果您正在使用所见即所得的Web页面构造函数。通常无法获得有关该用例的充分文档。在很多地方，您都必须进行试验，并且开发过程非常缓慢。许多事情只是无法按预期工作。但总的来说，它可能会以某种方式破解。
好消息是，这不是JSF的哲学或体系结构问题。 （据我所知）它还不够详细。
JSF 2带来了Composite Components，这应该使组件开发变得容易，但是对动态（程序）构造的支持却很差。如果您克服了动态复合组件构建过程中安静，复杂且几乎没有文献记载的过程，那么您会发现，如果将一些复合组件嵌套得更深，它们将停止工作，并引发一些异常。
但是，似乎JSF社区已经意识到了这一缺点。正如您从这两个错误中看到的那样，他们正在为此工作http://java.net/jira/browse/JAVASERVERFACES-1309http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-599
情况至少在我们谈论规范时，至少应该在JSF 2.2上更好。
#10 楼
评论我最近几个月的Primefaces / JSF经验：如果可以“现成”使用组件，我想那并不可怕。
但是，当您退出并需要自定义UI时，它并不能很好地发挥作用。 -例如，我们需要在项目中使用Twitter的引导程序。 （不是primefaces引导程序）。
现在我们的页面工作方式如下：
页面加载。
用户与具有ajax功能的Primefaces交互
引导程序的javascript绑定中断
我们运行额外的javascript来重新绑定所有内容
JSF避免编写JavaScript的承诺变成了比不使用Primefaces编写更多的javascript，并且该javascript可以解决Primefaces的不足。
水槽-除非您再次使用“现成的”东西。当必须与Selenium一起使用时，也真的很难看（Primefaces）。这一切都可以完成-但是又一次-只有那么多时间。
如果您正在与UX /设计团队合作并且需要在UI上快速迭代，则绝对可以避免这种情况。通过学习jquery /编写纯HTML或查看react / angular可以节省时间。
评论
不，您结合使用引导程序和质数符号的选择导致编写了比所需更多的JavaScript。可以使用底部或PF响应。硒的使用又如何丑陋呢？请详细说明。
–库克尔特耶
2015年7月26日15:00
这是硒的例子。 HTLM复选框： Primefaces复选框：
– rprasad
2015年7月27日在16:43
您的意思是串联的名称？美在旁观者的眼中。如果您学到一点xpath，可以轻松解决它。这不是专门针对PF的事情。关于设计团队的事情。让他们设计模板，其余的遵循jquery-ui准则。为我们完美地工作...
–库克尔特耶
15年7月27日在16:48
我后来加入了该项目，但与本演示文稿类似的问题，该演示文稿的项目以bootfaces开始，但实际上确实需要完整的引导程序（+ primefaces）：oracleus.activeevents.com/2014/connect/…
– rprasad
15年7月27日在16:50
该应用程序可以正常工作-无论如何，Primefaces都不是表演的障碍-但存在（并将继续存在）额外的时间消耗。例如特别是与使用Play和Django等框架的同事相比。 （同意您的其他观点，我认为QA应该能够在需要时使用xpath －我给了他们工作脚本）
– rprasad
15年7月27日在16:52
#11 楼
JSF有很多优点，但缺点是让我加几个要点。在一定时间范围内实施Web项目的实际场景中，您需要注意以下因素。
团队中是否有足够的高级成员可以提出适合每种情况的最佳控制方法？
您是否有足够的带宽来适应初始学习
您是否在团队中拥有足够的专业知识，可以审查开发人员生产的JSF
产品？最终无法维护的代码库中。
#12 楼
JSF只有一个缺点：在开始“ JSF”开发之前，您应该清楚地了解Web开发，核心Java和前端体系结构。如今，“新” JavaScript框架只是尝试复制/粘贴“ JSF”基于组件的模型。
评论
坦白说，我们应该摆脱所有这些组件，Bean，“功能”废话，然后回到正常的编码。我不希望有一个笨拙的框架来尝试为我做所有事情（我可能会做得很可怕）并使我远离下面的实际情况。我建议您看一下TypeScript，并尝试找到可以在此基础上构建的非常薄的代码层。 JSF / PF和朋友有很多“功能”，但是您必须热切地了解它们，并知道正确的魔术属性代码或树形布局才能执行所需的操作等。