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

 

评论

154 楼 csf177 2008-05-27  

zbm2001 写道

机器码没有语义？

没有语义连机器都不会读！

以哲学观点 任何信息中都含有语义
这个地方我确实说的不恰当

不过我没兴趣跟你讨论哲学问题 我这里的语义显然指易于被人理解的语义
准确地再说一遍：
你为什么不挑CL生成的汇编代码语义的可理解程度差呢？

153 楼 csf177 2008-05-27  

zbm2001 写道

说的好啊！“aspx页面才是源码 语义只存在于源码中”

——我想这是一个绝佳的（原谅我用这个词）分歧点，到底是我们命令程序往我们编写的文档里插入或操作数据呢？还是让程序挟着我们的文档操作呢？

不知所云了

152 楼 zbm2001 2008-05-27  

机器码没有语义？

没有语义连机器都不会读！

151 楼 zbm2001 2008-05-27  

csf177 写道

asp命名空间中的标签其实更好的维护了语义

顺便说一下 其实你那个页面不是HTML5的什么i标签的问题 而是你把li写错成了i 我也没仔细看 主要是没想到会有这种问题 实际上你的页面还是符合XHTML的
本来嘛 我还奇怪呢 那么简单的页面还能通不过XHTML

感谢细心指正！

csf177 写道

zbm2001 写道

.net3.0之前不但不能，还会在VS编辑器里破坏原来的源码结构，诸如肆意去掉文档申明、修改标签大小写，还好××浏览器好说话，想想如果这些是动态的程序代码会怎么样呢？
.net3.0迫于压力，做了改进，是基本能通过校验——

文档重在规范，但语义却是其灵魂，没有语义满页的标签汤，那个验证页面不是为这种验证而设立的。

无知啊 说了你还不相信

你对语义缺乏基本的了解 大学不是计算机专业的吧
对你们这种纯粹靠项目实践出来的人真没办法 所有东西都一知半解 然后还说得理直气壮

aspx页面才是源码 语义只存在于源码中 生成的页面是标签汤关你什么事 你怎么不去挑CL生成的机器码没有语义？

说的好啊！“aspx页面才是源码 语义只存在于源码中”

——我想这是一个绝佳的（原谅我用这个词）分歧点，到底是我们命令程序往我们编写的文档里插入或操作数据呢？还是让程序挟着我们的文档操作呢？

150 楼 csf177 2008-05-27  

asp命名空间中的标签其实更好的维护了语义

顺便说一下 其实你那个页面不是HTML5的什么i标签的问题 而是你把li写错成了i 我也没仔细看 主要是没想到会有这种问题 实际上你的页面还是符合XHTML的
本来嘛 我还奇怪呢 那么简单的页面还能通不过XHTML

149 楼 zbm2001 2008-05-27  

回到正题：

类似这种高度依赖性的模式，只会让××越来越多，这就是他们之间的关系。

所以基本支持楼主的观点！

148 楼 csf177 2008-05-27  

zbm2001 写道

.net3.0之前不但不能，还会在VS编辑器里破坏原来的源码结构，诸如肆意去掉文档申明、修改标签大小写，还好××浏览器好说话，想想如果这些是动态的程序代码会怎么样呢？
.net3.0迫于压力，做了改进，是基本能通过校验——

文档重在规范，但语义却是其灵魂，没有语义满页的标签汤，那个验证页面不是为这种验证而设立的。

无知啊 说了你还不相信

你对语义缺乏基本的了解 大学不是计算机专业的吧
对你们这种纯粹靠项目实践出来的人真没办法 所有东西都一知半解 然后还说得理直气壮

aspx页面才是源码 语义只存在于源码中 生成的页面是标签汤关你什么事 你怎么不去挑CL生成的机器码没有语义？

147 楼 zbm2001 2008-05-27  

.net3.0之前不但不能，还会在VS编辑器里破坏原来的源码结构，诸如肆意去掉文档申明、修改标签大小写，还好××浏览器好说话，想想如果这些是动态的程序代码会怎么样呢？
.net3.0迫于压力，做了改进，是基本能通过校验——

文档重在规范，但语义却是其灵魂，没有语义满页的标签汤，那个验证页面不是为这种验证而设立的。

