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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

这些难道不都是进步么？

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

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

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

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

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

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

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

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



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



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


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

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

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

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

首先你在不了解如何充分利用客户端框架的前提下，枉下评论是很不明智的。我做了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，生来就是一等公民。