JSF 与 "我的伟大发明" ---- 关于B/S UI开发的胡言乱语

这篇帖子后面的回复和讨论 已经变得比主贴本身更值得一读了
希望读这篇帖子的朋友 有时间的话可以看一看后面的那些评论

我不希望这种技术讨论沦为口才的较量 ,所以我本人不会在发表什么观点了
但是我的"关于B/S的解耦性 以及UI层的可独立性"的观点不会改变.

=============================
此文是 "初看jsf后的胡言乱语"http://fins.iteye.com/blog/181093 一文的延伸
同样是在我对JSF知之甚少的情况下写的, 如有不当,请见谅


先来看看一个"我的伟大发明":

汤匙用来喝汤,刀子用来切牛扒. 多麻烦啊. 我设计了这样一个东西:
一头是勺子, 一头是刀子, 这样餐具就可以少一件了, 为我们的采购 摆放 整理 清洗, 提供了极大的方便.
相信不久的将来,这样的产品一定会彻底的淘汰掉现有的汤匙和刀子.


什么?你早想到了? 哦 那好吧 算作"英雄所见略同"好了.

========================================

我的伟大发明说完了, 该说说JSF了.

以前写过一篇文章:
"世上没有B/S系统,只有B系统和S系统"http://fins.iteye.com/blog/123265.

当时对jsf一点也不了解 所以没有谈及更多
(那篇文章里说的更多的是 错误的---我眼中的错误的---使用ajax 所引起的一些我的思考)

但是现在看看 用那篇文章里的观点来表达我对jsf的态度 也许会更合适.


我写那篇文章被很多人说是"标题党,唱高调"
其实 我真的希望我的那篇文章是"标题党,唱高调", 因为那就说明,我所说的已经是废话,已经是尽人皆知的事情.

但事实恰恰相反.有太多太多的人 依然固守着传统的桌面开发模式,并且企图把这种模式强加到B/S系统中.
希望用一种语言 一种模式 来解决B/S里的所有问题.
这种想法是好的, 但是那是多么多么多么的不现实啊.
和前面提到的"我的伟大发明"是多么多么多么的相像啊.


我承认java很好很强大, 它有如下优点:...(此处省去四万五千六百七十八个字)
但是 但是 但是, 他那四万五千六百七十八个字才能说完的优点里,偏偏不包括 编写web-ui.


而jsf 就是要利用各种手段,来让java去做它本就不擅长的事情.
用java费了 九百头犀牛二百只华南虎的力气(简称九牛二虎之力) 做出来的事情,
换作别的语言来做,也许只要九只蜗牛二只壁虎的力气(简称九牛二虎之力) 便能搞定.

引用

用java来生成html+js+css层面的东西, 然后用java来处理发生在 html+js+css层面上的事件.
怎么可能比在html+js+css层面内部做这件事 更好呢??

关于jsf的ui层的实现有多么拙劣 我就不多说了,
如果有哪位能找出一个做的很好的 效果比ext  qooxood dojo 之类的更好的东西请告诉我.
那些商业的 大公司 用jsf做出来的东西 什么 ICEfaces  RCFaces  RichFaces ... , 在ext面前, 你们不觉得你们的face很红吗?


也许有人会说
JSF也可以和EXT dojo相整合啊 JSF UI也是解耦的 可替换的啊,
如果一个产品能够整合一个优秀的产品,那么到底是这个产品优秀 还是被整合的优秀?
而且整合还要看成本呢,
用jsf完全的封装ext有意义吗 有必要吗 有完美的实现吗? 封装出来的东西还具备ext原有的灵活吗?

关于jsf的"可替换", 这里我们要弄明白一件事, ext可以换成dojo,我们就能说jsf的ui层是高度解耦了?
jsf在封装ext的时候,肯定要写很多标签啊 java类啊, 那些东西也是 jsf 的一部分.
我把ext换成dojo, 那些为ext封装的标签啊 java类啊还能用吗???




也许有人会说:
UI组件只是JSF的一部分, 并不是JSF的全部. JSF还有很多 例如:某某模型,某某规范,某某架构,某某机制....
一味的批评JSF的UI, 从而否定整个JSF的做法是错误的


但是 但是 但是 JSF UI这部分和JSF的其他部分---那无数个"某某"----完全紧密的结合在一起,
没有UI的JSF,根本就毫无生命力,根本就不再是一个可运行的框架,
而JSF UI孤立的拿出来, 也根本就不是一个能被称为UI的东西.

所以,我怎么可能单独的去评价JSF的ui?怎么可能脱离JSF UI单独的评价JSF身上UI以外的东西??

引用

如果有一天JSF火了, 有人跑来跟我说, 看,现在是JSF的天下了.
那么我敢保证, 那时候的JSF肯定和现在的大不同, 也许只是名字未变而已.

我再表达一下 我的观点(可能过于理想化):

引用

在B/S系统中
UI层与系统其他层面的东西的唯一联系应该是"数据"
UI层应该是在后台系统不变的情况下可切换的

总之两个字"解耦".

任何违背这个准则的框架我都不认为是好的框架. JSF WICKET DWR 都不是.
事实上,我不认为有哪个框架 可以同时做好 后台和前台两个层面的工作.
既然做不好 那就别做.

整齐划一是好的,但是 我们应该 必须 一定 永远都要承认"分工"的存在.

最后问个问题:

你见过哪个西餐厅会放一把万能的瑞士军刀在餐桌上吗?
如果没有 那好, 请你也不要指望在 B/S系统开发领域内 见到一个万能的"瑞士军刀",
至于那个"我的伟大发明"你更是可以完全忘掉它了.

评论

119 楼 icewubin 2008-04-26  

引用

