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系统开发领域内 见到一个万能的"瑞士军刀",
至于那个"我的伟大发明"你更是可以完全忘掉它了.

评论

99 楼 icewubin 2008-04-24  

poko110 写道

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

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

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

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

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

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

98 楼 hax 2008-04-24  

有很多人看了jsf一眼就放弃了，为什么？难道不值得jsf反思么？

97 楼 lbfhappy 2008-04-24  

为什么有这么多不了解JSF的人在这里瞎评论JSF?

96 楼 awFeeling 2008-04-24  

首先声明，我对JSF不了解。

楼主所提的B系统和S系统，其实就是C/S架构的另外一种说法，只不过将客户端(C)限定为浏览器了而已。
这里的C/S和原来的C/S最大的差异是在S端，在原来的C/S架构中，S主要是指数据库，而现在的S，指的是能够为客户提供服务的一端。

我是非常赞同楼主强调的客户端和服务器端的解耦，这样才能够最大程度的避免由于服务提供者和服务使用者其中某一方的变化，导致另一方不得不跟随着变更。

之所以我对JSF不了解，是因为JSF给我的第一个印象就是它在服务器端，要对客户端的行为进行约束，而不是对客户端的数据消费方式(C/S数据交换接口)进行约束。当然，也许这是一个错觉，不过为什么它会给我这样一个错觉，而使我不愿意去了解它，也许还有其它的原因吧！

95 楼 poko110 2008-04-24  

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

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

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

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

94 楼 leebai 2008-04-23  

to fxy1949:

http://www.iteye.com/topic/185839

93 楼 indexchen 2008-04-23  

又想要开发效率高，又不想写javascript,又要得到ajax效果，那就选GWT好了。

92 楼 icess 2008-04-23  

terranhao 写道

我反驳不了你.
我都是用别人的组件,myfaces  richfaces
JSF开发组件确实很麻烦.但是,优秀的组件非常多
干嘛要重复发明轮子.
你对JSF的批评根本没到点子上
JSF最大的毛病是运行效率比JSP低了2,3倍,不过企业级的应用服务器应该都是比较牛B的,所以大致来说效率可以接受.
你去jboss看看他的rich-faces的demo吧,再想想你做个这种效果出来需要多久?

同意， JSF和 Ext之类的框架，关注的不是同一个方向，目标市场不是同一个市场， 没有很大的可比性， JSF不能替代所有的web开发框架， JSF专注于比较传统的企业级web开发， 需要良好ide支持的快速开发框架。

91 楼 icess 2008-04-23  

fins 写道

补充一下
我所说的

JSF开发UI组件很麻烦

是指 开发组件 而不是使用已经开发好的JSF UI组件
我说的是 开发 不是 使用

JSF的初衷不是让使用者开发组件，而是让一些专注于开发组件的公司和组织来开发组件，进而让其他开发者使用，形成一个第三方市场，比如IceFaces。 不熟悉组件开发，而你又非要去做组件，这无异于没有翅膀非要去飞翔的想法。

90 楼 fangshun 2008-04-23  

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也很容易，困难主要集中在开发一个具有交互式意义的标准组件，需要了解组件的族系，但是当你做过以后就会发现组件开发的继承关系，既是一堵墙也是一座桥,就看你熟不熟了！

89 楼 hax 2008-04-23  

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

88 楼 fxy1949 2008-04-22  

I think we are doing a quality discussion that helps us to understand more about the technology we are not familar and the core issues of B/S development. It's pretty good and I'd like to add a little bit more.


正如我前面提到的，不理解fins的人大多是思想被“server pages”禁锢者，总认为浏览器只能负责 html render，其他一切都应该在服务器上完成，就如IT业早期的主机－字符终端模式。这种思想本质上是把浏览器看作21世纪的字符终端，完全忽略和闲置了目前运行浏览器pc的强大计算功能。

If you open the source file of the html created by JSF,you will find that there are lots of javascript code used. With JSF,you are not prohibited to use Javascript, but you are not encouraged to use javascript directly. Let UI Compoments do it.

JSF wants the developer leave the javascript. It means during development state,there is no Javascript,but when it's running,there are lots of javascript code that are created by UI component. The main purposes for doing so: enhance development efficiency,reduce maintain cost ,and make it fit into standard JSF lifecycle.

So browser is still busy,but the developer becomes much more relaxing.

'这种思想本质上是把浏览器看作21世纪的字符终端，完全忽略和闲置了目前运行浏览器pc的强大计算功能.' is not true;


4、将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操纵语言。