146 楼 csf177 2008-05-27  

zbm2001 写道

ok，能对上口我很感激！我先不解释

看看这个：
http://www.w3.org/html/wg/html5/#the-i

这个：
http://www.w3.org/html/wg/html5/#the-b

还有这个：
http://www.blueidea.com/tech/web/2008/5497.asp

HTML5的规范为了使标准具有过渡性，对<i/><b/>等用来表现性标签重新规范了语义。

另外，我不想争论另外一些东西（诸如这个不是HTML5格式的文档或者是其还没正式发布之类的），至少你给的这个网站他的每一条规范和实现几乎永远是公开和透明的。——我想这也正是印证了我想要表达的一部分东西

HTML5跟XHTML校验时两码事吧？写通不过XHTML校验代码的人居然说通过校验的代码垃圾 语义不清之类的 而且你那CSS水平还是收着点吧

还有您老人家不会是拿W3C跟公司比吧 W3C是标准化组织难道出了规范藏起来申请专利？

145 楼 zbm2001 2008-05-27  

ok，能对上口我很感激！我先不解释

看看这个：
http://www.w3.org/html/wg/html5/#the-i

这个：
http://www.w3.org/html/wg/html5/#the-b

还有这个：
http://www.blueidea.com/tech/web/2008/5497.asp

HTML5的规范为了使标准具有过渡性，对<i/><b/>等用来表现性标签重新规范了语义。

另外，我不想争论另外一些东西（诸如这个不是HTML5格式的文档或者是其还没正式发布之类的），至少你给的这个网站他的每一条规范和实现几乎永远是公开和透明的。——我想这也正是印证了我想要表达的一部分东西

144 楼 csf177 2008-05-27  

不是很了解JSF
但我知道纯粹.NET服务端控件生成的代码可以保证通过XHTML校验的
我不知道为什么你那过硬的CSS和HTML 优美的语义网 精简、有语义、环保的代码通不过XHTML校验

“组件模型”有什么高深的东西？就是一个抽象化的说法，一个分配关系而已。
所以说跟你的代码有关系吗？你硬扯到代码环保上 当然我会认为你无知了。

143 楼 csf177 2008-05-27  

zbm2001 写道

就等着你这句呢！

那么好，为什么这些.net/jsf *&%$^%#&^#^# 林林种种不是出来的时候都自带了n个组件吗？

看看这些组件生成的代码多垃圾！想想人类把环境糟蹋的差不多了再来环保，网络世界也再来一遍？（这方面国内的前端界已经努力很久了，尽管他们所处环境那么艰难）

为什么不能像前端利用xhtml/css/js那样公开的标准的由自己驾驭，生产出精简、有语义的代码？文档（包括源码）阅读、视觉呈现、操作交互、数据交互、数据逻辑……

如果这样，我看还可以让××程序员立马少一半！想想这些××产生的根源在哪？

妄想把人捆绑在上面（有些技术点还时不时藏着掖着，虽然迫于压力有所好转）不是商业利益是什么？我看还得加两个字——无耻！

“组件模型”有什么高深的东西？——就是一个抽象化的说法，一个分配关系而已

http://validator.w3.org/check?uri=http%3A%2F%2Fwww.gs1cn.org%2Ftemplate%2Fdemo.html&charset=%28detect+automatically%29&doctype=Inline&group=0人是因为无知才有勇气 还是因为过于有勇气而无知？

142 楼 soci 2008-05-27  

不理解啊 ，ORM大家都接受，怎么服务端UI很多人就不接受。
JS+DHTML+CSS 和 pl/sql + trigger 多像。

141 楼 zbm2001 2008-05-27  

就等着你这句呢！

那么好，为什么这些.net/jsf *&%$^%#&^#^# 林林种种不是出来的时候都自带了n个组件吗？

看看这些组件生成的代码多垃圾！想想人类把环境糟蹋的差不多了再来环保，网络世界也再来一遍？（这方面国内的前端界已经努力很久了，尽管他们所处环境那么艰难）

为什么不能像前端利用xhtml/css/js那样公开的标准的由自己驾驭，生产出精简、有语义的代码？文档（包括源码）阅读、视觉呈现、操作交互、数据交互、数据逻辑……

