浏览 5783 次
锁定老帖子 主题:webwork2.2的AJAX功能讨论
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2005-12-11
这里存在的问题,我觉得有一点是可以作为讨论的前提加以明确的。 web开发现在基本分为:RIA和传统页面导航形式。RIA相对来说,实现难度大一些,因为它既有 传统页面导航形式的特征,又有各种复杂的界面交互以及近乎苛刻的用户交互体验在里面。 前者实现复杂,但是较容易符合以使用为中心的原则,而后一种实现简单,模式较为单一,但是 对于复杂的用户交互缺乏必要的支撑技术,很难实现用户复杂的交互需求。 那么,我们该如何决定项目该上哪一种形式的web app呢? http://www.javalobby.org/articles/ajax-ria-overview/ 里面提到了几个选择RIA的原则: Simple enough for HTML means that the UI has modest interactivity requirements. However, if any of the following features improves your UI, you should consider RIA technology: * Partial screen updates * Asynchronous communication * Server push * Widgets supporting direct manipulation * Multiple coordinated windows * Modal dialogs * Menus * Keyboard navigation 后面二条可以用DHTML/JS实现。 像满江红blog提到的:根据用户选择的客户ID来判断是否有足够的存款 这个逻辑已经涉及到RIA的应用了,对于它的大部分分析我还是赞同,不过似乎对于这点: 3,客户端基础设施难于与服务器端进行交互。xmlhttp以及web service可选,但是在企业应用中其低下效率可能会带来服务器的压力隐患, 降低性能和吞吐量。若excel方案,则同样面临着与服务器数据交互的难题。不管是xmlhttp方案还是application方案,都面临着抛弃 struts/webwork重新实现request/response dispatch的要求。 对于这点,我存在疑义。其实现有的webwork+dwr+dojo基本可以满足绝大部分RIA需求。简要针对上面提到的几个需求做一个分析: * Partial screen updates --〉webwork很好的支持,targetDiv = "your div". * Asynchronous communication-->WW对form的异步提交和响应作了很好的支持。具体的非form提交的异步 交互可以使用DWR来完成。比如上面提到的用户根据客户ID来判断存款是否充足的异步逻辑。 * Server push --〉DWR支持 * Widgets supporting direct manipulation 期盼DOJO等成熟的客户端组件出现吧 我基本上认为: WW2.2+DWR基本可以实现大部分的B/S结构RIA需求,不过他们的学习曲线比较高。 在具体的应用中,几乎全部的业务逻辑都可以通过后台代码来完成, 而前台的界面交互主要由JS来完成,这里有一个十分谨慎的讨论的禁区: JS可以完成一部分的业务逻辑吗? 比如相关输入项的计算规则?A+B+C*D = E, 这样的逻辑在前台完成似乎也不是什么难事。然而,会带来一个测试比较难,扩展比较 复杂的问题。打破了这个底线会给前后台一起粘合业务逻辑带来了潜在的隐患。 虽然在具体的项目中,这个地方的设计需要综合的考虑,很多都是相对的。在我们的项目中, 我们将这些计算规则统统放到了后台对应的领域模型身上。然后让DWR传输参数和调用 相应的逻辑,这里涉及到一个性能的问题。这里有一个度的问题,如果性能下降1-5% 可以带来架构上的优雅设计,我觉得是完全可以接受的。 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2006-01-12
如果不采用struts类似的mvc框架,直接在客户端用xmlhttp作web remote invoke来完成页面,也不是不可以的吧。虽然这不够优雅。
|
|
返回顶楼 | |
发表时间:2006-01-12
这篇文章主要是讨论AJAX,所以放在这里。再补上一个相关讨论:
Michael Chen 写道 下载回来了30几兆的安装包,然后java -jar webwork-2.2.jar
quickstart:showcase开始了showcase. 以下几个方面,让人无法忍受: 1 ui/example.jsp中的ww:date控件,我将format更改为%Y-%m-%d, 提交不正常。 2 ajax的校验,Firefox下面有时弹出错误 3 remoteForm, remoteDiv的演示做得实在很粗糙,点完后对ajax能够改善交互体验产生严重的信任危机。显然开发者本人对ajax的作用不太重视 4 然后我开启了另外一个应用shopping cart。这个应用基本不可用。当更新数量的时候报错,同时页面刷新。交互感觉不太好 我不得不重申我的观点:那个代表灵活、优雅的webwork已死。在web2.0/ajax的冲击下,我看到webwork想赶上这趟车,但是,不知道是什么原因,webwork2.2最大亮点之一ajax支持却做得这么差。作为一个完整的web框架产品,居然同时集成两种ajax产品,而两者在语言基础上存在较大不同(dwr有自己的js语法结构和加载机制)。这对于最终用户如何选择和使用?一个框架应该对外保持概念一致性以保证美感,webwork已经偏离了这个方向。 我的个人观点,对于传统的web应用,webwork提供的ajax新特性可以加快一些开发;但在新一代的web应用中完全是鸡肋。 Xiaogang Cao 写道 我觉得我就没必要用webwork了。
完全在客户端进行layout控制,用qooxdoo来做UI,ajax作为传输,服务器端只需要xwork了。 目前来说,Webwork的AJAX支持bug很多,功能也很少,只能说迈出了第一步而已,对用户有点帮助,但是帮助不大。不过坦白说,目前还没有哪个Web框架能够支持AJAX,Webwork算走在前面的了。另外现在的纯AJAX框架也只不过都提供了一些基础功能,用户仍然需要大量的写JS自己搞定很多效果,目前还处于一个探索的阶段,不能期望webwork站出来做killer,当然我对webwork AJAX支持也不满,主要不是功能上的,主要是bug太多。 前段时间我因为某个不可告人的目的下载了webwork1.4,这可是Richard Oberg亲手做的,看了以后很诧异,因为发现webwork1.4实在太简陋了,也难怪Rod Johnson当年会自己写Spring MVC,我相信,那时候如果webwork2.1就出来的话,Rod肯定会放弃自己写MVC了。要换了我,当时也肯定不会用webwork1.4。因此说webwork缺少了Richard,就没有了创新,我觉得是不对的。这一点比较一下两个版本就知道了。 Webwork集成的两种AJAX框架分别用来做不同的事情的,DWR是AJAX分布式调用的,dojo则是AHAH方式组装页面的,这两种方式并不冲突,是互补的关系。关于这一点,我最近BEA SHUG演讲探讨了这个问题: http://www.iteye.com/pages/viewpage.action?pageId=779 Webwork的AJAX支持对于一个Rich AJAX Web应用来说的确是鸡肋,但是对于一个只是希望少量采用AJAX改善交互的Web应用来说,则是一道不错的饭后甜点。 |
|
返回顶楼 | |
发表时间:2006-01-12
Michael Chen 写道 Hey, Robbin:
显然,按照java以及特别是java领域的开源的作法而言,同时集成两种代表不同功能方向的产品显然是没有任何问题的。但是,现在前提发生改变了:是js+java,而不是单纯的java. 单纯在java环境内,java语言为我们提供了一致性,而且jvm内部不需考虑太多的事情;但同时集成另外两种基础不同的javascript的时候,除了对network bandwidth可能造成的影响外,关键是对开发者造成了不一致性的影响。显然,dwr是做了验证的事情,谁说dwr又不能做remoteLink的事情呢?dojo做了AHAR的事情,但用它来做验证也可以。在集成的方面,很遗憾,webwork显然考虑不够细致。 另一个重要的需要考虑的是,一旦一个js被加入,作为前台应用的开发者,为了减少流量的影响,需要考虑这个js能够做尽可能多的事情,而不是为了满足某一个简单的功能。这个考虑,纯粹的java开发者是考虑不到的。因为要校验,所以加入dwr.js; 因为要remoteForm,所以加入dojo.js。开发者怎么办?dojo要学,dwr要学,对于开发者,可真不是一件轻松的活儿。 xiaogang, 呵呵,等qooxdoo 0.2 final之后我就考虑提供与buffalo集成的方案。 最后说一些建设性的想法。webwork提供的几个tag显然是经过考虑的,涵盖了对ajax的流行用法。只需要采用prototype+buffalo就可以实现ajax相关全部的tag了。但是这对开发者还是不一定够用,没关系,prototype提供了绝大多数常见操作;buffalo提供了稳定坚固的传输基础(广告,呵呵),保证浏览器加载的js不会被浪费。 |
|
返回顶楼 | |
发表时间:2006-01-12
robbin 写道 Michael Chen 写道 Hey, Robbin:
显然,按照java以及特别是java领域的开源的作法而言,同时集成两种代表不同功能方向的产品显然是没有任何问题的。但是,现在前提发生改变了:是js+java,而不是单纯的java. 单纯在java环境内,java语言为我们提供了一致性,而且jvm内部不需考虑太多的事情;但同时集成另外两种基础不同的javascript的时候,除了对network bandwidth可能造成的影响外,关键是对开发者造成了不一致性的影响。显然,dwr是做了验证的事情,谁说dwr又不能做remoteLink的事情呢?dojo做了AHAR的事情,但用它来做验证也可以。在集成的方面,很遗憾,webwork显然考虑不够细致。 另一个重要的需要考虑的是,一旦一个js被加入,作为前台应用的开发者,为了减少流量的影响,需要考虑这个js能够做尽可能多的事情,而不是为了满足某一个简单的功能。这个考虑,纯粹的java开发者是考虑不到的。因为要校验,所以加入dwr.js; 因为要remoteForm,所以加入dojo.js。开发者怎么办?dojo要学,dwr要学,对于开发者,可真不是一件轻松的活儿。 xiaogang, 呵呵,等qooxdoo 0.2 final之后我就考虑提供与buffalo集成的方案。 最后说一些建设性的想法。webwork提供的几个tag显然是经过考虑的,涵盖了对ajax的流行用法。只需要采用prototype+buffalo就可以实现ajax相关全部的tag了。但是这对开发者还是不一定够用,没关系,prototype提供了绝大多数常见操作;buffalo提供了稳定坚固的传输基础(广告,呵呵),保证浏览器加载的js不会被浪费。 对,webwork2.2对于AJAX的支持是一个鸡肋,而且它引入一些bug。你前面提到ajax关于验证的bug,这确实是一个失误,页面没有某个名字的inputField,而验证返回有这么名字的出错信息时,webwork的客户端脚本就会试图在一个不存在的节点上加入错误信息。 我们用它来试验了两个项目,开始有点振奋,后面慢慢感觉还是有很多不完善的地方。不过不广泛基于AJAX而仅仅部分用的话,用它确实还行。 qooxdoo我也正在关注。。。。。 |
|
返回顶楼 | |