As 'fangshun' said: '...,server端框架怎么去集成它们才对，多考虑server端如何更好的集成client技术要胜过让client端去替代本不属于它们的功能范围的事情，这要进步多。'

Put it in another way, JSF(or other server page solution) provides a full 'framework' for presentation layer,html and javascript should be part of it. Without a 'framework', the system will tend to be more difficult to change and maintain.

至于RIA(javaFx or Flex)，我认为它是侧重多媒体表现的“全功能UI Layer"的等价物，它的发展前景取决于厂商对它的定位：如果你认同RIA，就没有理由不认同“全功能UI Layer"的思路。

RIA is targeted to provide a full user interface solution. SAP has already integrated Flex in their NetWeaver platform as a front end solution. so RIA is not '侧重多媒体表现' at all.

Running within a local container,RIA uses declarative style lanaguage, which is beatiful and born for user interface.

Comparing with them,you will find that browser plus javascript are not good enough.if “全功能UI Layer" is based on browser and javascript,I still doubt that it will be a good solution.

87 楼 fangshun 2008-04-22  

  仔细看并分析fins的这份观点，有这些方面：
  1.jsf基于桌面UI模式的思路，很不适合B/S。
  2.基于这种UI模式生产了很多展现层方面的框架，ajax方面也有，感觉jsf的手伸的太长了，在很多简单的问题上反而变得复杂，麻烦。
  3.jsf的UI是jsf机制紧密耦合的一部分，很难灵活支配。
  4.B/S就应该把UI和系统分割，中间由数据维系关系
  5.ext等这种纯js编写的框架在各方面的优势要优于基于jsf-ajax UI模式的框架

  对于以上观点我给你的一些建议：
  这些建议也只是你愿意使用jsf作为你的技术框架的一部分才有效。
  第一点：B/S模式长期走的路线都是通过展现层分离的模式来处理应用。而jsf的六个阶段：恢复视图，值请求，验证，更新模型，调用应用，渲染。虽然通过视图的状态化（恢复视图，保存视图），让应用更像一个UI，但是运行机制中渲染和其他几个阶段是完全不同的两方面，例如：一次提交页面请求后，系统整个生命周期触发了两次request，到了渲染阶段时，上一个request已经消失，触发了一个新的request进行渲染，上个request的请求数据基本都在值请求阶段保存在了组件当中，供新的request渲染使用。从这里可以看出其实jsf也是将系统对于request的消费，以及通过request进行的渲染分成了两个部分，系统应用关注前几个阶段，渲染关注最后一个阶段，这也就是说，渲染阶段可以由第三方提供不同形式的渲染方式，比如ajax，只不过需要满足jsf规定的状态保存和恢复机制，以及覆写基础渲染接口。那么我也可以这样理解jsf只是仿照桌面UI思路，并非桌面UI思路，而且主要仿照的不是渲染机制，而主要是在事件监听方面的仿照，这样的目的在于数据传递的方式细粒度，并且可以传递细粒度的执行命令。所以本质上都是通过框架维系B/S两端的交互，却可以为开发模型提供一个统一的开发模式，而不需要通过诸如硬性分层，对页面和server进行硬性分工，再通过诸如xml等数据载体作为纽带，非得让开发者看的见一切机制，这就是为开发者在两端交互上套上输入输出的模式。
  你所说的jsf不适合B/S我认为更多的是jsf为开发者建立的开发方式不适合，而不是jsf机制不适合。但是如果这种开发模式不适合，那么也就是认为OO的开发方式维系两端交互不适合，那我也没办法，具体情况具体对待了！

  第二点：我一直都不赞成企业应用过分的炒作ajax，jsf加入ajax框架，其实这才是商业化的推动。而对于一个简单的js应用，其实使用后台一个简单的servlet就可以处理了，而jsf却要那么多复杂步骤，来完成一个同样作用的事情。赞同者认为增强复用，简化使用。批评者认为不灵活，制作组件麻烦。其实这就是组件化优劣之处，只不过对于client技术深度侵入业务应用还不是很成熟的情况下，却要将组件安置到前端，所以这个问题更加明显。也有人回帖说client技术是抢了server端技术的饭碗，我认为是很肤浅的看法，client端如果能OO化，带了高级的企业特性，那么甚至server端摆个数据库就可以了，十年前人们就应该想到了，为什么还要傻傻的转移到Server端技术呢。因为很多事情你没有想到，并不代表它不存在，就像j2ee核心技术很多都在很好的运行而你确不用关注。你关注的更多的是模型的设计与建立上，如果模型对象要是放在client端我才觉得有些奇怪，干脆吧应用服务器的底层都放在client吧，jdbc也用js来实现一套。这样使用起来才方便。到底看谁比谁复杂！
 
  第三点：jsf的UI机制是分离的，我不说了，你最好再看看jsf的实现机制。UI框架实现的那么多就是证明，你见过由几家公司实现了基于struts的ajax扩展框架（从另个方面讲，根本不用实现，基本很简单）
 
  第四点：很多架构师都是披着羊皮的狼，那么深沉的角色居然前端玩开ajax，感觉好前卫啊！ajax有一种用法很邪恶，就是作为数据的输入输出机制，使用某种载体（例如xml）成为一体的流水线，让两边的工人明白对方想要什么，就放什么。不用OO，只要尽快看到东西，跨时代进入工厂化，不求产品质量，禁止业务变动，只要分工明确，一切留待维护。大量的程序员一端用js美化调试，一端装配着持久层需要的东西，看似很自动，很流程，却搞不清楚软件耦合处需要分割后通过胶合剂粘合;需求变动后不再重新构建和迭代模型结构，确不得不重新换了一条生产线；搞不清楚用UML画什么图形，只要prototype和数据库字段对应就ok。

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

