从JSF和Ext看WebUI开发－－给对JavaScript 有恐惧感的朋友

话题由来：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，否则只能是半拉子开发人员。

 

楼主说的都挺有道理。但
最好不要再轻易做JSF和Ext的比较，二者擅长的领域和功能都不同，根本不具备比较性。所以很多结论性的东西也值得商榷

自吹自擂以下，我发现JavaEye上对服务端（包括数据库、ORM、MVC）和客户端的数据结构和在内存中的操作方式都非常清楚得还真是不多啊。

楼主这么比是有问题的，以下的比法还差不多：

JSF和Spring MVC + JSON(or other) + EXT
JSF和Struts 2 + EXT
等

你如果担心风险，完全可以小步迈进，从使用部分的EXT的功能开始了解它。

感觉楼上两位对 Browser base 的UI开发（下面简称B-UI,对应S-UI:jsp,jsf等Server base 的UI开发）所能达到的程度并不了解。

在正真的B-UI应用中，Browser自己负责界面构造和界面跳转，Server只负责提供business logic 访问，也就是说Server上根本就不需要S-UI的Web层（虽然还是HTTP访问），没有所谓的Controler，也就是说MVC不再是真理，Spring MVC/Struts之类的Web层框架完全没有必要。

“server pages”开发者理解B-UI时最大的思路陷阱就是“Web层”，MVC。

 B-UI（Ext等界面组件+HTML+JS+ajax）是S-UI(jsp,jsf,asp,asp.net)的完全等价物，不存在什么功能jsf能做， B-UI不能做的问题。

jsf需要结合Ext、ajax，只能说明jsf实现某些功能很费劲，只好借用B-UI的现成技术。

楼主可以把错别字改一下么
“本省”－>“本身”

难得有这么认真看帖的同学，谢谢，已经改了。

楼主要表达的是否是:
世界上只有B系统和S系统.(谁说的?引用一下)
搞B/S系统的都不是真正意义上的数据和表现分离.
真正意义上的数据和表现分离在后台应该只看到DB数据的操作(当然还有业务逻辑了)
看不到一行html或生成html的控制.
页面表现应该在前台有html/css/javascript来完成,这才是真正意义上的分离!
那问问楼主有谁的方案真正实现了这个呢?

你的理解完全正确，在首贴我已经指出“话题由来”，我100％支持fins的“世界上只有B系统和S系统”。

可以很不谦虚地告诉你，这种方案本人在6年前就已实现，而且经过N多项目的实践，欢迎各位实地考察：

http://www.xjawa.org/xjawa/kontent/80039.html

再不谦虚一点，本人的方案还做到了，实现同样的功能：

1、该框架所要的代码量远小于绝大部分（其实剩下的极少数我也没发现）java Web开发方式；
2、开发人员所需的培训和学习成本远小于各种主流框架。
3、开发人员的劳动生产率远高于各种主流框架。
4、所开发的应用系统的运行效率远高于各种主流框架。
5、所开发的应用系统的部署维护成本远低于各种主流框架。
。。。。

当然，上面的描述看起来像天方夜谈；但是，在我看来，很多年来，J2EE社区的各种时髦技术大多数也很荒唐。

 

培训学习时间有多长？
这么一套架构要多少钱？
生产率是多少？
一个系统开发多少小时？

PS：我也认为时髦技术没有专用技术好用。

1、普通的培训是3个小时，深入一点的需要6个小时；HTML/JS、Java需要较好的基础。

2、框架整体开源免费。

3、生产率我无法量化（因为我构思中的Web系统复杂性量化模型还没最终完成），只知道很快。

4、一个系统开发多少小时？无法量化，原因同3，

谢谢关注"专有技术":-) 虽然有点离题了，感觉在卖假药 (呸呸，俺怎么就学不会IBM传道士忽悠水平的1%?)