也许我说的还是太包容了，让你理解不了我的意思，client与server两端的交互使用OO不适合，那么你的做法肯定就是简单的传输了，两边各做各的事情，那么视图状态谁来维护？你肯定是受够了粗粒度框架（struts等）在服务端的维护代码，终于发现其实视图状态在client维护简直是太妙了，你的事件机制，验证，数据状态都可以在客户端轻松实现，的确很美妙，我以前也很喜欢这样做！你的server端呢？依然使用struts等框架接受者request过来的数据，依然要尽量将xml的格式转换成模型，依然要将模型放入服务层，依然要从服务层得到数据，依然要将服务层的模型数据转换成xml，你累吗？你真的不明白jsf的贡献，你的美妙感受jsf都可以做到了，它最有价值的地方就是优雅的解决了视图状态的维护，解决了视图与模型的映像绑定，这种契机带来了seam框架也就是未来的webBeans规范的产生，最终服务端和jsf代表的展现端形成一个统一的开发模型，这是以前根本不敢想的事情，这对开发效率的提高是上了一个很高的台阶！为什么要谈OO，就是以前的约束无法在两端实现真正的OO，真正的MVC！至于client的OO，我很想笑，server端支持OO的开发模式都多久了，client端突然发现现在自己有机会也能处理一些业务，激动的当然也要OO一下！

首先你在不了解如何充分利用客户端框架的前提下，枉下评论是很不明智的。我做了6年多的传统基于URL跳转开发，怎么会不理解你的意思。


视图状态是需要维护的时候，这个是和需求有关的，不是和你技术有关的。比如一个调研类的网站，连续回答100道题，当然要在服务端存放状态，但是未必是视图状态，我可以只在服务端存放很少的数据，比如当前这个用户ID和他回答到第几道题，和回答过的题目的答案。客户端和服务端交互的时候，只要提交当前题目的ID和答案，拿到下一道题的题目内容就可以了。

交互不使用OO是指整个MVC没有必要OO，视图状态也是基于MVC的理解提出来的。交互的数据本身是可以OO，我们采用的就是JSON，服务端的对象图，利用工具转换成JS对象图，传递到客户端，客户端拿到的直接就是JS对象图，也很OO的。所以你已开始跳不出传统MVC的框框，大脑中就一定要维护所谓的视图状态，视图状态本身完全是可以分解的，重要的业务数据可以少量的放在服务端，但是大量的和业务数据无关的视图状态就是扔在客户端的。

JSF的贡献只能基于传统MVC式的思维的，结构上来讲你能会说明JSF比Tapestry优雅在哪？不要臆想什么“美妙的感觉”，客户端框架不是大包大揽，需要和服务端的传统MVC不断配合，不断调整的，所以叫小步迈进。还是说明你在不了解如何利用服务端框架的情况来和我讨论细节是没什么意义的。

client不是现在才发现能处理一些业务的，我之前说过多少次，传统MVC的一大弊端就是为了客户的需求，在客户端充斥了各种不规范、不考虑浏览器兼容性的代码，这个是讨论的前提，你们做的项目如果长得象“贝宝”这种完全不依赖于客户端脚本的页面当然可以不考虑客户端开发的工作量。所以这部分的开发量和调试量是减少不了的，客户端框架主要做的就是在同等效果下减少这部分的工作量，至于为了更多的用户体验而增加的代码，给人一种错觉好像代码反而便多了，那是因为功能增多了，同等功能下，效率一定是提升的。

JS本来就支持OO的，不是激动以后才OO，比如function，生来就是一等公民。

118 楼 myy 2008-04-26  

seekgirl 写道

公元3000年，某程序员拿着需求文档大声的朗诵：系统a，你要实现功能1，功能2。。。。。。 5分钟后，超级计算机回答到：您要的系统已经做好了。

公元4000年，某企业老总带上一个“头盔”，闭上眼睛，大脑开始YY一个ERP系统, 5分钟后“头盔”另一端的超超超级计算机已经把一个完美的ERP系统生成好了。

117 楼 seekgirl 2008-04-26  

公元3000年，某程序员拿着需求文档大声的朗诵：系统a，你要实现功能1，功能2。。。。。。 5分钟后，超级计算机回答到：您要的系统已经做好了。
jsf就是漫长路上的一小段，做的不怎么样，总体思路倒是对。

116 楼 fangshun 2008-04-26  

icewubin 写道

我就是认为“OO”的开发方式维系两端交互不适合，你说的太好了，当初server page产生的历史是由当时受限制的技术条件为背景的，当然是互不适合的。不管是技术的相对进步，还是为了概念的炒作，技术市场的现状就是如此。
还有现在客户端框架也在OO，再次强调，没让你用EXT的全部功能，但是JSF变相的封装JS，难道就算是OO了么，做标准组件开发的必须要熟悉JS的，就好比要精通Hibernate必须要精通Sql是一样，要精通Java或者说JVM等性能问题，熟悉编译也是必要，从来不矛盾。

也许我说的还是太包容了，让你理解不了我的意思，client与server两端的交互使用OO不适合，那么你的做法肯定就是简单的传输了，两边各做各的事情，那么视图状态谁来维护？你肯定是受够了粗粒度框架（struts等）在服务端的维护代码，终于发现其实视图状态在client维护简直是太妙了，你的事件机制，验证，数据状态都可以在客户端轻松实现，的确很美妙，我以前也很喜欢这样做！你的server端呢？依然使用struts等框架接受者request过来的数据，依然要尽量将xml的格式转换成模型，依然要将模型放入服务层，依然要从服务层得到数据，依然要将服务层的模型数据转换成xml，你累吗？你真的不明白jsf的贡献，你的美妙感受jsf都可以做到了，它最有价值的地方就是优雅的解决了视图状态的维护，解决了视图与模型的映像绑定，这种契机带来了seam框架也就是未来的webBeans规范的产生，最终服务端和jsf代表的展现端形成一个统一的开发模型，这是以前根本不敢想的事情，这对开发效率的提高是上了一个很高的台阶！为什么要谈OO，就是以前的约束无法在两端实现真正的OO，真正的MVC！至于client的OO，我很想笑，server端支持OO的开发模式都多久了，client端突然发现现在自己有机会也能处理一些业务，激动的当然也要OO一下！

