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

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

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

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


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


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


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


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

不要忽略事实上的标准和 现实情况 使用客户端 不要安装吗？不是时代倒退是什么？(就当前而言) 当然可以用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给客户看效果？），成本对比如何？好好想想吧。

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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