从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，否则只能是半拉子开发人员。

 

评论

174 楼 fye 2008-11-14  

<div class='quote_title'>leebai 写道</div>
<div class='quote_div'>
<div class='quote_title'>achun 写道</div>
<div class='quote_div'>楼主要表达的是否是: <br/>世界上只有B系统和S系统.(谁说的?引用一下) <br/>搞B/S系统的都不是真正意义上的数据和表现分离. <br/>真正意义上的数据和表现分离在后台应该只看到DB数据的操作(当然还有业务逻辑了) <br/>看不到一行html或生成html的控制. <br/>页面表现应该在前台有html/css/javascript来完成,这才是真正意义上的分离! <br/>那问问楼主有谁的方案真正实现了这个呢?</div>
<p><br/><br/>你的理解<span style='color: #ff0000;'>完全正确</span>，在首贴我已经指出“话题由来”，我<span style='color: #ff0000;'>100％</span>支持<span style='color: #ff0000;'>fins</span>的“<span style='color: #ff0000;'>世界上只有B系统和S系统</span>”。 <br/><br/>可以<span style='font-size: small; color: #ff0000;'>很不谦虚地</span>告诉你，这种方案本人在6年前就已实现，而且经过N多项目的实践，欢迎各位实地考察： <br/><br/><a href='http://www.xjawa.org/xjawa/kontent/80039.html' target='_blank'>http://www.xjawa.org/xjawa/kontent/80039.html</a> </p>
<p><br/><br/><span style='font-size: small; color: #ff0000;'>再不谦虚一点</span>，本人的方案还做到了，实现同样的功能： <br/><br/>1、该框架所要的代码量远小于绝大部分（其实剩下的极少数我也没发现）java Web开发方式； <br/>2、开发人员所需的培训和学习成本远小于各种主流框架。 <br/>3、开发人员的劳动生产率远高于各种主流框架。 <br/>4、所开发的应用系统的运行效率远高于各种主流框架。 <br/>5、所开发的应用系统的部署维护成本远低于各种主流框架。 <br/>。。。。</p>
<p>当然，上面的描述看起来像天方夜谈；但是，在我看来，<span style='color: #ff0000;'>很多年来，J2EE社区的各种时髦技术大多数也很荒唐</span>。</p>
<p> </p>
</div>
<p> </p>
<p>我们公司也做了一套楼主这样思想的web开发框架。 后台只负责数据存储和业务逻辑，不负责渲染任何页面。</p>
<p>前台就是  javascript + html + css。 当然，前台更近了一步，在 jquery的基础上开发了适合我们公司专用的一些ui控件，然后在这些控件的基础上开发我们公司的项目，非常的高效，简单，上手很快。</p>
<p> </p>

173 楼 key232323 2008-09-20  

lz十分之强悍，我希望站在巨人的肩膀上
呵呵

172 楼 tonik 2008-06-25  

这有什么争论的~
所谓，b/s就是一个B 一个S
所谓C/S就是一个C 一个S
都是分开的~

从理想效果来看，当然降低耦合最好，包括开发人员职能/各种脚本语言/结构清晰等等
但是，到底哪种好，是由项目说了算~

说JSF/ASPX不好，可是他带来的快捷是不可否认的，况且，你所认为的复杂/乱，都是在他的管理之下，所以，这些你不用操心。
况且，JSF+自己定义的UI框架，也不是不可以结合，取各自的优点不好么？
如果他不能满足你的需要，那当然就用别的方法来实现。

大家在说明自己的追求的时候，都忽略了一点，我们的追求是建立在每一个项目基础上的
哪种更合适用哪种~

不过，各位给出的连接，确实很有意思~
学习ing

171 楼 leebai 2008-06-20  

rushio 写道

正在认真阅读http://www.xjawa.org/xjawa/kontent/80039.html
感觉很受启发
结论拟先研究-->再试用后，再发表：）

By Rushio Wang.

谢谢关注。

本人对技术的兴趣很没常性，经常很长时间不写不看任何代码，也不看技术文章，不上技术论坛，希望关注该框架的朋友要有耐心，不要期望从我这里得到多好的支持，最好自己通读框架代码，理解后想做什么就做什么。

170 楼 rushio 2008-06-19  

正在认真阅读http://www.xjawa.org/xjawa/kontent/80039.html
感觉很受启发
结论拟先研究-->再试用后，再发表：）

By Rushio Wang.

169 楼 icewubin 2008-06-18  

alger 写道

解除了B/S开发已经两年了
一直用的是java


在这两年里面,从最基础的mode1  到 jsp+servlet+javabean(mode2) 再到  struts,spring,hibernate