icewubin 写道

你这人说话怎么这么容易走极端，没人说要在客户端做JDBC，您还别说，早期的JSP就是充斥JDBC（当然JDBC不是客户端），JSP还是早期J2EE的重要组成部分呢。
客户端减弱的MVC的任务，以服务端为主的框架包揽了太多的客户端原本能做的事，本身就是有问题的，问题越搞越复杂，才会出现各种MVC框架，本来的方向就是有问题的。没人说客户端要替代事务层和持久化层。

我不是走极端，这是一个明摆的事情，已经有很多人，在ajax上下大功夫了，我所知道的就有一个做表单的，表单上已经内嵌了所有需要的sql字段，通过client组装sql语句通过ajax发送给server端，多么轻松啊，多么解耦啊！server端的开发实践，开发模式你以为是做了一两年的毛头小伙提出来的，那是沉淀，client有吗？让我们继续造轮子，迟早有一天，ajax在客户端也有mvc框架的概念，呵，server端的mvc方向有问题，佩服！

icewubin 写道

你这话说的太幽默了，“UI框架实现的那么多就是证明”我怎么没看到很多啊，“由几家公司实现了基于struts的ajax扩展框架”很多服务端的Ajax框架都能和struts结合得不错，为什么要基于它扩展呢，这只能说明JSF整体耦合性太高，模块之间一向强调高内聚，低耦合，MVC框架内聚的东西太多也不应该，这个观念迟早会变的。

落后的始终是落后，进步的它就是进步，我就给你举举例子吧，myfaces标准实现后，apache基于myfaces出现的组件框架有Trinidad,Tobago,Tomahawk,Orchestra 等等，有一个是oracle捐赠的；基于模板重新定义渲染层的facelets框架，jboss公司出品的seam框架的重头戏就是增强jsf实践能力，增强jsf与业务框架的缝合能力，以及jsf的页面流程配置能力，richfaces，icefaces, ajax4jsf,都是jboss出的ajax的组件框架；金蝶的OperaMasks,包含了标准实现，ajax组件，seam功能很类似的增强框架IDE支持等等。sun基于netbeans的Visual JSF开发工具
Infragistics的商业jsf组件。等等........，我数不清了，你自己数吧！以前的框架能带来这样的连锁效应吗，怎么会是耦合性太高带来的产物呢？。老外都傻了吗啊，袁红岗技术认识很差啊！ 顺便你也说说基于struts都有什么扩展增强框架，别说的那么笼统，结合的不错，用xml作为纽带算集成吗，我用js通过ajax照样可以能让jsf基于request进行处理。

icewubin 写道

“软件耦合处需要分割后通过胶合剂粘合”，胶合剂不要太多啊，不懂的人，只能说这个架构师不懂什么叫UI架构师，退一步说身为架构师，UI部分是必须掌握的部分，即使不精通也得理解，也得考虑公司的用人成本和学习兴趣，也得考虑公司的技术路线，考虑客户的体验，考虑如何像自己的大老板汇报，要靠率各方涉众的利益。

spring的主要工作就是防止侵入，实现粘合，呵呵，这个粘合剂够多吧，seam干脆就叫缝合，和粘合就差一个字，难道胶合剂仅仅是一个客户端到服务端的传输线？？？做技术千万别提大老板啊，咱们不讨论那个，做好技术就OK，客户的体验我认为是其次的，满足实际业务需求才是最主要的，也是最致命的，满足实际需求的第一要诀就是适应需求变化，满足需求变化的第一要诀就是建立柔性的架构设计，好好想想全局怎么考虑问题吧，client技术和jsf相比，后者对于架构设计的协助要好的多，client模式只会降低架构设计的伸缩性，只能让设计与实现龟缩在client里面扑腾。

icewubin 写道

没人说它代表业务开发的全部，但是目前的开发模式，开发人员大量的时间用在UI开发和调试上，结果从时间上看就是开发的中心，当然要分项目，要看你这个项目是“平原型”还是“深井型”，即使“深井型”UI部分的工作量不会少到哪里去的。“client端去替代本不属于它们的功能范围的事情”，这个进步吗？以前CS结构，不就是客户端该做的事么？如果CS结构结局部署的问题，解决客户端容量大小的问题，解决服务端没有中间层的问题，不就是将来的RIA么，既然大家都认可RIA的未来，为什么就不认可目前的Ajax呢？完全的偏见啊。

“开发人员大量的时间用在UI开发和调试上”，我很赞同这句话，这就是我为什么选择jsf的主要原因，太多太多的事情你不用做了，你不用做了，不代表它不存在，jsf解决了，就应该记住，而不是因为它不好解决的事情而反对或者反感。

到底谁抢了谁的饭碗，现在来看B/S抢了C/S的饭碗，RIA想重新夺回，如果有那一天，我到完全可以接受，可你说了大家认可未来的RIA。而现在需要的是让RIA做它该做的事情，能做事情。目前我坚持认为维系两端的中间层开发模型，这个不可忽视的领域，jsf当仁不让！

115 楼 icewubin 2008-04-26  

引用

AJAX有什么稀罕的，这种东西还有什么进步不进步。

我们公司的技术由完全刷新到部分刷新，减少服务器的负载，降低网络流量。

页面效果上由相对朴素的页面改善成能让用户感觉很熟的界面。

页面中的JS代码由以前各自为政的风格迥异的代码，变成能够相对统一，大大减少人员流动成本和维护成本。

这些难道不都是进步么？

当然这些进步不完全因为Ajax技术本身，我这里说的Ajax框架代指EXT之类的综合性框架。

顺便说一下，我不认为EXT仅仅是一个Ajax框架，是个客户端综合框架，比如我针对网络传输的特点，对下拉框的数据来源反而是不用它的Ajax特性，采用local的方式提高数据传送效率。现在想想，我在设计数据交互的时候还尽量少的发生Ajax数据请求，只是把原本基于URL跳转的模式部分变成了Ajax通讯，不段做调整的，所以是小步迈进。

