论坛首页 Web前端技术论坛

传统Web框架 PK AJAX -来自BJUG邮件列表的讨论

浏览 24531 次
该帖已经被评为精华帖
作者 正文
   发表时间:2006-02-20  
dlee 写道
有区别啊,用户事件在哪里处理,采用异步方式还是同步方式发送请求,两方面都有区别。如果事件能够直接在客户端响应,并且不打断用户的工作流程(不必忍受几秒钟的等待),不是会更好?
不必要的延迟对于软件的可用性和用户体验的影响可大了。
0 请登录后投票
   发表时间:2006-02-20  
zj 写道
所需的数据完全在客户端的情况下, 当然应该尽量在js中处理. 如果是需要服务器端提供数据, 则局部html片断在服务器端生成还是在客户端生成并没有什么用户体验上的区别.
另外, 无论什么界面模板方案, 能够提供一种再抽象机制才是重要的, 例如backbase的bxml, 我们的tpl模板方案
0 请登录后投票
   发表时间:2006-02-20  
dlee 写道
zj说到:
所需的数据完全在客户端的情况下, 当然应该尽量在js中处理. 如果是需要服务器端提供数据, 则局部html片断在服务器端生成还是在客户端生成并没有什么用户体验上的区别.

回答:
可以在客户端实现某种服务器端领域模型的缓存机制,这样可以获得更加灵敏的响应。但是随之而来的是客户端领域模型和服务器端领域模型之间的同步。Ajax in Action提供了一些这方面的代码。
在服务器端组装html片断就是以内容为中心的应用,只是Ajax应用的一种。它的问题主要是:
由于浏览器布局盒模型的限制,这段html必须放在某个矩形容器中,因此它所能更新的内容限于屏幕上某些固定的矩形区域。

而仅仅将数据(XML、JSON或者其他格式)传递给客户端,则可以完全避免这个限制。

zj说到:
另外, 无论什么界面模板方案, 能够提供一种再抽象机制才是重要的, 例如backbase的bxml, 我们的tpl模板方案

回答:
基于Ajax的组件库可以看作这一层抽象,dojo开了一个很好的头。XUL也可以看作这一层次的抽象。
从大的架构来看Ajax/XUL/Flash是很相似的。
0 请登录后投票
   发表时间:2006-02-20  
zj 写道
dlee说到:
在服务器端组装html片断就是以内容为中心的应用

    ,只是Ajax应用的一种。它的问题主要是:
    由于浏览器布局盒模型的限制,这段html必须放在某个矩形容器中,因此它所能更新的内容限于屏幕上某些固定的矩形区域。


结合类似于rico的引擎机制,  更新的区域并不必然限制在矩形容器中, 当然服务器端生成html片断对于细粒度界面元素的控制肯定不如js, 但是在目前的商业应用环境中, 我并不认为适当放大粒度会影响到效率问题. 就如同ORM中更新对象时我们可能是同时更新所有字段,而不一定要使用dynamic-update机制来准确控制到底是哪些字段需要更新.

dlee说到:
基于Ajax的组件库可以看作这一层抽象,dojo开了一个很好的

    头。XUL也可以看作这一层次的抽象。


dojo将多个既定组件封装成一个新的组件很方便吗, 我还没有发现
0 请登录后投票
   发表时间:2006-02-20  
dlee 写道
zj 说到:
结合类似于rico的引擎机制,  更新的区域并不必然限制在矩形容器中,
直接设置innerHTML,更新的区域就是在一些矩形容器中,即使这个矩形容器是一个很小的div。

zj 说到:
但是在目前的商业应用环境中, 我并不认为适当放大粒度会影响到效率问题.
我并没有跟你争论这个问题,刚才我们争论的核心问题是对于交互设计有没有影响,你认为完全没有影响,我认为还是有一些影响的(就是说存在一些局限)。不要拖离开我们刚才争论的主题。又扯到ORM上,我看不出他们的关系有多大。我们不是在讨论一个交互设计的问题吗?是否需要分离一点关注点?

一些对于交互性要求非常高的应用,采用以内容为中心的方式是很难建造的。
下面这个问题就算你说的对,你也没有办法证明模板必须要在服务器端组装。XUL可以满足你们的要求吗?
0 请登录后投票
   发表时间:2006-02-20  
zj 写道
提到ORM只是就粗粒度更新的效率问题做个类比而已, ORM当然与ajax是完全无关的.

如果同时更新多个分散但是关联的界面元素, 一种方式是直接更新它们的container box, 另一种方式是通过更多的js控制来完成. 这两种方式我们都使用, 只是以第一种为主而已. 我不认为强制一种完全的js中间层是很好的选择.

我并不执着于模板非要在服务器端组装, 如果界面支持xul, 我是非常乐于使用的. 一种前台xml模板机制与我们的后台模板机制可以更好的配合.
0 请登录后投票
   发表时间:2006-02-20  
讨论到这里已经开始跑题了,我总结一下我的观点,把讨论拉回来:

这个主题本意是要讨论,在AJAX时代,当我们做一个带有AJAX特征的web项目的时候,Java Web框架还有价值吗?我们是应该抛却掉Java Web框架吗?Java Web框架和AJAX框架是竞争的关系吗?

