2011-07-23 129 views

回答

3

另一種選擇是創建一個替代com.google.web.bindery.requestfactory.shared.RequestTransport類型,而不是使用DefaultRequestTransport。這一點(以及BobV方法的一個缺點)是,你不會知道什麼時候在服務器上的請求中殺死它,所以它可能已經運行了你的一些方法 - 你不會從它們中獲得任何反饋,你會停止傳出的請求。

我懷疑這就是爲什麼RF沒有這個功能,就像RPC一樣。請考慮甚至RPC通過或RequestBuilder的情況 - 那些通知服務器他們已經改變了主意,並且不運行請求?我的理解是,他們不 - 他們早期關閉的唯一方法是當他們嘗試讀取/寫入響應,並且由於連接已關閉而發生tcp錯誤。 (這可能是我錯了,另一個線程留意tcp連接的狀態,並調用thread.stop(Throwable),但已停止使用quite a while。)

一個想法是將消息發送到服務器,告訴它從同一會話中刪除其他請求 - 但這需要積極參與您的服務器代碼,但可能在ServiceLayerDecorator子類型中通用,可能至少在invoke,loadDomainObject(s)getSetter等等中。這很明顯是要求GWT爲你構建它,雖然...

4

調用fire()方法後無法取消請求。考慮構建定製Receiver基類如下述:

public abstract class CancelableReceiver<V> extends Receiver<V> { 
    private boolean canceled; 

    public void cancel() { 
    canceled = true; 
    } 

    @Override 
    public final void onSuccess(V response) { 
    if (!canceled) { 
     doOnSuccess(response); 
    } 
    } 

    protected abstract void doOnSuccess(V response); 
} 

的圖案可以重複在Receiver類型的其他方法。

+0

正如你所指出的,感謝,並不真正解決問題,因爲服務器仍然認爲它是繼續處理請求。 我在這裏創建了一個問題:http://code.google.com/p/google-web-toolkit/issues/detail?id=6610 – fabiangebert