如果你认为这些不算是进步，那我们就不用讨论下去了，我在半年前不断问自己，要好看的界面和Ajax通讯到底有什么用，到底能给客户带来多少价值。后来事实证明，效果远远超出我和同事的想象。

最近的几个项目，极其少见的出现，用户对界面的难看与否只字不提，提的修改意见和界面几乎没有关系，这在我们以前做的项目是不可想象的。

还有就是我们的大老板，平时不大表扬的，突然冒出一句“界面设计不错”的话来，让我们大吃一惊，以我们对他的了解，我们还以为他会说我们界面太花哨呢。

就在前两天，经过测试人员的负载测试，ajax减轻服务端负载和流量压力还有了数字上的依据。

我在拿各种事实说话，你呢？

114 楼 icewubin 2008-04-26  

引用

用JS编写的东西也得考虑多浏览器的兼容性 这和JSF没什么区别。

JSF只是太新 而且当前国内没什么太成功的案例，而且害怕如此复杂技术的人太多 ，所以导致你们害怕JSF。

我一直强调现在有各种JS客户端框架，没说完全用JS干写，这个是绝对重要的前提，兼容性已经由框架帮我们考虑，经过我们实际使用测试，没发现任何的不兼容的情况，当然我们的测试未必做到面面俱到，就我使用的部分来说，完全没碰到兼容性问题。

“JSF只是太新”？都两年多了还新？你对JSF历史了解太少。“而且害怕如此复杂技术的人太多”，Hibernate够复杂了，还不是成功了，这和复杂没有直接关系。再说了一个技术的学习成本当然是要考虑的。“所以导致我们害怕JSF”，我们有害怕么？好的东西我很乐于接受的，从来没有害怕这一说，你又没拿刀子对着我，我害怕什么？难道还怕掌握的技术被淘汰，我对你说，我的JS还没我带的人水平高呢，我害怕他们超过我么？我还担心他们水平不够高呢，他们水平越高，我就能花更多精力在其他方面了。

113 楼 icewubin 2008-04-25  

poko110 写道

icewubin 写道

poko110 写道

你说的
UI设计到客户的确认的不断迭代过程难道不是敏捷么，JSF做得到么（难道发个绿色的tomcat和JVM给客户看效果？），成本对比如何？好好想想吧。


这些东西有个度的原因 ，当前JSF的控件当然不是非常完美的 ，但是他正朝着这个方向发展，你这个观点无异于说 开发WINDOWS程序的时候 客户反对一切控件的样式 。
JSF怎么会做不到不断迭代过程。当然这个美工稍微懂一点JSF的基本规则

如果你限定好一切条件 那你只能用汇编或者机器码

我哪有说“开发WINDOWS程序的时候 客户反对一切控件的样式 。”，客户才不管你做UI设计用什么形式。我说了你完全可以在白板上和客户确认每个操作流程，然后照相机拍下来，或者用其他工具画界面和客户确认。但是最后这些确认得到的资料转化成最终的界面都是需要开发成本的。UI设计先行的理念类似于测试先行，可操作性上来说更有可能。

当然这个美工稍微懂一点JSF的基本规则，怎么个稍微懂一点？我说过不止一次，讨论都是有前提，你没必要动不动就走极端说什么汇编，我假设的这些前提都是适合于80%的中小公司的，自己要承担需求风险的，技术选型是自主的，当然有公司是不适合我这次讨论的，但也不至于你说得我先定好一切条件吧，非得用汇编，真怀疑你对大多数公司的的软件工程过程管理了解多少。

我看你是外包做多了，我说上面的话主要是 因为国内JSF学的都不够深入，所以美工还是需要照顾到一点程序员的。如果JSF比较精通 那你照样可以画 可以相机拍 有什么问题？
你的观点让我觉得 好像在说ORACLE不好，因为ORACLE难操作 所以ACCESS好。
我决的如果一个人要完成更多的工作 构造更大规模的工程，那使用JSF再好不过。 你不用再理会什么JS,什么HTML，什么HTTP，什么SESSION。你站在更高的层次用JAVA代码来描绘你想要的世界。这有什么不好吗？

你可以说国内JSF学的都不够深入，我还觉得国内的程序员相当长的一段时间内歧视脚本语言呢。我说的美工需要照顾程序员是有伏笔的，理想状态下是要有UI设计师来做这个是的，而不是美工。我说的画画和拍照都是有典故的，意思是指两点：不要小看传统沟通能力和效率，沟通方式和实现方式有很多种，但是时间和成本都是有限的，大家都是要和成本控制作斗争的。

但是Oracle的灵活性比Access差么？大数据量下，oracle的速度比access快多少？作类比不要这么片面好么？

Java一定层次高么（虽然我支持Java，但是Java的缺点我看得很清楚）？理由是什么？你怎么不用ruby或者是MDA语言呢？MDA层次还要高呢？你有想过MDA为什么火不起来的深层次原因么？

用同一种语言描绘世界没什么不好，但是时间和成本不允许你这么浪费各种成本，一个企业要在各个方面和同行业企业竞争，不进则退。我之前有一个长贴也说了在国内的中小企业，适当的使用大家认为优秀的技术能够间接的降低成本。

112 楼 poko110 2008-04-25  

“我们公司在向Ajax小步的迈进的过程中非常谨慎，现在取得了阶段性的成果”


AJAX有什么稀罕的，这种东西还有什么进步不进步。

“我反复强调了JSF这种模式必然导致在使用封装Ajax组件、开发自定义标准JSF业务组件的时候，调试成本非常高。”

用JS编写的东西也得考虑多浏览器的兼容性 这和JSF没什么区别。

JSF只是太新 而且当前国内没什么太成功的案例，而且害怕如此复杂技术的人太多 ，所以导致你们害怕JSF。

111 楼 poko110 2008-04-25  

icewubin 写道

poko110 写道