86 楼 leebai 2008-04-22  

to fxy1949 :

正如我前面提到的，不理解fins的人大多是思想被“server pages”禁锢者，总认为浏览器只能负责 html render，其他一切都应该在服务器上完成，就如IT业早期的主机－字符终端模式。这种思想本质上是把浏览器看作21世纪的字符终端，完全忽略和闲置了目前运行浏览器pc的强大计算功能。

1、Lightweight和Performance。在一个server和UI无关的模式下（下面称为“server business”，与“server pages”对应），server只是一个business logic server（只接受UI请求改变或查询系统的state），大致相当于砍掉了J2EE的Web层，Lightweight是肯定的了，至于Performance，除了节省处理
'UI layer'(NOT ONLY 'presentation layer') 的CPU开销，更重要的是大量节省服务器的出口带宽开销。

2、3、“server business”模式(SB)与“server pages”模式(SP)本质上是不同的,SP下的'presentation layer'概念并不适合SB模式。比如你列的这些功能：

  handle request：SB模式的browser不用处理http request，server 也不需要处理 full specification 的 http request，HTTP协议可以精简。

  validate input：SB下browser负责防止用户意外出错的validate ，server负责恶意攻击的validate,SP下此两者是不分的，并不合理。

  invoke business logic：SB下browser使用ajax通道调要server上的业务服务

  process result：SB下，server只返回结果数据，browser负责界面响应。

  save session state：SB下，browser每次请求也要提供session ID，server只保留server上用得着的 session state，其他 session state由browser自己负责。

  security authentication： SB下，server依据session ID判别用户，并处理安全验证（和SP相同）。这一点上，SB比SP更合理，既：访问授权验证应当属于业务层功能，而SP将此重要功能放在表现层，只能说明SP模式的"实现混杂"特性。


4、将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"的等价物，它的发展前景取决于厂商对它的定位：

http://leebai.iteye.com/blog/78357

如果你认同RIA，就没有理由不认同“全功能UI Layer"的思路。

－－－－－－－－－－

可惜你在London ，要是在北京我可以让你看看  it（完全基于浏览器的UI） might NOT be a mistake for any enterprise applications.[ by 7wxAop]。

85 楼 fxy1949 2008-04-21  

<p><br/>hehe, I think that 'fins' is not that great for having this idea, if you have a chance to read any JSRs in J2ee platform. </p>
<p> </p>
<p>1) Web server(including Application server) does much more work than you think. </p>
<p>       presentation layer(Servlet,JSP,JSF...) + business logic layer(EJB) + intergration layer(JDBC,JCA,WorkFlow,etc..)  </p>
<p> </p>
<p>Even we don't use any framework like JSF or struts, servlet has to be used for "接受数据-&gt;...-&gt;返回数据". Is it right? How much work do you think the server can save? </p>
<p> </p>
<p>The bottleneck of performance normally is not only in presentation layer. so "服务器端将非常<span style='color: #ff0000;'>Lightweight和Performance</span>，大厂商的J2EE服务器还有高性能硬件还会有几个项目需要？" is obviously not true. </p>
<p> </p>
<p>2) The key points of this argument are where to put 'presentation layer' and who runs 'presentation logic'. </p>
<p>   a. RIA (JavaFx , Flex, ...)                  client local JRE, client local Flash container           JavaFx, ActionScript</p>
<p>   b. Javascript framework(Ext,...)         Browser (javascript engine)                               Javascript</p>
<p>   c. Server side page(Jsp,JSF,...)          web server                                                    Java</p>
<p> </p>
<p>3) What does presentation layer do? Mostly, handle request,validate input, invoke business logic, process result, save session state, security authentication and so on.</p>
<p> </p>
<p>For me,it is very clear that browser is not a good candidate to do above "presentation layer work",browser should do its own job, a engine for executing html. </p>
<p> </p>
<p>4) I think, Ajax is only a transition technology, and is a complement to server side page pattern. It's very good using it to reduce interactions between browser and server. But if you want to use "Javascript framework" to implement the whole presentation layer, it might be a mistake for any enterprise applications. When RIA gets mature, maybe very soon, this pattern will first be beaten and,in contrast, server side page pattern will still survive. </p>
<p> </p>
<p>Why did I say that?  Because there will still be lots of applications that are suited to use browser as user interface , whereas the applications, which use "Javascript framework" pattern such as Ext and try to have a desktop-application-like user interface, will easily be replaced by the RIA technology(javaFx or Flex).</p>
<p> </p>
<p>Have a look at JavaFx Demo, you will find out more what will happend in the near future. </p>
<p><a href='http://jfx.wikia.com/wiki/Demos'>http://jfx.wikia.com/wiki/Demos</a></p>
<p> </p>
<p>  </p>
<p> </p>