如果这样，我看还可以让××程序员立马少一半！想想这些××产生的根源在哪？

妄想把人捆绑在上面（有些技术点还时不时藏着掖着，虽然迫于压力有所好转）不是商业利益是什么？我看还得加两个字——无耻！

“组件模型”有什么高深的东西？——就是一个抽象化的说法，一个分配关系而已

140 楼 csf177 2008-05-27  

国内程序员的问题在没有自知之明
不看文档 也不认真了解（能同时找到.NET的文档 JSF的文档 ECMA262 XHTML的XSD和文档的同学举下手 全看过的也举下手）

其实麻烦就在某些人根本不知道什么叫组件模型 在一些显然没边的问题上胡扯 所以根本没法说。我也不是开培训班的 没兴趣普及软件基本理论。没学过计算机或者上学期间没好好学的同学就不要在这里不懂装懂了。

组件模型碍着标签封闭什么事了，某人公司的.net程序员垃圾，跟组件模型有何关系？所以我说MS和SUN这种做技术的公司，做出来的好多东西都被浪费了，不喜欢SUN但我也替SUN悲哀。无知很悲哀，但是被无知者当作无知更悲哀。

成天在社区对不了解的技术说三道四，什么商业利益、管理层分歧、技术派系，其实跟三姑六婆说家常里短没什么区别，是最没出息的程序员做的事。

139 楼 zbm2001 2008-05-27  

还不够悲哀吗？？？
如果是普遍的现象，那以我愚笨的脑袋从这里实在看不出有国内的程序界有什么希望！！！

引用

我认为，不管是哪种粗粒度界面组件实现，最好都由浏览器厂家联合来做，做出标准、通用、有持久生命力的界面组件。微软推出.net的时候，粗看简介我还以为是理想中的界面层技术，细看代码原来还是“服务器动态页面”，后来SUN的JSF也这么学，我们公司一个项目组现在在用的SAP的webDypro也是，因此我都有点怀疑:业界大佬们之所以不愿意在客户端组件上下功夫，之所以不想变革目前的Web应用架构，不是因为他们没看到技术需求，而是因为，他们的根本利益在于利润丰厚的各种服务器端产品；Web开发之所以搞得这么复杂，里面说不定有什么惊天大阴谋；或者说，这些业界大佬们睁一只眼闭一只眼地看着广大Web开发者累得死去活来，看着Web独立开发商和集成商一个个倒下去，却背过身去窃笑着点着大把的钞票----扯远了:)，这问题有空发个专贴，反正做了6年IBM独立开发商就给我这种感觉。

——一语中的！
“××的（留点口德）服务端组件模型”不老老实实处理数据逻辑还要干什么？！
若不是客户端不容易控制安全问题，我看连这块都得待一边去！

引用

4、服务器端UI组件的使用者，一般不太关心组件的具体实现，而且使用中也缺乏HTML+JS的训练，当组件功能满足不了要求时，自己扩展组件的难度很大，也就时说使用组件和开发组件之间存在巨大鸿沟。而浏览器端UI组件的使用者，一般会大致了解组件的实现，使用中频繁接触HTML，JS操纵能力也得到训练，因此他们会比较自然地形成组件改造扩展能力，使用组件和扩展组件之间得学习曲线是平滑的。

没有前端代码的控制能力，缺少改造和扩展组件的本领，那就让“××的（留点口德）服务端组件模型”生成的垃圾代码给淹死吧！反正都泡惯了这些毫无语义的垃圾代码臭水池。

138 楼 kimmking 2008-05-27  

zbm2001 写道

我是受够了！！！
××的（留点口德）服务端组件模型，生成的代码那叫一个垃圾！

http://www.gs1cn.org/template/demoGDS.html
还少了一个</div>闭合标签，我们那个5年的.net程序员，2年多到现在愣是改不过来；项目里类似这种控件生成的垃圾代码到处都是，还跟新人侃这个框架、那个组件……多有经验啊——真让人替这些新人担忧；js组建更是到处抓，导致项目埋下n多地雷，我做了许多测试都心惊肉跳……；跟他说到这些还脸红鼻塞的……最是替那些个项目担忧了！
——不学也罢，脏了眼睛，时间也宝贵着呢。