你说的
UI设计到客户的确认的不断迭代过程难道不是敏捷么，JSF做得到么（难道发个绿色的tomcat和JVM给客户看效果？），成本对比如何？好好想想吧。


这些东西有个度的原因 ，当前JSF的控件当然不是非常完美的 ，但是他正朝着这个方向发展，你这个观点无异于说 开发WINDOWS程序的时候 客户反对一切控件的样式 。
JSF怎么会做不到不断迭代过程。当然这个美工稍微懂一点JSF的基本规则

如果你限定好一切条件 那你只能用汇编或者机器码

我哪有说“开发WINDOWS程序的时候 客户反对一切控件的样式 。”，客户才不管你做UI设计用什么形式。我说了你完全可以在白板上和客户确认每个操作流程，然后照相机拍下来，或者用其他工具画界面和客户确认。但是最后这些确认得到的资料转化成最终的界面都是需要开发成本的。UI设计先行的理念类似于测试先行，可操作性上来说更有可能。

当然这个美工稍微懂一点JSF的基本规则，怎么个稍微懂一点？我说过不止一次，讨论都是有前提，你没必要动不动就走极端说什么汇编，我假设的这些前提都是适合于80%的中小公司的，自己要承担需求风险的，技术选型是自主的，当然有公司是不适合我这次讨论的，但也不至于你说得我先定好一切条件吧，非得用汇编，真怀疑你对大多数公司的的软件工程过程管理了解多少。

我看你是外包做多了，我说上面的话主要是 因为国内JSF学的都不够深入，所以美工还是需要照顾到一点程序员的。如果JSF比较精通 那你照样可以画 可以相机拍 有什么问题？
你的观点让我觉得 好像在说ORACLE不好，因为ORACLE难操作 所以ACCESS好。
我决的如果一个人要完成更多的工作 构造更大规模的工程，那使用JSF再好不过。 你不用再理会什么JS,什么HTML，什么HTTP，什么SESSION。你站在更高的层次用JAVA代码来描绘你想要的世界。这有什么不好吗？

110 楼 xiao0556 2008-04-25  

我用seam做ＪＳＦ开多一年半了，jsf想的太理想化了有点脱离了实际需求。其多达６个请求生命周期的会造成你在集成ＡＪＡＸ的时候　复杂度远远超过你的想像（如果你的应用界面相对简单例外，或是你把所有状态所在Ｓｅｓｓｉｏｎ里）。比如根据条件动态切换页再提交，当然你想简单点也可以请把所有的数据放到session里　但这样我感觉很不爽.自定义的ＵＩ组件开发起来真的很烦。渲染器(就像servlet写html)　ＵＩ组件　还要注册　总的来说学习生成太高而且不灵活　有人说很灵活可以扩展啊　但是扩展的生成你算过没有　当然能扩展　但是值不值呢。如果你用ＪＳＦ做传统应用　就是跳来跳去的话相信很多框架比它做的好，如果你做交互比较复杂的应用　那用Ｅｘｔ吧（或别的Ａｊａｘ框架）或Ｆｌｅｘ

109 楼 icewubin 2008-04-25  

poko110 写道

你说的：
和目前我见到的大厂商的产品的界面都是往Ajax的方向走。

我怎么不见的大家都在往AJAX发展 ，AJAX一直都存在 只是现在有些炒作而已

我觉得用不用无所谓，增加流程和开发步骤。 这只是一种方式 ，以前做在线进销存的时候完全用FLASH来和服务器通讯  比AJAX还有激情 。 我觉得你现在有点迷失在AJAX中。其实这个东西很平常，

再说JSF JSF组件更可以使用AJAX 而且是组件化的使用，只需要编写一次，
AJAX根本不和JSF在一个层次上。JSF甚至还可以包含TELNET客户端。

另外不用跟我解释那些名词  我就是这么一路过来的。

我迷失么？我们公司在向Ajax小步的迈进的过程中非常谨慎，现在取得了阶段性的成果，整体开发效率得到很大提升，客户满意度极大的提高，程序员对新技术的认可程度也很高。我是在我们公司取得阶段性成功之后，才把半年多来我的想法和实践体会和大家交流，你在不了解很多行业背景的情况下枉自说我迷失，真幽默啊。

你没看到大厂商的产品那就是你的问题，就我看到的有Cognos的前台报表、微软的BI工具等，Ajax的元素越来越多。

没人说JSF不能用Ajax组件，之前大家都说了，JSF的问题是不灵活，支持和灵活使用是两码事。

编写一次不等于调试成本低，我反复强调了JSF这种模式必然导致在使用封装Ajax组件、开发自定义标准JSF业务组件的时候，调试成本非常高。

我们讨论的东西和telnet客户端有关么？先前还有个人和我讨论手持设备呢，讨论这个有意义么，这里又不是工具讨论组和嵌入式讨论组，要进行跨界讨论也不是这个帖子里做的事。

还有一点，我哪里有解释名词了？我解释哪个名词了？我只是举了些例子，并没有解释啊，你是不是没仔细看，扫两眼就开始回贴了？

108 楼 icewubin 2008-04-25  

poko110 写道

你说的
UI设计到客户的确认的不断迭代过程难道不是敏捷么，JSF做得到么（难道发个绿色的tomcat和JVM给客户看效果？），成本对比如何？好好想想吧。


这些东西有个度的原因 ，当前JSF的控件当然不是非常完美的 ，但是他正朝着这个方向发展，你这个观点无异于说 开发WINDOWS程序的时候 客户反对一切控件的样式 。
JSF怎么会做不到不断迭代过程。当然这个美工稍微懂一点JSF的基本规则

如果你限定好一切条件 那你只能用汇编或者机器码

我哪有说“开发WINDOWS程序的时候 客户反对一切控件的样式 。”，客户才不管你做UI设计用什么形式。我说了你完全可以在白板上和客户确认每个操作流程，然后照相机拍下来，或者用其他工具画界面和客户确认。但是最后这些确认得到的资料转化成最终的界面都是需要开发成本的。UI设计先行的理念类似于测试先行，可操作性上来说更有可能。

