2

最近、多くの gwt リクエスト ファクトリの例を見てきましたが、まだ全体像を見つけることができません。

GWT リクエスト ファクトリのスイート スポットは CRUD (作成/読み取り/更新/削除) です。そうは言っても：

  1. 「更新」の場合でも、EntityProxyChange (イベント) の発生の責任者が誰であるかは明確ではありません。

クライアント側のリクエストファクトリが「見た」EntityProxyのローカルキャッシュを保持していることをどこかで読んだ（どこを忘れたか）、それが新しいものを「見た」場合は、EntityProxyChange（イベント）を起動します

つまり、私の「updatePerson()」メソッドが (新しく更新された) PersonProxy を返す場合、ローカル クライアント側のリクエスト ファクトリ インフラストラクチャは、この新しく更新された人を (つまり、更新された versionId によって) 「見る」ことを意味しますか?自動的に EntityProxyChange (イベント) を起動しますか?

  1. 「削除」の場合、リクエスト コンテキストで「deletePerson()」という関数を作成するとします。リクエストがサーバーに到着する方法を理解しており、たとえば SQL DELETE を実行してエンティティを削除しますが、 WriteOperation=DELETE を使用して EntityProxyChange (イベント) を発生させる責任がありますか? これらのイベントはサーバー側で発生しますか? クライアント側？

listwidget の例 ( http://code.google.com/p/listwidget ) を見てきましたが、「itemlist」の削除では、全体のブルート フォース リフレッシュを実行するだけで「ごまかす」ようなものです。リスト (ただし、その詳細は必ずしも listwidget が最初に説明しようとしているものではないことは理解しています); WriteOperation.DELETE イベントをリッスンし、そのエンティティだけを ListDataProvider から削除する EntityProxyChange (Event) ハンドラーが表示されることを期待していました。

ServiceLayer/ServiceLayerDecorator.isLive() はこれに影響しますか?

4

1 に答える 1

1

http://code.google.com/p/google-web-toolkit/wiki/RequestFactoryMovingParts#Flowを参照してください

クライアント側はキャッシュを保持せず（1年前の初期のイテレーションではおそらくそうでしたが、マイルストーン以外のリリースではそうではありませんでした）、サーバー側はキャッシュを「起動」する責任があります。イベント（JSON応答ペイロードに表示されます）。

上記のwikiページに次のように記載されている場合：

取得できなくなったエンティティ..。

それが実際に意味するのは、isLiveが返されたことfalseであり、isLiveの実装はデフォルトgetでIDによってを実行し、null以外の結果をチェックします。

于 2011-08-18T14:28:14.797 に答える