An *_*ect 10 html user-interface jsf jsp
最近,我的公司决定重建一个企业门户网站,该门户网站将被全球各地的人们用来为产品提供延长保修期.他们提出了J2EE(spring MVC)和Oracle作为Business层的技术堆栈,并决定使用JSF(java服务器面)来设计前端的东西(用户界面)我是Frontend Engineer,想要由于它会减少对生成的标记的控制权,因此JSF会向页面注入/生成不必要的标记,这将对浏览器起到不健康的作用.此外,实现浏览器兼容性将变得困难,因为我对生成的标记没有任何控制很难应用正确的CSS行为.此外,它不可能使用流体布局,表格较少的布局等概念.所有这些都将导致糟糕的用户体验.我的想法是使用手工编码HTML开发UI,然后将这些.html文件转换为JSP,并将这些JSP插入Spring MVC架构中.
说完这一切之后,我需要提出一个建议来证明用HTML替换JSF的UI层,你的输入/想法和建议很有价值,请回信.
另外,我不相信XHTML作为其他选项,它必须是HTML？让我知道你的想法是什么,是什么让你这么想？
谢谢,停下来.如果阅读所有这些花费了你很多时间,我会道歉.
Bal*_*usC 23
当您使用具有"纯"JSF组件的复古JSF 1.0/1.1 API时,您所说的是正确的.没有内置组件可以用来表示HTML <div>元素(这样您就可以以语义方式完成常规页面布局).此外,在JSF页面中嵌入"普通"HTML是一件痛苦的事情,因为它在JSF组件树之外和之前呈现.您必须<f:verbatim>在所有位置的标记中放置纯HTML .纯粹主义者和不知不觉的人越来越少被迫使用<h:panelGrid>(呈现a <table>)来定位页面中的元素.
除此之外,在早期的JSF时代,Netbeans附带了一个内置的可视化JSF编辑器,它使您可以直观地拖放和绑定JSF组件,而无需编写任何代码行.这显然会产生许多乍一看不必要且不可维护的代码,并且元素的像素精确定位是用幕后实现的"幕后" <h:panelGrid>.这些JSF应用程序考虑到可维护性和Web语义是一个彻底的灾难.
关于前端开发,您将听到的关于JSF的大多数负面故事都与此有关.从那时起,大多数JSF用户/观察员/管理员目前仍然盲目地专注于此,因为他们拥有糟糕的经验和/或他们认为JSF现在仍然是相同的和/或他们将可视化编辑器视为JSF的一部分而它只是"另一个"(坏)工具.大多数说"JSF糟透了"的人通常是那些开始使用它与视觉/拖放编辑器的人,而没有任何关于幕后发生的事情的背景知识(尤其是Servlet API!).
自从JSF 1.2(已经超过4年前发布了btw)以来,该<h:panelGroup>组件得到了一个额外的属性:layout="block"它将(最终)呈现一个完整的HTML <div>元素,以便您可以仅使用JSF组件带来更多的语义布局.但不仅如此,JSF 1.2还附带了一个改进的视图处理程序,它可以将纯HTML嵌入到其他JSF组件中,而无需使用<f:verbatim>标记.你可以很好地将<div>元素放在你想要的地方,而不会增加更多的冗长.
尽管这是一个重大改进,但标准JSF实现仍然存在另外两个主要(但不直接与UI相关)问题:1)请求之间的状态管理很难,而不会占用会话范围(想想在表中保留相同的数据)和下拉列表以及例如rendered属性的条件); 2)一切都通过POST,你不能通过GET很好地调用JSFish动作.
从几乎已经有1年历史的JSF 2.0开始,这些问题就被新范围,视图范围和GET操作的一组新组件所覆盖.此外,JSP被Facelets取代为默认视图技术.Facelets极大地简化了模板化和创建复合组件,而无需使用原始Java代码和/或自定义组件/渲染器.即使它是基于XHTML的,它也可以完美地呈现HTML5有效的响应<!DOCTYPE html>.XHTML就在那里,因为Facelets使用基于XML的工具来生成(X)HTML输出.基于XHTML的模板绝不意味着它只能发出XHTML/XML.
总而言之,当您使用JSF 1.2或更新版本时,您的标记问题不是问题,并且XHTML(Facelets)也不应成为问题,因为它可以完美呈现HTML5有效标记.
JSF为您提供了许多预定义的丰富控件,这些控件提供了必须手动实现的功能.它的价格在某种程度上放弃了用户与应用程序交互的方式以及生成的HTML的控制权.它也可以阻碍与JS库的集成.
使用JSP,特别是使用Spring,调试和测试相当简单.
这实际上取决于您的网站的功能集,实施团队(和支持团队)的技能,提供约束的时间等.
我个人更喜欢更简单的技术,这些技术可以为开发人员提供更多的控制权(带有Spring MVC的JSP)只是为了框架的内部优雅,但这绝不是决定因素....
我为全球银行巴克莱银行担任UI工程师.现在,我会第一个说金融行业在用户界面方面还有很长的路要走,特别是巴克莱的技术落伍.话虽这么说,他们确实知道如何构建有效且可靠的工作方式,而且UI Lead是我曾经有机会与之合作的最令人惊叹的思想之一.此外,作为一家银行,他们是合规的坚持者.
我们正在使用您提出的替代方案,它对我们来说效果很好.网站每天可靠地处理数百万用户,没有负面结果.UI工作很简单,当联邦卡行为出现时,公司可以聘请基本网络人员进行切割/ html工作,工程师可以将其插入系统.
至于你的XHTML问题,最终我们选择严格遵循HTML 4.01,原因如下:首先,w3决定不推进XHTML工作组......实质上,它正在逐步走向缓慢的死亡.其次,4.01严格是最接近HTML5标准,并且一旦5支持变得更加普遍,可以相当容易地进行调整.对我们的一个硬性要求是对IE6的完全兼容性,这使我们能够实现这一目标.
在你的谈判中,我个人认为最终产品符合当前的网络标准(W3)至关重要,因为这使得最有可能实现与那里的浏览器兼容的网站(我说最有可能因为我确信微软找到了一种方法,以某种方式,打破我最终建立的所有内容...它们是如何滚动的.对于您的网站的辅助可能是对不合规代码的SEO问题,以及对屏幕阅读器支持等可访问性的障碍.您也可以尝试使用这两种技术输出两个相似(简单)的站点,并对性能进行分析.在我工作的一个网站的情况下,每天服务100万次,每天节省5k的文件大小5kb.
祝好运!这只是我使用Java和Oracle摆脱大型企业工作的众多原因之一....