1、java的方法避免用 java 和 javascript的關鍵字。 如 try()方法 或 delete()方法。
2、在你的java類中不要出現重載 avoid overloaded methods.
3、 在生產環境下，你可以把deprecated.js engine.js util.js 合并成一個，并放到web容器內，直接在htm,jsp中引用。 （對于java代碼轉換成的javascript代碼也可以這么做，免得每次生成javascript代碼浪費時間）
4、研究一下Bean Converters。POJOjava對象必須嚴格按照 getProperty() setProperty()定義。Bean Converters是按照 java對象的 get set方法工作的。DWR1.1加了Object Converters,是按private int property;這類屬性工作的。
<convert converter="bean" match="example.Fred"/>
<param name="exclude" value="property1, property2"/>
</convert>
當你這樣配置時，java對象轉化成的javascript對象不包括property1和property2。
<convert converter="bean" match="example.Fred"/>
<param name="include" value="property1, property2"/>
</convert>
反過來java對象轉化成的javascript對象直包括property1和property2。
5、<convert converter="collection" match="java.util.Collection"/>
<convert converter="map" match="java.util.Map"/>
這也是容易出問題的地方.
如
package example;
public class Person{
private String name;
get ... set
private List relationPerson;
public List setRelationPerson(List relationPerson){
this.relationPerson=relationPerson;
}
}
<convert converter="bean" match="example.Person"/>
</convert>
<signatures>
<![CDATA[
import java.util.Set;
import example.Person;

Person.setRelationPerson(List<Person>);
]]>
</signatures>

在jdk1.5泛型中有寫法區別


6、另外在Set,List等做為方法參數時也會出現混淆。返回集合類型不會出現問題，想想就知道了。
如 在Test類中有 public Set testBeanSetParam(Set test) 這個方法，客戶端得到的javascript方法可能是Test.testBeanSetParam(p0,callback);當我們 javascript調用這個方法時，鬼才知道怎么確定p0的類型,也不可能知道Set集合中該放什么類型的java對象，所以dwr的 special signatures syntax 確定這些集合和內容的類型
<signatures>
<![CDATA[
import java.util.Set;
import example.Test;

Test.testBeanSetParam(Set<TestBean>);
<!--Test.stringStringMapParam(Map<String, String>);-->
]]>
</signatures>
7、Creators
<allow>
<create creator="..." javascript="..." scope="...">
<param name="..." value="..."/>
<auth method="..." role="..."/>
<exclude method="..."/>
<include method="..."/>
</create>
...
</allow>
為了更少的暴露業務方法，最好配置include屬性。
dwr支持new ,script,struts....幾種集成方法，也支持static方法的調用，我覺得最好的是spring,其他感覺是處理遺留問題處理。
8、engine_js 作為dwr框架客戶端核心，主要完成xmlHttp或iframe的構造，我們沒必要關心它如何實現。有幾點創新的我們可以學習下。
Call Batching 我們可以把幾個客戶端請求一起放送到服務器端，減少了網絡交互，但要注意依存關系和他們處理的順序。
Call Ordering 同步異步調整。一般用默認的就好了。注意依存關系。
Remoting Hooks 鉤子，"small AOP"
依存關系解釋。 如果 request1() request2()兩個業務邏輯方法，request2方法需要用到request1方法從服務器端返回的結果。如果調用request2時，request1還沒處理或還沒請求。 下拉框連動可能有這個問題。
9、util.js propotype.js有些重復，這讓我很難受。只能改代碼了，可別壞了開元協議。
10、如果你的回調方法想加其他參數
var dataFromBrowser = ...;
var callbackProxy = function(dataFromServer) {
callbackFunc(dataFromServer, dataFromBrowser);
};
var callMetaData = { callback:callbackProxy };
Remote.method(params, callMetaData);
11、dwr1.1
1.1只能算一個bug消除版本，沒有什么大的功能調整。源代碼結構做了些調整。2.0有新的特征加入。

It has a far broader scope; the major new features are accessibility enhancements, and what now appears to be called 'Comet'. 在文檔中提到了“Comet”，估計與DWR2.0作者想法類似。

http://forum.javaeye.com/viewtopic.php?t=19089

樓主叫server push。

http://alex.dojotoolkit.org/?p=545 給正名了，叫 Comet