当然这个美工稍微懂一点JSF的基本规则，怎么个稍微懂一点？我说过不止一次，讨论都是有前提，你没必要动不动就走极端说什么汇编，我假设的这些前提都是适合于80%的中小公司的，自己要承担需求风险的，技术选型是自主的，当然有公司是不适合我这次讨论的，但也不至于你说得我先定好一切条件吧，非得用汇编，真怀疑你对大多数公司的的软件工程过程管理了解多少。

107 楼 icewubin 2008-04-25  

poko110 写道

你说的
RIA：Applet、webstart（Swing的BS方案，不是CS）、Google Gear、Sliver Light、JavaFX

你知道让一个人安装一个插件是多么难吗，现在事实上的标准只有FLASH，
动不动几十M的运行时 你该如何安装到他们的浏览器里？

对啊，你说得没错，否则这些技术都会快速推广的，目前sliver Light和Java都准备出2MB做得精简客户段“虚拟机”，要说难也未必这么难，google也出了Google Gear，以前也出过google bar，难道会很多人排斥google么？

106 楼 poko110 2008-04-25  

你说的：
和目前我见到的大厂商的产品的界面都是往Ajax的方向走。

我怎么不见的大家都在往AJAX发展 ，AJAX一直都存在 只是现在有些炒作而已

我觉得用不用无所谓，增加流程和开发步骤。 这只是一种方式 ，以前做在线进销存的时候完全用FLASH来和服务器通讯  比AJAX还有激情 。 我觉得你现在有点迷失在AJAX中。其实这个东西很平常，

再说JSF JSF组件更可以使用AJAX 而且是组件化的使用，只需要编写一次，
AJAX根本不和JSF在一个层次上。JSF甚至还可以包含TELNET客户端。

另外不用跟我解释那些名词  我就是这么一路过来的。

105 楼 poko110 2008-04-25  

你说的
UI设计到客户的确认的不断迭代过程难道不是敏捷么，JSF做得到么（难道发个绿色的tomcat和JVM给客户看效果？），成本对比如何？好好想想吧。


这些东西有个度的原因 ，当前JSF的控件当然不是非常完美的 ，但是他正朝着这个方向发展，你这个观点无异于说 开发WINDOWS程序的时候 客户反对一切控件的样式 。
JSF怎么会做不到不断迭代过程。当然这个美工稍微懂一点JSF的基本规则

如果你限定好一切条件 那你只能用汇编或者机器码

104 楼 poko110 2008-04-25  

你说的
RIA：Applet、webstart（Swing的BS方案，不是CS）、Google Gear、Sliver Light、JavaFX

你知道让一个人安装一个插件是多么难吗，现在事实上的标准只有FLASH，
动不动几十M的运行时 你该如何安装到他们的浏览器里？

103 楼 icewubin 2008-04-25  

引用

不要忽略事实上的标准和 现实情况 使用客户端 不要安装吗？不是时代倒退是什么？(就当前而言) 当然可以用FLASH 但是JSF也正在用这个方式去支持FLASH。遇到现有组件无法解决的时候，JSF并不阻止你直接在页面中嵌入其他脚本。另外你编写了组件得到了高度复用的优点 当然要为了他付出一些时间。这和敏捷有什么关系 不要讲些虚无缥缈的东西来搪塞。

先说什么叫事实上的标准，事实上的标准就是从网站炒web2.0的概念到大厂商炒企业2.0的概念，和目前我见到的大厂商的产品的界面都是往Ajax的方向走。

再和你详细分析使用客户端为什么需要安装，现在很多swing方案根本不需要安装，用webstart就能解决部署的问题。
不要拘泥于什么名词，浏览器也是客户端，不同浏览器兼容性还很差呢。

1.最早的CS结构的程序，例如QQ，QQ上线后，判断是否需要更新程序，然后开始复杂的更新过程，先停止客户端的服务，然后下载升级文件，全部的或者是增量的，然后重新注册DLL，再启动程序。

2.后来流行的BS结构，浏览器从服务端拿到HTML（不要以为是什么JSP或PHP啊，不解释了）+图片+JS等，然后浏览器本身就是客户端，对拿到的东西进行渲染。Ajax架构和这个是一模一样的，只不过JS稍微大一点而已，和图片比起来，GZIP压缩后的JS还是算小的。

3.RIA：Applet、webstart（Swing的BS方案，不是CS）、Flex、Google Gear、Sliver Light、JavaFX等，都是现在客户端装插件（当然现在开始比谁的插件少），然后RIA“虚拟机”每次自动判断程序内容是否更新，更新的话马上下载，就是不需要QQ那样自己实现升级，RIA“虚拟机”接管了这个自动部署的“艰巨”任务。重要的是，这个过程从数据流动上来讲和浏览器自动判断JS需不需要更新是一样的。

所以你说“使用客户端 不要安装吗？不是时代倒退是什么？”我就感觉你被BS和CS的名词束缚住了，仔细想一下部署的模式，没有什么本质区别。

然后说一下敏捷的事，虚无缥缈么？如果你不是外包公司的话，你从需求开始起，如何降低需求的风险？

我认为在需求阶段，就可以提前开始做UI设计，当然UI设计方式多种多样，可以画个图、照相机拍下来（有老外就是这么干的），可以用工具画出界面设计图，并描述出主要的页面逻辑，或者用DreamWeaver做出大致的界面和客户确认需求，主要是通过确认的过程中发现需求不理解的地方或者是需求的误区，尽可能早的降低需求风险。

当然这一时期的UI设计可以简单，可以复杂，但是到了系统设计-开发的迭代阶段（不迭代也一样的），UI设计就要细化，这个细化总是有的，即使没有专门的过程，比如小公司时间紧，UI设计的细化就是参杂在开发的工程中，有点做到哪设计到哪的味道，差一点的，整个UI设计会存在于项目经理或者是技术经理的大脑中（不会让开发人员异想天开）；好一点的，就是用需求阶段类似的方法进一步详细化，然后和客户确认，这么做的目的是希望及早发现问题，等拖到开发的差不多了才发现问题就会带来非常巨大的修改成本，导致项目失控和延期。