首先要明确一点,就是我们包括我在内,都是拥护AJAX的,也相信AJAX应用代表了更好的用户体验。

然后,在AJAX项目中,还有没有Java Web框架的地位?是不是应该抛弃掉Web框架这个问题上,观点有比较大分歧:

在我看来,AJAX有两种形态,一种是web request,大部分情况都会采用这种方式;另一种是web remoting,有些情况下必须使用这种方式。

当使用web remoting的情况下,是JS通过Gateway(Servlet)来调用spring的bean,返回数据到浏览器,由JS来render数据,在这种应用方式下,确实完全不需要Java Web框架。值得注意的一点是:这种调用方式在服务器端实际上需要提供一些基础设施来解决诸如权限控制,DTO转换,数据校验,异常处理等等问题,而且也需要有一些设计模式来指导这种情况下的应用(我计划在这方面做一些工作)。

当使用web request的情况下,是JS通过URL地址取一段HTML回来,然后在浏览器组装页面,这个URL既可以是静态页面,更可以是"xxx.action",也就是由服务器端Web框架来生成所需要render的HTML。在这种情况下,Web框架和传统用法稍有不同的地方在于,生成的HTML不是整个页面的HTML,而是局部HTML,也可以说对Web框架的使用颗粒度更细。在web request的情况下,Java Web框架不但是必要的,而且是非常重要的一环,因为它实际承担了所有的控制工作和View工作,而浏览器承担的只是组装页面这一简单任务。

web request和web remoting这两种方式在一个典型的Web项目中可能会都被用到,当然哪种方式用得更多,取决于问题的解决域。

总之,在比较普遍的web request应用中,Java Web框架并没有被抛弃,而是和AJAX框架很好的整合在一起共同发挥作用。因此,我不认同AJAX框架会淘汰Java Web框架的观点。

近期我和一个朋友准备开发一个网站型应用,到时候我们会把代码开源出来,那个时候可以请大家来评判一下我们是如何把Java Web框架和AJAX框架进行良好整合的。
0 请登录后投票
   发表时间:2006-02-20  
zj 写道
在我看来, webremoting 与webrequest并没有什么区别. web request之后只要返回一个json视图即可完成web remoting 调用
0 请登录后投票
   发表时间:2006-02-20  
dlee 写道
to zj:
看来我们逐渐达成一些共识了。说到XUL,同样有两种,一种是运行于Firefox/Mozilla浏览器中的XUL,完全使用XML描述整个界面布局。还有一种广义上的XUL,就是类似于XUL,使用XML来描述界面某个局部的布局,通过JS开发的Render引擎解释为HTML片断,甚至还可以自动生成CSS。
这种广义上的XUL开发方式已经有了好几种。在JavaEye上面jackyz曾经介绍过,他还曾经详细给我解释过这种广义的XUL,并且我们认为这类开发方式也属于Ajax技术体系的一部分(可以运行于大多数主流浏览器中,使用JS来开发)。

实际上Ajax技术体系的外延目前在迅速扩大,Firefox所支持的native的SVG、E4X,Firefox/Opera所支持的Canvas,还有他们搞的那个WhatWG的Web Application 1.0的标准,这些技术都可以算做Ajax技术体系的内容。

确实,对于我们所习惯的一类传统的Web应用,以内容为中心的方法基本上够用了。但是如果我们仅仅把Ajax的可能性局限在这些领域,那么我们就短视了。我们思考问题还是应该有点前瞻性,不要完全被现在的技术局限所束缚。当然我的意思也不是天马行空。在我看来,Ajax领域是今年比较引人瞩目的一个技术领域,我们都应该对这个领域保持足够的开放度。
0 请登录后投票
   发表时间:2006-02-20  
dlee 写道
为什么Ajax在Struts、WebWork或者JSF这些架构中只能起到有限的作用,无法做到Google Maps一类应用那么酷那么眩?甚至现有的一些解决方案中将Ajax削足适履,硬塞进一套原有的架构中?例如早先所贴出的那个所谓完美的JSF-Ajax集成方案。Ajax本身和这些架构是存在一些内在的冲突的。任何一种架构或框架在设计之初,对于其所运行的环境,所要解决的问题都存在着一些基本的假设,还包括有大量的隐喻。WebWork在设计之初,并没有充分思考过如何支持Ajax/Flash这样一类RIA应用,特别是根本没有思考过异步请求会带来的好处。Ruby on Rails的好处是它是后来者,在发展之初,就出现了Ajax这种技术。WebWork有可能为Ajax的需求而重新锻造吗?可能性非常小。JSF同样有没有可能。所以还是各走各的路好了,强扭的瓜不甜,一定要把它们组合在一起,很多情况只能得到一个不尽理想的结果。

传统的Web框架所基于的环境,以及Ajax所要解决的问题,在Ajax in Action这本书中有详尽和令人信服的解释。这本书确实是一本非常棒的书,可以说代表了目前Ajax技术发展的水平(目前外版的Ajax著作还没有看到能超越这本书的)。
0 请登录后投票
论坛首页 Web前端技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics