话题由来:http://www.iteye.com/post/523520?page=1
把其中我的观点整理出来:
100%支持fins!!! B端和S端彻底分开,分别有自己的框架,“UI层与系统其他层面的东西的唯一联系应该是"数据" ,UI层应该是在后台系统不变的情况下可切换的”,这种架构策略完全可行,而且实际代码上也比JSF/asp.net等“server page”变种优雅,本人已经在N个项目中实践过:
http://www.xjawa.org/xjawa/kontent/10020.html
使用这个7wxAop框架(浏览器端7wx + 服务器端Aop),有个朋友喜欢用Ext做前端,他就把7wx替换成Ext, 照样跑得很好:
http://www.deepsoft.com.cn/ext-aop/demo.html
那些不理解fins得同学,可能是没做过ajax开发,或者ajax用的比较少,或者思想已经被“server page ”方式禁锢。虽然本质上 jsf 还是“server page”,但确实比jsp、tag强很多;但是比起B/S完全分开得架构,jsf还是很丑陋。 我们公司有个项目组用得是SAP得WebDynpro,和jsf类似,要比jsf成熟,但实际开发起来也是很多问题。
个人认为,fins设想的这种架构之所以未被普遍关注,是因为它损害了J2ee大厂商的商业利益,因此他们控制的主流IT媒体不愿宣传。想想:如果Server只是用来接受数据->处理逻辑->返回数据,服务器端将非常Lightweight和Performance,大厂商的J2EE服务器还有高性能硬件还会有几个项目需要?
====================================
。。。正如我前面提到的,不理解fins的人大多是思想被“server pages”禁锢者,总认为浏览器只能负责 html render,其他一切都应该在服务器上完成,就如IT业早期的主机-字符终端模式。这种思想本质上是把浏览器看作21世纪的字符终端,完全忽略和闲置了目前运行浏览器pc的强大计算功能。
。。。在一个server和UI无关的模式下(下面称为“server business”,与“server pages”对应),server只是一个business logic server(只接受UI请求改变或查询系统的state),大致相当于砍掉了J2EE的Web层,Lightweight是肯定的了,至于Performance,除了节省处理 'UI layer'(NOT ONLY 'presentation layer') 的CPU开销,更重要的是大量节省服务器的出口带宽开销。
。。。“server business”模式(SB)与“server pages”模式(SP)本质上是不同的,SP下的'presentation layer'概念并不适合SB模式。
。。。将ajax单纯地视为transition technology本身也没什么错,虽然Ext等前端组件已经超越了这一概念。用Javascript framework称呼基于浏览器的“全功能UI Layer"并不适当,后者 = HTML + DHTML(DOM) + JS,JS只是一个粘合剂,Ext等前端组件本质上只是扩展了HTML Element,假设HTML 6.0包含了功能强大的TreeView、ListView(GRID)等通用UI组件,则JS将回归为单纯的DHTML API操纵语言。 至于RIA(javaFx or Flex),我认为它是侧重多媒体表现的“全功能UI Layer"的等价物,它的发展前景取决于厂商对它的定位,如果你认同RIA,就没有理由不认同“全功能UI Layer"的思路。
|
JSF:基于服务器端的UI模型,Ext:基于浏览器端的UI模型。
很多人质疑以JavaScript为中心的UI开发,其实是对html/JavaScript的恐惧。
1、 不要把《 HTML(含CSS) + DHTML(或DOM)API + JavaScript开发》 简单理解成 JavaScript 开发。很多人觉得“JavaScript”难以掌握,是因为他们混淆了JavaScript脚本语言本身和它所要操纵的API:其实JavaScript本 身 非常简单,但它所要操纵的API“非常复杂”,因为HTML(含CSS) + DHTML(或DOM)API所涉及的API对象、属性、方法、事件数量巨大,可以说和Win32 API,JDK API(不单是swing/awt)同一个数量级。
2、HTML(含CSS)作为UI的表达语言,其“潜在的”界面表达能力应该说远远超越任何已有高端UI组件库(asp.net,jsf,Ext...),因为它们本 身 都是基于HTML(含CSS)开发的,要想完整地(还不含绘图)、无障碍表达WebUI,掌握HTML(含CSS)及其API--DHTML(或DOM)是必由之路。
3、所有高端UI组件库的设计思想都是提高组件粒度,以掩盖HTML(含css)的复杂性。不同在于,服务器端UI组件(asp.net,jsf)试图“彻底”掩盖,它们排斥直接使用HTML(含css),并且操纵UI组件的API面向后端语言(C#,VB,java);而浏览器端UI组件(Ext等)是“开放性的”封装,允许直接操作HTML(含css),操纵UI组件的API面向javascript。
4、服务器端UI组件的使用者,一般不太关心组件的具体实现,而且使用中也缺乏HTML+JS的训练,当组件功能满足不了要求时,自己扩展组件的难度很大,也就时说使用组件和开发组件之间存在巨大鸿沟。而浏览器端UI组件的使用者,一般会大致了解组件的实现,使用中频繁接触HTML,JS操纵能力也得到训练,因此他们会比较自然地形成组件改造扩展能力,使用组件和扩展组件之间得学习曲线是平滑的。
5、因此,从开发人员自身职业发展的角度看,要想成为无障碍的Web开发者,使用浏览器端UI组件模式应该是更好的选择。
作为Web开发者,必须热情拥抱HTML(css)和javascript,否则只能是半拉子开发人员。
分享到:
相关推荐
javaee.jar,jsf-api.jar,jsf-impl.jar,jstl-1.2.jar
jsf-api.jar和jsf-impl
ajax4jsf-1.0.6.jarajax4jsf-1.0.6.jarajax4jsf-1.0.6.jar
jsf-impl.jar jsf-api.jar jsf-impl.jar jsf-api.jar
JavaEE源代码 jsf-apiJavaEE源代码 jsf-apiJavaEE源代码 jsf-apiJavaEE源代码 jsf-apiJavaEE源代码 jsf-apiJavaEE源代码 jsf-apiJavaEE源代码 jsf-apiJavaEE源代码 jsf-apiJavaEE源代码 jsf-apiJavaEE源代码 jsf-...
什么是JSF JSF的特性 JSF与其它框架的比较 JSF实现 JSF示例
JSF为JAVA的 Web应用用户界面的开发人员提供了标准的编程接口、丰富可扩展的UI组件库(一个核心的JSP标记库用来处理事件、执行验证以及其他非UI相关的操作和一个标准的HTML 标记库来表示 UI组件)、事件驱动模型等...
JavaEE源代码 jsf-implJavaEE源代码 jsf-implJavaEE源代码 jsf-implJavaEE源代码 jsf-implJavaEE源代码 jsf-implJavaEE源代码 jsf-implJavaEE源代码 jsf-implJavaEE源代码 jsf-implJavaEE源代码 jsf-implJavaEE源...
jdom.jar、jsf-api.jar、jsf-impl.jar、jstl-1.2.jar、saxpath.jar、xalan.jar、xerces.jar、xml-apis.jar包
引用别人的Demo,自己运行。做个备份。 http://www.mkyong.com/jsf2/jsf-2-0-hello-world-example/
JSF-api-1.2_14-sources.jar,提供了jsf使用时的多种内部类。
jsf相关jar包, 包含jsf-api.jar jsf-impl.jar jstl-1.2.jar javaee.jar
Beginning JSP, JSF and Tomcat_ Java Web Development - Giulio Zambon.pdf
航空系统C++软件开发规范,此规范的目的是确保编出的代码满足安全、可靠、可测试和已维护的特点。
jsf-api,jsf-impl,jst1-1.2,javaee是基于java的web开发,java ee5.0的jar 包汇总
JSF-API.CHM,JSF-API.CHMJSF-API.CHM,JSF-API.CHM
tomcat里的jar 包,在项目启动时缺少包
JSF-2-Hello-World-Example.zip
NULL 博文链接:https://miaoxianjie.iteye.com/blog/1571298
JSF开发所必需包:花了很长时间才收集好,很费时,现已收集好,何不分享给大家,让大家节省时间做点有意义的事情呢?呵呵。。。已在附件供大家下载,若是你所需要的东西,那就请投个票、说句鼓励的话,我就满足了。 ...