所以整个过程就是敏捷的思想，UI部分的快速原型，和客户确认，确认的过程大大降低需求风险，并不是什么虚无缥缈的东西，你想想国内有多少项目事实上毁在了需求上，客户一眼看到界面就说这不是他要的东西。。。

说了这么多，然后就是如何的UI部分快速原型，以前这种模式，用美工快速做出页面是可行的，但是美工很有可能是没有程序员的能力的，你让他做出越来越多的带Ajax风格或者是精致渲染的界面（不管你用什么技术，越来越多的Ajax风格的出现是不可避免的，当然你们公司需求人员强势，需求导向厉害那就另当别论），是不现实的，美工往往只会DreamWeaver。

所以能够不依赖于服务端基础设施，让某个程序员配合美工，做出UI界面时非常划算的步骤：
1.客户不会因为看到的Ajax界面和静态Demo（无一些特殊效果）差异过大，而产生疑问，如果客户非常不幸运的不认可Ajax的风格，就白做了。
2.很多项目是售前打单项目，只要界面，还只要界面好看，根本不需要什么后台。
3.如果项目开始实施，UI界面拿来就能直接开发了，节省了开发时的UI开发时间，而且界面操作过程是客户确认过的。

我只是借用了“敏捷”一词而已，UI设计到客户的确认的不断迭代过程难道不是敏捷么，JSF做得到么（难道发个绿色的tomcat和JVM给客户看效果？），成本对比如何？好好想想吧。

102 楼 poko110 2008-04-25  

icewubin 写道

poko110 写道

我觉得楼主没有真正的指出JSF的弱点，也没有看清楚它的强大。你不过是站在外人的角度去看待它的表面。

我使用JSF开发2年来，觉得最大的弱点在于JSF的性能还很勉强，完全不适用于门户型网站，而且高度组件化造成很难修改具体某点小型是。JSF组件难开发，有一个原因是因为中文资料相对来说非常少，而且组件这个东西本身层次就有点，你得考虑发生的众多情况，改变原本的处理方式。

但是 非常重要的是 ，我们再也不要重复的去操作编写调用一段JS。我们完全站在更高的一个层次上去看待问题，其实你说的AJAX那真的有那么重要吗 ，我记得02还是03年的时候还没有这种概念 我使用FLASH和服务器通讯或者IFRAME，用不用那些看具体情况 可以具体实现 又不是必须的。 我觉得真正理解JSF的人不是不会写JS的人 而是不再想写JS不再想在那么底层做东西的人。

时代发展不就是这样吗，你编辑HTML，编写JS 就好像现在用C去编写程序，虽然你可以精确控制但是却很难操作大局。而且JSF并去反对你在页面中插入那些代码。

反过来说，我用客户端的框架，一样不用去造轮子，你这么说话，完全就是不了解客户端框架目前的现状，不知道客户端框架目前的生产力到底是怎么样的。

这么说吧，这几天我又想了一下，JSF甚至于其他服务端生成JS的框架，如果我要调试一段JS（你不能保证也不可能保证所有的JSF组件没有BUG，自己开一个总要调试吧），周期太长，从敏捷的角度来说，这个是致命的。

不要忽略事实上的标准和 现实情况 使用客户端 不要安装吗？不是时代倒退是什么？(就当前而言) 当然可以用FLASH 但是JSF也正在用这个方式去支持FLASH。遇到现有组件无法解决的时候，JSF并不阻止你直接在页面中嵌入其他脚本。另外你编写了组件得到了高度复用的优点 当然要为了他付出一些时间。这和敏捷有什么关系 不要讲些虚无缥缈的东西来搪塞。

101 楼 icewubin 2008-04-24  

fangshun 写道

  
  你所说的jsf不适合B/S我认为更多的是jsf为开发者建立的开发方式不适合，而不是jsf机制不适合。但是如果这种开发模式不适合，那么也就是认为OO的开发方式维系两端交互不适合，那我也没办法，具体情况具体对待了！

我就是认为“OO”的开发方式维系两端交互不适合，你说的太好了，当初server page产生的历史是由当时受限制的技术条件为背景的，当然是互不适合的。不管是技术的相对进步，还是为了概念的炒作，技术市场的现状就是如此。
还有现在客户端框架也在OO，再次强调，没让你用EXT的全部功能，但是JSF变相的封装JS，难道就算是OO了么，做标准组件开发的必须要熟悉JS的，就好比要精通Hibernate必须要精通Sql是一样，要精通Java或者说JVM等性能问题，熟悉编译也是必要，从来不矛盾。

fangshun 写道

  第二点：我一直都不赞成企业应用过分的炒作ajax，jsf加入ajax框架，其实这才是商业化的推动。而对于一个简单的js应用，其实使用后台一个简单的servlet就可以处理了，而jsf却要那么多复杂步骤，来完成一个同样作用的事情。赞同者认为增强复用，简化使用。批评者认为不灵活，制作组件麻烦。其实这就是组件化优劣之处，只不过对于client技术深度侵入业务应用还不是很成熟的情况下，却要将组件安置到前端，所以这个问题更加明显。也有人回帖说client技术是抢了server端技术的饭碗，我认为是很肤浅的看法，client端如果能OO化，带了高级的企业特性，那么甚至server端摆个数据库就可以了，十年前人们就应该想到了，为什么还要傻傻的转移到Server端技术呢。因为很多事情你没有想到，并不代表它不存在，就像j2ee核心技术很多都在很好的运行而你确不用关注。你关注的更多的是模型的设计与建立上，如果模型对象要是放在client端我才觉得有些奇怪，干脆吧应用服务器的底层都放在client吧，jdbc也用js来实现一套。这样使用起来才方便。到底看谁比谁复杂！

