浏览 5763 次
|
锁定老帖子 主题：webwork2.2的AJAX功能讨论
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2005-12-11
今天早上在网络上无意看到满江红blog上的这么一篇文章，说出了很大一部分web 开发人员的困惑。
这里存在的问题，我觉得有一点是可以作为讨论的前提加以明确的。 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我也正在关注。。。。。 
|
| 返回顶楼 | |
