0

クライアント側:

factory.find(proxyId).fire(new Receiver<P>()
{
    @Override
    public void onSuccess( P response )
    {
        proxy = response;
        ...
    }

    @Override
    public void onFailure( com.google.web.bindery.requestfactory.shared.ServerFailure error )
    {
        Window.alert( error.getMessage() );
    }
}

サーバー側では、以下のようなロケーターを使用します:

public class myLocator extends Locator<T, String>
{
    @Injector LocatorHook hook;

    @Override
    public T find( Class<? extends T> clazz, String id )
    {
        T result = ...;
        hook.run( result );
        return result;
    }

    ....
}

hook.run()メソッドがスローされる可能性RunTimeException("validation exception")があります。クライアント側で例外をキャッチすることを期待していますが、例外をonFailure()キャッチしましたが、メッセージは「内部サーバーエラー」であり、スローされた例外ではありませんhook.run(): 「検証例外」。

クライアントがサーバー側でスローした例外をキャッチできるようにするためのアイデアはありますか?

更新: トーマスが言ったように、データ ストアから新鮮なオブジェクトを検証するのは奇妙ですが、サービス メソッドの使用方法がわからない状況に遭遇しました: クライアントEntityProxyIdでオブジェクトをfactory.find( proxyId ).fire(...)取得し、データストアからエンティティを取得できます。しかし、エンティティはユーザーがアクセスするのに適していない可能性があります。この状況では、サーバー側で確認する必要がありますが、検証を行うのに適した場所が見つかりません。これに関するアイデアはありますか?

4

1 に答える 1

1

RequestFactoryは、ロケーターによって例外がスローされることを想定していません。例外はサービスメソッドによってのみスローされる必要がありReceiver、クライアント側の適切なもの（スローされたサービスメソッドにアタッチされているもの）に転送されます。

サービスメソッドの外部では、クライアントにルーティングされる唯一の例外はsであり、これはのメソッドReportableExceptionからのみスローできます。つまり、ロケーターからの例外をキャッチしてそれらをキャッチする独自のフックを作成できるということです。ServiceLocatorDecoratorreport()ServiceLocatorDecoratorreport()

そうは言っても、データストアから新鮮なオブジェクトを検証するのは奇妙に思えます。ServiceLocatorDecoratorオーバーライドを提供することをお勧めしますvalidate()（クライアントからの変更が適用された後にオブジェクトを検証します）。Receiverエラーは'sonConstraintViolationsでクライアントに戻り、フリーズが解除RequestContextされるため、プロキシをさらに編集してやり直すことができます。fire()

于 2013-02-05T10:41:45.423 に答える