http://www.gs1cn.org/template/demo.html
看看什么叫CSS+html过硬！什么叫语义网！那些打包好的××的（留点口德）服务端组件模型会明白吗？等着自己开发吧！
——js上也逼着自己开发zCool库，优雅而健壮的实现再辛苦都快乐（过段时间有机会贴上来献丑）——I love in it！！

我只是个做前端设计的，快30岁才入行，写js程序算是个八脚毛，

绝对希望和楼主这样的程序员搭档！

我们自己写可以啊 我更愿意自己写 但是我不做项目啊 我做技术 我可以弄几个组件让人勉强用 不用什么学习成本 我不能让他跟我一样一点一点写js 就算是他自己愿意 领导们也不愿意 领导们只愿意不花钱 不花时间 不花人力 功能就出来了。 无奈啊。

137 楼 zbm2001 2008-05-27  

我是受够了！！！
××的（留点口德）服务端组件模型，生成的代码那叫一个垃圾！

http://www.gs1cn.org/template/demoGDS.html
还少了一个</div>闭合标签，我们那个5年的.net程序员，2年多到现在愣是改不过来；项目里类似这种控件生成的垃圾代码到处都是，还跟新人侃这个框架、那个组件……多有经验啊——真让人替这些新人担忧；js组建更是到处抓，导致项目埋下n多地雷，我做了许多测试都心惊肉跳……；跟他说到这些还脸红鼻塞的……最是替那些个项目担忧了！
——不学也罢，脏了眼睛，时间也宝贵着呢。

http://www.gs1cn.org/template/demo.html
看看什么叫CSS+html过硬！什么叫语义网！那些打包好的××的（留点口德）服务端组件模型会明白吗？等着自己开发吧！
——js上也逼着自己开发zCool库，优雅而健壮的实现再辛苦都快乐（过段时间有机会贴上来献丑）——I love in it！！

我只是个做前端设计的，快30岁才入行，写js程序算是个八脚毛，

绝对希望和楼主这样的程序员搭档！

136 楼 csf177 2008-05-26  

<div class='quote_title'>leebai 写道</div>
<div class='quote_div'>
<div class='quote_title'>csf177 写道</div>
<div class='quote_div'>
<div class='quote_title'>leebai 写道</div>
<div class='quote_div'>
<div class='quote_title'>kimmking 写道</div>
<div class='quote_div'><br/><br/>还好，我的js还是比较好调试的。 <br/><br/>呵呵。我对js也没有什么恐惧感，虽然我很菜。 <br/><br/></div>
<p> </p>
<p> 这么好的苗子，玩JSF，可惜了，呵呵。</p>
</div>
<p>老大 你这什么逻辑关系 用JSF就是JS不行？你也说了JSF只是服务端组件模型 难道服务端组件模型真的强大到可以省了JS？</p>
<p>我还觉得JavaEye这里AJAX版天天框架没出息呢 用Prototype的已经算底层了 天天膜拜Ext</p>
<p>不过相对而言你还是不错的 起码知道自己写个7wx(先不说质量 精神很可贵)</p>
</div>
<p><br/>呵呵，不是这个意思。我是说：一个开发者既然HTML/JS玩得转，又何必去捧JSF的臭脚。</p>
<p>对“服务器端页面”模式，原先只是不喜欢(对“企业应用”而不是“网站应用”)，最近耐着性子看了一遍sun网站上得java ee 5 tutorial 中的JSF章节，现在是&lt;厌恶&gt;了。</p>
<p> </p>
</div>
<p>不要去看Sun的东西 JS+HTML功底过硬的话 你当然应该按自己的思路去考虑JSF了 </p>
<p>服务端组件模型的复用比客户端要容易得多</p>

135 楼 leebai 2008-05-26  

<div class='quote_title'>csf177 写道</div>
<div class='quote_div'>我还觉得JavaEye这里AJAX版天天框架没出息呢 用Prototype的已经算底层了 天天膜拜Ext<br/></div>
<p><br/> <br/><br/>完全同意。 </p>
<p><br/><br/>不过，虽然大部分人盲从，你也要看到fins、jindw、achun...这些同学也一些自己积累的技术。</p>
<p> </p>