你这人说话怎么这么容易走极端，没人说要在客户端做JDBC，您还别说，早期的JSP就是充斥JDBC（当然JDBC不是客户端），JSP还是早期J2EE的重要组成部分呢。
客户端减弱的MVC的任务，以服务端为主的框架包揽了太多的客户端原本能做的事，本身就是有问题的，问题越搞越复杂，才会出现各种MVC框架，本来的方向就是有问题的。没人说客户端要替代事务层和持久化层。

fangshun 写道

  
  第三点：jsf的UI机制是分离的，我不说了，你最好再看看jsf的实现机制。UI框架实现的那么多就是证明，你见过由几家公司实现了基于struts的ajax扩展框架（从另个方面讲，根本不用实现，基本很简单）。

你这话说的太幽默了，“UI框架实现的那么多就是证明”我怎么没看到很多啊，“由几家公司实现了基于struts的ajax扩展框架”很多服务端的Ajax框架都能和struts结合得不错，为什么要基于它扩展呢，这只能说明JSF整体耦合性太高，模块之间一向强调高内聚，低耦合，MVC框架内聚的东西太多也不应该，这个观念迟早会变的。

fangshun 写道

  
  第四点：很多架构师都是披着羊皮的狼，那么深沉的角色居然前端玩开ajax，感觉好前卫啊！ajax有一种用法很邪恶，就是作为数据的输入输出机制，使用某种载体（例如xml）成为一体的流水线，让两边的工人明白对方想要什么，就放什么。不用OO，只要尽快看到东西，跨时代进入工厂化，不求产品质量，禁止业务变动，只要分工明确，一切留待维护。大量的程序员一端用js美化调试，一端装配着持久层需要的东西，看似很自动，很流程，却搞不清楚软件耦合处需要分割后通过胶合剂粘合;需求变动后不再重新构建和迭代模型结构，确不得不重新换了一条生产线；搞不清楚用UML画什么图形，只要prototype和数据库字段对应就ok。

“软件耦合处需要分割后通过胶合剂粘合”，胶合剂不要太多啊，不懂的人，只能说这个架构师不懂什么叫UI架构师，退一步说身为架构师，UI部分是必须掌握的部分，即使不精通也得理解，也得考虑公司的用人成本和学习兴趣，也得考虑公司的技术路线，考虑客户的体验，考虑如何像自己的大老板汇报，要靠率各方涉众的利益。

fangshun 写道

  第五点：如果直接使用ext等js框架是很好，也没有必要要求它们去支持jsf，但是它的主要作用就是js显示组件库，它不代表的是业务开发的全部，也不是业务开发的重心，所以它们不需要，也不够格去考虑怎么和server端集成，而是server端框架怎么去集成它们才对，多考虑server端如何更好的集成client技术要胜过让client端去替代本不属于它们的功能范围的事情，这要进步多。

没人说它代表业务开发的全部，但是目前的开发模式，开发人员大量的时间用在UI开发和调试上，结果从时间上看就是开发的中心，当然要分项目，要看你这个项目是“平原型”还是“深井型”，即使“深井型”UI部分的工作量不会少到哪里去的。“client端去替代本不属于它们的功能范围的事情”，这个进步吗？以前CS结构，不就是客户端该做的事么？如果CS结构结局部署的问题，解决客户端容量大小的问题，解决服务端没有中间层的问题，不就是将来的RIA么，既然大家都认可RIA的未来，为什么就不认可目前的Ajax呢？完全的偏见啊。

100 楼 icewubin 2008-04-24  

fangshun 写道

hax 写道

JSF是可以产生js。你可以想象成一个编译器把高层代码编译成了底层代码。但是且慢，你要注意到这样一种模式的复杂度。因为浏览器端的html/css/js并不是机器语言、汇编代码。它的复杂度已经超过了许多通用编程语言。所以结果就是：
1. jsf不能充分运用浏览器的特性，尤其是现在浏览器大发展的形势下。
2. 两端模型不匹配。比如css对于样式的分离非常出色，但是在现在的jsf体系里根本没有它的位置。
3. 自定义控件变得非常困难，而且随着浏览器与jsf模型的渐行渐远，难度还会进一步加剧。

  高级语言替代底层语言一直都是大势所趋，你一定要清楚jsf也是在发展的，其实我对jsf的tag标记库也很不满意，但是tag标记那只是jsf ui端的起点，而不是终点，facelets模板渲染机制的出现就证明jsf的渲染机制可以灵活发展，如果用jsf的UI层去方便的控制js的显示那才是很舒服的事情，但是你一定要说直接用js更灵活，那也是对的，就看划不划算！
  使用jsf的第一要诀就是懂得css对页面进行样式分离，因为jsf的组件块特性决定了css表的控制更利于jsf在页面上的显示逻辑，所以不是你说的没有位置，而是非常重要，我现在的项目中，CSS已经起到了决定性作用，基本抛弃了表格式布局。
  浏览器的发展会朝着浏览器脚本语言统一支持的方向进步，不管对于直接操作浏览器脚本还是通过组件化渲染脚本都是好事！自定义组件的开发是有难度，但不是难上青天，自定义组件也分为验证组件，转换组件，监听组件，标准组件。写一个标准组件进行渲染html也很容易，困难主要集中在开发一个具有交互式意义的标准组件，需要了解组件的族系，但是当你做过以后就会发现组件开发的继承关系，既是一堵墙也是一座桥,就看你熟不熟了！

接上面我的帖子，如果你要开发标准组件，你要同时了解JS，还要了解整个JSF组件的生成JS的机制和运行机制，还要相对很长的生成周期，这个致命弱点已经足够说明问题了。

再说明一点，以后我会系统提到，合理使用Ajax，并自己精确控制，能够变相的减少很多原本完全没必要的MVC逻辑，极大的提升开发效率，弱化对MVC框架的依赖，绝对不是界面花哨那么简单的事，本质上来讲是先要改善用户体验，然后再由这个技术的前提下，还能改变UI交互模式，减轻服务端的负载，减少网络流量。