我最深的感受就是越到最后 月要把以前学习的东西抛弃掉,

比方说 之前经常要写一些html css javascript  到最后 好像jsf 和struts 就不这么写javascript乐


经常会有人提到 ssh开发  我一直没有感觉到这个所谓的主流框架有多么的好!

对于当前主流框架来说,我更喜欢mod2更喜欢用jsp+javabean+servelt开发,
表现层我宁愿用html+css+javascript!

呵呵 这个是我一个新手的心声!

问题是你在公司里不是单干的，你要和别人合作，你要服从架构师的规范，要和团队保持风格一致。

168 楼 jyfln1234 2008-06-18  

<div class='quote_title'>leebai 写道</div>
<div class='quote_div'>
<div class='quote_title'><span style='color: #ff0000;'>很多年来，J2EE社区的各种时髦技术大多数也很荒唐</span>。</div>
<p> </p>
</div>
<p><br/>恩，是啊，很多用过之后感觉都不如自己写个类来的方便，特殊需求决定了特殊的解决方案！</p>
<p> </p>

167 楼 alger 2008-06-18  

解除了B/S开发已经两年了
一直用的是java


在这两年里面,从最基础的mode1  到 jsp+servlet+javabean(mode2) 再到  struts,spring,hibernate

我最深的感受就是越到最后 月要把以前学习的东西抛弃掉,

比方说 之前经常要写一些html css javascript  到最后 好像jsf 和struts 就不这么写javascript乐


经常会有人提到 ssh开发  我一直没有感觉到这个所谓的主流框架有多么的好!

对于当前主流框架来说,我更喜欢mod2更喜欢用jsp+javabean+servelt开发,
表现层我宁愿用html+css+javascript!

呵呵 这个是我一个新手的心声!

166 楼 supernaturalmagician 2008-06-18  

引用

我多年的编程习惯是，自己能做的事，尽可能自己做：除了工作量太大的web服务器、数据库服务器、全文检索引擎，以及一些绝对可靠的工具，系统中涉及的绝大多数东西都自己实现，比如web框架、持久化模型、前端UI组件、ajax通讯组件、文件上传组件、HTMLEditor、log策略。。。这些东西其实都不是很难，第一次用比直接使用现成的东西会多花点时间，但时间长了自己做的东西在使用效率、可整合性、可调试性、可扩展性等方面都会有明显优势。

感觉观点有点偏激，并不是什么都是自己实现的才是最好，有些开源控件已经可以满足需求，而且扩展性也不错，大部分项目的开发时间都是很紧的，很少有人在项目开发过程中发明重复的轮子，当然自己可以做封装以便以后的项目使用，但是任何学习都是有成本的，你封装的框架要想让别人学习，跟学习struts2,jsf 一样需要时间，而且越通用的框架，必然内部越复杂，这是为什么国内很多项目的开发一直使用struts 1.x的原因。

165 楼 icewubin 2008-06-16  

soci 写道

GWT 怎么样 是不是把正方反方都能接受？

GWT还是属于服务端生成的，怎么能让双方都接受？

如果都能接受，干嘛还出个GWT-EXT。
也就是说，你绑在一棵树上了。如果不出GWT-EXT，难道你自己封装么？
很多优秀客户段框架的选择权就放弃或者部分放弃了。

对于个人还好，对于一个团队，对一个技术的直接或间接投入的人力成本是很大的。
从一个技术管理人员的角度来看某个技术的话，一般都是从各种风险和成本入手，找平衡点。

164 楼 pensun37 2008-06-10  

晕，战火烧到了这里，贴子前十页有点含量，后面是楼主群战各马甲 ：）

163 楼 soci 2008-05-27  

<div class='quote_title'>leebai 写道</div>
<div class='quote_div'>
<div class='quote_title'>soci 写道</div>
<div class='quote_div'>不理解啊 ，ORM大家都接受，怎么服务端UI很多人就不接受。 <br/>JS+DHTML+CSS 和 pl/sql + trigger 多像。</div>
<p><br/><br/><br/>哈，有反例啊，ORM我就不接受，哪天单发个帖子抨击ORM，先转贴一个我在xjawa网上的简单评论：。</p>
<div class='quote_title'>引用</div>
<div class='quote_div'><span style='font-size: small;'>7wxAop看到，<strong>面向对象编程与RDBMS之间存在严重的不匹配</strong>。7wxAop认为，要么业务实体本身没有状态需要持久化，就像各种界面组件、Web浏览器程序；要么业务实体不依赖于RDBMS能解决自身状态的持久存储问题，就像Photoshop、Office等桌面应用，否则不要想方设法把业务实体设计成实体对象，再想方设法保证实体对象与RDBMS的一致性。7wxAop认为这种被称为OR Maping的努力是混杂的、低效的、徒劳的，再怎么发展也是没有前途的。7wxAop发现，与丑陋的<strong>EJBQL/HQL</strong>相比，被世人遗忘的<strong><span style='color: #000000;'>SQLJ</span></strong>其实更有借鉴潜质，于是<strong>7wxAop将Http的Request、Response引入SQL其改造成<span style='color: #dc143c;'>SQLHTTP</span>（框架中称为<span style='color: #dc143c;'>AutoSQL</span>），简洁高效地在浏览器UI和DB之间建立了直通桥梁</strong>。</span></div>
<p> </p>
</div>
<p>明白了，怪不得前面吵的这么厉害，原来大家路线不同啊</p>