84 楼 leebai 2008-04-21  

<p><span style='color: #ff0000;'>100％支持fins！！！</span> B端和S端彻底分开，分别有自己的框架，“UI层与系统其他层面的东西的唯一联系应该是"数据" ，UI层应该是在后台系统不变的情况下可切换的”，这种架构策略完全可行，而且实际代码上也比JSF/asp.net等“server page”变种优雅，本人已经在N个项目中实践过： <br/><br/><a href='http://www.xjawa.org/xjawa/kontent/10020.html' target='_blank'>http://www.xjawa.org/xjawa/kontent/10020.html</a> <br/><br/>我这个7wxAop框架（<span style='color: #ff0000;'>浏览器端7wx + 服务器端Aop</span>）就是该理论的实践，有个朋友喜欢用Ext做前端，他就把7wx替换成Ext， 照样跑得很好：</p>
<p><a href='http://www.deepsoft.com.cn/ext-aop/demo.html'>http://www.deepsoft.com.cn/ext-aop/demo.html</a><br/><br/><br/>那些不理解fins得同学，可能是没做过ajax开发，或者ajax用的比较少，或者思想已经被“server page ”方式禁锢。虽然本质上 jsf 还是“server page”，但确实比jsp、tag强很多；但是比起B/S完全分开得架构，jsf还是很丑陋。 我们公司有个项目组用得是SAP得WebDynpro，和jsf类似，要比jsf成熟，但实际开发起来也是很多问题。 <br/><br/>个人认为，<span style='color: #ff0000;'>fins设想的这种架构之所以未被普遍关注，是因为它损害了J2ee大厂商的商业利益，因此他们控制的主流IT媒体不愿宣传</span>。想想：如果Server只是用来接受数据-&gt;处理逻辑-&gt;返回数据，服务器端将非常<span style='color: #ff0000;'>Lightweight和Performance</span>，大厂商的J2EE服务器还有高性能硬件还会有几个项目需要？ <br/><br/><br/></p>
<p> </p>

83 楼 JJYAO 2008-04-21  

假如我们不考虑团队的技能，开发的效率，项目的维护，那么在web层，JSF能做的Ext + Struts都能做，而JSF不能做的(确切的说应该是扩展比较麻烦)，Ext + Struts也都能做

但假设在这样一个团队下，他们缺乏对JS的认知，或者只能写最简单的js。。事实上，很多大公司都是这样，绝大部分开发人员都缺乏对js的良好的掌握，但参与的却是非常大的项目，这些项目业务逻辑相对复杂，但页面展现可能并不需要太绚丽，个别页面另当别论。

考虑到广泛的开发效率和日后的维护成本，那么JSF的优势就来了，服务端的事件模型能够避免开发人员编写JS。而只需要编写服务端Java代码即可。如果对刷新的效果不满意，可以考虑整合Ajax，比如Icefaces等框架也可以拿来看看。

目前JSF的缺陷确实也存在，比如组件扩展确实成本高了点。facelets能力弱了点。期望能够有所发展～～

82 楼 triu 2008-04-21  

我下面的观点,有错吗? 错在哪呢? 其实我对自己也充满了怀疑

引用

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

一个B/S系统中 应该有两个框架 一个负责s端 一个负责b端
三个太多 ,一个太少, 两个刚刚好

能说什么呢？LZ的观点百分之百的支持。

