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

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



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



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

所以这里有两点。

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



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



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

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

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


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

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

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

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

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

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

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

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

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服务器还有高性能硬件还会有几个项目需要？

 

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.

 

1) Web server(including Application server) does much more work than you think.

       presentation layer(Servlet,JSP,JSF...) + business logic layer(EJB) + intergration layer(JDBC,JCA,WorkFlow,etc..) 

 

Even we don't use any framework like JSF or struts, servlet has to be used for "接受数据->...->返回数据". Is it right? How much work do you think the server can save?

 

The bottleneck of performance normally is not only in presentation layer. so "服务器端将非常Lightweight和Performance，大厂商的J2EE服务器还有高性能硬件还会有几个项目需要？" is obviously not true. 

 

2) The key points of this argument are where to put 'presentation layer' and who runs 'presentation logic'.

   a. RIA (JavaFx , Flex, ...)                  client local JRE, client local Flash container           JavaFx, ActionScript

   b. Javascript framework(Ext,...)         Browser (javascript engine)                               Javascript

   c. Server side page(Jsp,JSF,...)          web server                                                    Java

 

3) What does presentation layer do? Mostly, handle request,validate input, invoke business logic, process result, save session state, security authentication and so on.

 

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. 

 

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.

 

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).

 

Have a look at JavaFx Demo, you will find out more what will happend in the near future.

http://jfx.wikia.com/wiki/Demos

 

  

 

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]。

  仔细看并分析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端去替代本不属于它们的功能范围的事情，这要进步多。

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.

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