162 楼 kimmking 2008-05-27  

只有两种语言，一种天天被人骂，另一种没有人用。

161 楼 csf177 2008-05-27  

<div class='quote_title'>leebai 写道</div>
<div class='quote_div'>
<p>不要太相信大厂商，我们做过6年IBM的ISV，知道大厂商的东西未必都事好东西；而且从软件产业发展的历史看，失败的技术远多于成功的技术。</p>
</div>
<p>这东西不是说盲目相信不相信的问题 判断当然要靠自己。我想你也看到了，这地方的有些程序员是非常幼稚的，动不动就猜测XXX商业利益驱动的结果，什么技术派系斗争啦，某某高管生孩子啦（这个是我编的）。好像大厂商的东西就是过家家弄出来的玩物一样。大厂商出的东西你可以评论，也可以不用，但是不用的理由不能太可笑，有些原则性错误（比如说试图永久性消灭HTML和JS，事实上HMTL+CSS+JS这种模式很受MS和SUN的认可，连桌面软件都在借鉴这种结构）根本就不可能有人犯。</p>
<p>我看到的是，很多优秀的技术在无知的人手中被浪费，又因为这些失败而被盲目地批判。大多数技术都处于两个极端，要么被疯狂的追捧（就像现在的Ext），要么被疯狂的批判。到最后技术本身究竟是怎么回事都没多少人知道了，剩下的全是观点。初学者则往往被这些观点左右,形成更加盲目的群体。</p>

160 楼 leebai 2008-05-27  

<div class='quote_title'>soci 写道</div>
<div class='quote_div'>不理解啊 ，ORM大家都接受，怎么服务端UI很多人就不接受。 <br/>JS+DHTML+CSS 和 pl/sql + trigger 多像。</div>
<p><br/><br/><br/>哈，有反例啊，ORM我就不接受，哪天单发个帖子抨击ORM，先转贴一个我在xjawa网上的简单评论：。</p>
<div class='quote_title'>引用</div>
<div class='quote_div'><span style='font-size: small;'>7wxAop看到，<strong>面向对象编程与RDBMS之间存在严重的不匹配</strong>。7wxAop认为，要么业务实体本身没有状态需要持久化，就像各种界面组件、Web浏览器程序；要么业务实体不依赖于RDBMS能解决自身状态的持久存储问题，就像Photoshop、Office等桌面应用，否则不要想方设法把业务实体设计成实体对象，再想方设法保证实体对象与RDBMS的一致性。7wxAop认为这种被称为OR Maping的努力是混杂的、低效的、徒劳的，再怎么发展也是没有前途的。7wxAop发现，与丑陋的<strong>EJBQL/HQL</strong>相比，被世人遗忘的<strong><span style='color: #000000;'>SQLJ</span></strong>其实更有借鉴潜质，于是<strong>7wxAop将Http的Request、Response引入SQL其改造成<span style='color: #dc143c;'>SQLHTTP</span>（框架中称为<span style='color: #dc143c;'>AutoSQL</span>），简洁高效地在浏览器UI和DB之间建立了直通桥梁</strong>。</span></div>
<p> </p>

159 楼 leebai 2008-05-27  