如果需要依赖其他人开发的组件来达成快速、高效的话确实存在很大的问题，
为什么之前已经有很多人阐述过了，当然从纯粹满足客户需要，达成交易的
目的来说，这也没什么大问题，但LZ强调的好的框架设计并非单纯指效益好。

的确，唯一联系应该是"数据"，而基于XML+XSLT的框架就能实现MVC的完全分
离，每层的实现都可以被替换。

JAVA要干的事情就只是生成“数据”（XML），而UI的表现则可以用XSLT将生
成的数据（XML）转换成HTML、SVG或其它的XML（包括FLEX的MXML，是不是觉
得世界很美好呢！）。

81 楼 KKFC 2008-04-20  

Ajax真正放在刀刃上开发才多少年?它还年轻!不过相信是经得起考验的!

80 楼 hax 2008-04-20  

fxy1949 写道

1) JSF本来就是要实现Http Request统一的,规范的,以事件驱动方式的处理,Web Server和Browser之间传送http request(上传)和html(下传),不亲密点行吗?

这里你已经预先接受了jsf的模型。问题是fins质疑的正是这个。组件的、事件驱动的方式，为什么就一定要在server端做？纯b端的框架也能组件化，事件驱动。

fxy1949 写道

最重要的一点(这个要你好好学了JSF才能理解)是: 标准JSF UI组件达不到类似Ext的效果,灵活性(比如说频繁和服务端交互)的原因是: JSF UI组件的数据(MVC中的Model)都在Web Server Session中,要改变或获取只能靠Http request/response的方式; 而Ext之类组件的数据全部都先取到Browser中,或动态通过Ajax获得. 如果你说这个是JSF的不足,也对,但这也是JSF的核心观念之一,Web Server保存其数据(Component Tree),Browser负责Render Html(数据来自component tree ). 当然,现在有了RichFace之类的技术已经能弥补这个不足.

既然jsf的核心观念导致这样的结果，那么为什么不能质疑呢？

fxy1949 写道

看到这里,我已经快不能承受了. JSF和开发后台业务逻辑能搭的上吗? 连最基本的JSF原理都没有搞明白,在这里说JSF为什么不能做的更好?不觉的好笑吗?

jsf的支持者经常说：你们不懂jsf。比如我批评OperaMask的beforeRender的annotation的时候，就老是有人搬出jsf的生命周期来。但是他一直就不明白我批评的要害在哪里。

所以这里有两点。

第一，你是否预设了jsf的方式就是合理的呢？
第二，不懂jsf不等于不懂web开发。懂了jsf也不等于懂web开发。

fxy1949 写道

除了Myface,每一个Java开发人员都已经安装了以上其他内容,从做Java开发第一天开始,你觉的这个哪里不正常了?
这样做是挺好的,等你这头(B系统)调好了,准备和那一头(S系统)调试的时候,S系统不需要安装JDK,tomcat和服务端程序, controller, Json-libarary, something like that?

有人做了测试框架来脱离container测试servlet，看来真是吃饱了撑的。

fxy1949 写道

我以前和现在所在的公司都对jsf进行过考察,说实话 没有一个组件包是够用的
想满足我们验证项目的需求
我们用来验证JSF的项目是:
某电信BSS系统 ,
某公司人事管理系统,
某应用管理系统(类似websphere的web控制台)

想实现我们的需求,要从各个组件包里提取各种组件进行组合 而且还要自己扩展很多

我真的很好奇 那些说现在的jsf组件已经够用的人 做的是什么项目

你讲这些一点都没有说服力. 我就问一个简单的问题: 目前Java世界里, Web层开发技术到底是怎么分布的?

实践项目需求的考察如果没有说服力，那什么有说服力？你后面的判断和体会不过都是基于java程序员的视角，而不是基于实际项目的视角。

fxy1949 写道

以下是我的判断和体会:

目前,JSP还有一部分, Struts绝对是主流,因为比较成熟和被广泛使用,你去看到处招人都是精通SSH就知道了.

JSF是作为Struts的替代品而来的(Struts的作者是JSF规范的主要制定者),来的晚,但技术及理念上要比Struts先进(即使是Struts2还是摆脱不了form驱动,UI没有组件化的问题),所以,JSF比例会逐渐提高. Spring MVC大部分情况只是被用做Controller.

至于Ext,Dojo这一类基于Javascript的架构,会有一部分系统,比如那些有很高用户体验要求,操作复杂灵活的,但功能相对较少系统会采用. 但在大型的管理信息系统中采用的比例不会太高,这样的系统最终还是会选择开发效率高,易于维护,基于标准的技术,比如JSF, Struts.