DWR中的util.js

1. $("id") 大概等价于document.getElementById("id") 如果返回结果唯一的话返回该元素的值,不唯一则返回一个数组 .另外,如果单独使用util.js的话,可能在IE5以下的浏览器中无法正常使用,需要跟engine.js配合使用. 注意,这里得到的是一个对象,如果需要得到该对象的值的话,需要用innerHTML来取得.或者直接用DWRUtil.getValue("elementId")来取值. 
2. DWRUtil.toDescriptiveString("elementId",debugLevel),这是一个debug用的函数.第一个参数是元素的id,第二个参数是debug等级,可以是0,1,2.随着等级增加,输出信息也会增加.注意这个函数只是一个debug工具,不要对它抱有太大幻想. 
3. DWRUtil.getText("elementId"),返回一个select下拉菜单中的text值.仅适用于select类型的元素. 
4. DWRUtil.getValue("elementId"),返回一个元素的值,This method works for most HTML elements including selects (where the option with a matching value and not text is selected), input elements (including textareas) divs and spans 
5. DWRUtil.getValues({ div:null,
     textarea:null,
     select:null,
     text:null,
     password:null,
     formbutton:null,
     button:null
   }),返回一个对象包含这些元素的值,暂时不知道做什么用的. 
6. DWRUtil.onReturn(event, submitFunction) 定义在输入框中按回车的响应,防止执行submit. 
7. DWRUtil.addOptions() 一个重要的方法

等不及dwr2.0了。

    精巧的设计使DWR很容易被java开发人员接受；对传统web程序的无侵害性让它被引入更多的项目。与服务器端通信，DWR很有代表性，并很好的隐藏的xmlhttp对象，也基本可以满足我们要求。如果我们想抛弃传统的webwork/spring mvc等MVC框架，全部数据由DWR来实现的话，也有一定风险。没办法，只能挖掘DWR深层次的应用了。

一、业务层设计
   为了讨好传统的，用户量惊人的传统web应用。可能更准确的说是webwork/jsf为了和火热的AJAX套上关系，主动和dwr联系。dwr可以与Struts/JSF/PageFlow....集成。webwork最先干这个事，效果不好，用户根本不满足那一点点ajax应用。我认为与DWR的服务器端业务层最合适的是spring.也就是DWR的creator最好的是spring IOC框架.
    前段时间考虑,想在service层前面再有一外观层,因为dwr/ajax在浏览器端可能有很多细粒度的方法,以防破坏service层OO特性.(太教条了). 我们设计service层时,完全可以考虑,我们正在为DWR设计服务层,该注意的都应该注意.例如方法不能重载,不能用javascript关键字delete......
    设计要点:
         细粒度方法,粒度划分由浏览器业务决定.void updateName(id,name);  void updateUser(user);???
         方法的参数能用基本类型就用基本类型,可能性能会好点???
         避免方法重载
         关键字
         //todo
二、关于PO/VO....
     如果你用hibernate,如果把PO让dwr的HibernateBeanConverter处理,可以看 http://getahead.ltd.uk/dwr... . 
好象也有问题,尤其是hibernate3属性的lazyload.

     User.getRoles();
     roles.getUsers();
     logic.getUser();
     logic.getUserList();
     logic.getRolesList();
     ........

好象VO/DTO又有出头之日了.

另外还有一个问题.

logic.java
   User logic.find(int id);
   logic.save(User user);
action.java
   User user=logic.find(id);
   user.setName("");
   .....
   ....
    logic.save(user);

如果在ajax应用中,我相信会有logic.updateProper();这些细粒度方法,如果还象以前那样,那AJAX还有什么意思.

我现在意见是AJAX为主的应用中放弃hibernate,用spring template,不考虑OO.
毕竟不是所有的应用都适合AJAX为主.

   ajax portal
    http://my.msn.com
   Window对象
    改变它的位置
    填加连接
    ......
这些细粒度方法.OO不见得有多合适.

三、DWR服务器端扩展
1 、htmlConverter
  DWR最让人称道的是java方法可以由javascript调用,并把java对象和"json"互换.如果一个特点特别亮的话,那它肯定会有更大的不足.
    ajax可能传递  xml/json/html片段等.这里我觉得json基本可以替代xml,但html片段,dwr几乎没有支持,虽然可以由json包含html片段,但注意,这个html有java生成.html片段我任何还是很有必要的.
     如何生成这些html?由java实现?freemarker?htmlConverter?如何简单配置?值得考虑一下!
2、如果简化converter
    dwr提供的converter功能已经很不错了,但是扩展.编写自己类型的converter还是很麻烦.
    现在服务器端生成javascript也挺热闹,虽然偶不是很感兴趣,但如果dwr能把converter弄简单一些,包括配置,扩展,所见既所得.那就完美了.
    另外对于java反射感觉不爽,如果在正式运行环境下,把具体对象bean/object converter重写一下也是方便的.
四、客户端开发
    通过服务器生成javascript,与service函数对应.方便确实方便,但这也成了众多人的批判点.其实这些js不下载,dwr也可以运行的很好.
    其实dwr的这个封装没有必要,限制的dwr的开发.比如偶想在客户端做个cache,nnd,函数类型,不爽.编写无聊的,可能层次很深的callback函数.让代码很乱.
     另外dwr能称为ajax framework真有些牵强,如果不是j2ee程序员喜欢赶时髦,唉,这帮不知疲倦的人啊.
主要是客户端代码太弱,还须努力.
      这部分我已经做了点点工作,过几天show一下.
五、后续努力
   dwr如此优秀,我们应用的却不是很好,只能当成一个方便的数据存取框架.
   如果在浏览器角度,我们把服务器当成数据库的话,dwr做的不错.但这些json数据如何与dojo/yui/qooxdoo 优秀试图框架结合,需要大家努力.




这几天准备试着基于dwr开发一客户端MVC实现.
有什么建议欢迎讨论.