锁定老帖子 主题:使用Dwr渲染table
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2007-06-13
第一次尝试使用Dwr来开发ajax,js也没有想像那么难写。有一个感觉,Dwr的设计很像axis1,连显示服务的风格都很像,呵呵,是不是作者使借签了axis的设计思想啊 1、设计目标 避免查询的时候刷新页面的全部区域,只用改变查询结果显示的部分 2、web.xml中部署Dwr xml 代码
3、Dwr.xml部置 xml 代码
客户端调用的是Spring代理的javabean,所有creator要使用spring,如果是普通javabean,则使用new就可以了。javascript属性指定了客户端的js名字 参数,spring中是使用beanName来获取spring中的bean。如果是普通的javabean,则使用class,值为java类 需要注意的是convert,如果传递的对象不是基本类型,则需要配置javabean,并指定相关的属性。如配置文件中的id,name 需要说明的是,fileItemManager的方法是一返回一个java.util.List对象 4、页面中插入js js 代码
其中${ctx}/dwr/inteface/FileManger.js的名字要和前面dwr.xml中javscript属性的值一致。 5、编写JS代码 js 代码
在query查询函数中,调用FileManager得到查询结果,和普通的java方法调用一样。但要注意,第二个参数传入的是回调函数,用于处理响应值,注要是指如何渲染。 在回调函数中第一个要定义的就是cellfuns,它代表每一列值的表现形势,有多少function,就有多少列。每一个单元格的内容可以是简单的值,也可以是一个包含了其它HTML标签的Document. 接下来就是具体的处理参数值的过程。DwrUtil是DWR框架提供的一个非常有用的功具函数,包含通常的是JS处理功能,如动态添加select的option等,可以单独使用。 DwrUtil.addRows('fileResultBody',data,cellfuncs,...)是用来实际插入数据的,第一个插入是要插入数据所在的表格的ID,最好是tbody的ID,data为值,cellfuncs前面已经介绍了,最后两个参数是用于创建<tr>和<td>属性的
声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2007-06-14
dwr确实很简单易用,尤其提供了Spring的支持之后。
|
|
返回顶楼 | |
发表时间:2007-06-14
不过不是有一个小问题,整个系统是基于Struts+Spring+iBatis开发的
我的安全域配置是配置是根据URL+action(action的方法名)+用户身份实现的。使用dwr后,就变成直接调用事业层的方式了,安全校验就失效了,不知知道在dwr中有什么方法,可以让其调用action来完成数据获取 |
|
返回顶楼 | |
发表时间:2007-06-15
dwr同样有struts的creator
|
|
返回顶楼 | |
发表时间:2007-06-18
DWR适用于类似RPC方式的设计,如果有比较复杂的UI,仅使用DWR有很多不利的地方,HTML的表现层不是那么容易处理的,特别是当你需要处理浏览器兼容性的时候更是麻烦。
安全性也是一个问题,如果使用DWR,因为DWR没有提供安全性的指南,实现起来基本依赖于使用者的经验和具体应用环境。 在大多数的web应用环境中,DWR并不是合适。反而是那些js库配合jsp或servlet(asp也可以)在服务器端组合完成数据和html表现更符合具有web开发经验的团队的基本常识和开发经验。现在有很多js的库Yahoo UI, prototype, dojo, 一般的都带有某种ajax.update方法,这才是web开发中快速实用的技巧。 |
|
返回顶楼 | |
发表时间:2007-06-21
我没有做过大型的开发。不过SteveGY提到的
那些js库配合jsp或servlet(asp也可以)在服务器端组合完成数据和html表现更符合具有web开发经验的团队的基本常识和开发经验 我想首先这就不符合MVC模式,页面的渲染和服务端代码混在一起,一是很难开发,二是更难维护。如果页面需要做出修改,那到底是UI的工作,还是programmer的事情呢。 |
|
返回顶楼 | |
发表时间:2007-07-12
卒子99 写道 我没有做过大型的开发。不过SteveGY提到的
那些js库配合jsp或servlet(asp也可以)在服务器端组合完成数据和html表现更符合具有web开发经验的团队的基本常识和开发经验 我想首先这就不符合MVC模式,页面的渲染和服务端代码混在一起,一是很难开发,二是更难维护。如果页面需要做出修改,那到底是UI的工作,还是programmer的事情呢。 服务端代码并不局限于处理页面渲染,可能包括业务逻辑,事务处理,安全管理以及数据持久化等操作。WEB瘦客户端先天不足限制页面渲染的能力,复杂的界面表现仍然需要服务端代码提供帮助。 ps: 过于严格的分工可能会造成沟通成本的上升,设计模式的滥用也会提高开发和维护的难度。 blogbin |
|
返回顶楼 | |
发表时间:2007-07-17
SteveGY 写道 DWR适用于类似RPC方式的设计,如果有比较复杂的UI,仅使用DWR有很多不利的地方,HTML的表现层不是那么容易处理的,特别是当你需要处理浏览器兼容性的时候更是麻烦。
安全性也是一个问题,如果使用DWR,因为DWR没有提供安全性的指南,实现起来基本依赖于使用者的经验和具体应用环境。 在大多数的web应用环境中,DWR并不是合适。反而是那些js库配合jsp或servlet(asp也可以)在服务器端组合完成数据和html表现更符合具有web开发经验的团队的基本常识和开发经验。现在有很多js的库Yahoo UI, prototype, dojo, 一般的都带有某种ajax.update方法,这才是web开发中快速实用的技巧。 dwr关注的中心是信息的传递,组装表现确实非其所长,就我的理解来说,将数据的传递与具体的表现组装方式分离是一种优美的方式,dwr简化了数据的包装与传递,在数据需求不变的情况下可以只将注意力集中于表现的变化。我们开发中一般使用dwr结合prototype或者jquery |
|
返回顶楼 | |
发表时间:2007-07-18
不知道大家是否遇到过DWR报找不到DWREngine错误的情况,当然是在那三个js文件都存在的情况下,好像和ie的设置有关,好像选中 使用http1.1 就可以,但是不是很有规律.
|
|
返回顶楼 | |
浏览 8301 次