<div class='quote_title'>csf177 写道</div>
<div class='quote_div'>国内程序员的问题在没有自知之明 <br/>不看文档 也不认真了解（能同时找到.NET的文档 JSF的文档 ECMA262 XHTML的XSD和文档的同学举下手 全看过的也举下手） <br/><br/>其实麻烦就在某些人根本不知道什么叫组件模型 在一些显然没边的问题上胡扯 所以根本没法说。我也不是开培训班的 没兴趣普及软件基本理论。没学过计算机或者上学期间没好好学的同学就不要在这里不懂装懂了。 <br/><br/>组件模型碍着标签封闭什么事了，某人公司的.net程序员垃圾，跟组件模型有何关系？所以我说MS和SUN这种做技术的公司，做出来的好多东西都被浪费了，不喜欢SUN但我也替SUN悲哀。无知很悲哀，但是被无知者当作无知更悲哀。 <br/><br/>成天在社区对不了解的技术说三道四，什么商业利益、管理层分歧、技术派系，其实跟三姑六婆说家常里短没什么区别，是最没出息的程序员做的事。</div>
<p> </p>
<p>不要太相信大厂商，我们做过6年IBM的ISV，知道大厂商的东西未必都事好东西；而且从软件产业发展的历史看，失败的技术远多于成功的技术。</p>

158 楼 csf177 2008-05-27  

<div class='quote_title'>leebai 写道</div>
<div class='quote_div'>
<div class='quote_title'>谢谢zbm2001兄认可。</div>
<p> </p>
<p>很认同你说的：不要乱用框架。拼凑使用各种框架、工具确实是项目失控的重要原因之一：不能100％地把握框架和工具，有时就会被框架所困。</p>
<p> </p>
<p>我多年的编程习惯是，自己能做的事，尽可能自己做：除了工作量太大的web服务器、数据库服务器、全文检索引擎，以及一些绝对可靠的工具，系统中涉及的绝大多数东西都自己实现，比如web框架、持久化模型、前端UI组件、ajax通讯组件、文件上传组件、HTMLEditor、log策略。。。这些东西其实都不是很难，第一次用比直接使用现成的东西会多花点时间，但时间长了自己做的东西在使用效率、可整合性、可调试性、可扩展性等方面都会有明显优势。</p>
<p> </p>
</div>
<p><br/>web框架和前端UI组件绝对是应该自己写的 其实主要原因是现在的框架太烂 但自己写的就算不如它们 也好控制得多 不论是优化、排错还是裁减</p>

157 楼 csf177 2008-05-27  

soci 写道

GWT 怎么样 是不是把正方反方都能接受？

我自己没什么特别的观点 反正我自己什么都不用 只是有些明显的错误挑一挑而已

如果谈组件模型 决不是这种谈法

JE这个地方 初看到处都在讨论分析、架构和设计，其实进去帖子才知道 大多数都是些不知是什么的东西。

156 楼 leebai 2008-05-27  

<div class='quote_title'>zbm2001 写道</div>
<div class='quote_div'>我是受够了！！！ <br/>××的（留点口德）服务端组件模型，生成的代码那叫一个垃圾！ <br/><br/>http://www.gs1cn.org/template/demoGDS.html <br/>还少了一个&lt;/div&gt;闭合标签，我们那个5年的.net程序员，2年多到现在愣是改不过来；项目里类似这种控件生成的垃圾代码到处都是，还跟新人侃这个框架、那个组件……多有经验啊——真让人替这些新人担忧；js组建更是到处抓，导致项目埋下n多地雷，我做了许多测试都心惊肉跳……；跟他说到这些还脸红鼻塞的……最是替那些个项目担忧了！ <br/>——不学也罢，脏了眼睛，时间也宝贵着呢。 <br/><br/>http://www.gs1cn.org/template/demo.html <br/>看看什么叫CSS+html过硬！什么叫语义网！那些打包好的××的（留点口德）服务端组件模型会明白吗？等着自己开发吧！ <br/>——js上也逼着自己开发zCool库，优雅而健壮的实现再辛苦都快乐（过段时间有机会贴上来献丑）——I love in it！！ <br/><br/>我只是个做前端设计的，快30岁才入行，写js程序算是个八脚毛， <br/><br/>绝对希望和楼主这样的程序员搭档！</div>
<p>谢谢zbm2001兄认可。</p>
<p> </p>
<p>很认同你说的：不要乱用框架。拼凑使用各种框架、工具确实是项目失控的重要原因之一：不能100％地把握框架和工具，有时就会被框架所困。</p>
<p> </p>
<p>我多年的编程习惯是，自己能做的事，尽可能自己做：除了工作量太大的web服务器、数据库服务器、全文检索引擎，以及一些绝对可靠的工具，系统中涉及的绝大多数东西都自己实现，比如web框架、持久化模型、前端UI组件、ajax通讯组件、文件上传组件、HTMLEditor、log策略。。。这些东西其实都不是很难，第一次用比直接使用现成的东西会多花点时间，但时间长了自己做的东西在使用效率、可整合性、可调试性、可扩展性等方面都会有明显优势。</p>
<p> </p>

155 楼 soci 2008-05-27  

GWT 怎么样 是不是把正方反方都能接受？