2

拡張ライブラリ コンポーネントのリモート サービス ( xe:jsonRpcService) を使用しようとしています。こことここからいくつかのヒントを得ました。基本的に、RPC を使用してドキュメントを保存しようとしています。問題は、ドキュメントは保存されますが、XPage に存在するフィールドは保存されないことです。以下はサンプルの XPage コードです。

<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core" xmlns:xe="http://www.ibm.com/xsp/coreex">
    <xp:this.data>
        <xp:dominoDocument var="document1" formName="Test"></xp:dominoDocument>
    </xp:this.data>
    <xe:jsonRpcService id="jsonRpcService1" serviceName="service">
        <xe:this.methods>
            <xe:remoteMethod name="saveDoc">
                <xe:this.script><![CDATA[print(">> " + getComponent("inputText1").getValue());
document1.save();
return true;]]></xe:this.script>
            </xe:remoteMethod>
        </xe:this.methods>
    </xe:jsonRpcService>
    <xp:br></xp:br>
    <xp:inputText id="inputText1" defaultValue="testValue" value="#{document1.testField}"></xp:inputText>
    <xp:br></xp:br>
    <xp:button value="Save" id="button1">
        <xp:eventHandler event="onclick" submit="false">
            <xp:this.script><![CDATA[var deferred = service.saveDoc();
deferred.addCallback(
    function(result) {
        alert(result);
    }
);]]></xp:this.script>
        </xp:eventHandler>
    </xp:button>
</xp:view>

ここで行ったことはservice、現在のドキュメント ( ) を保存するリモート サービス ( )を作成したことですdocument1。ドキュメントは保存されますが、値は保存されませんinputText1。inputText1また、コンソールに表示される値を印刷しようとすると、保存されません。

これは正しい方法ですか？それとも、ここで何かが欠けていますか。xe:jsonRpcServiceまた、 の使用が正当化されるシナリオにはどのようなものがありますか?

4

1 に答える 1

12

このタイプの操作で JSON-RPC の使用を避けるには、(少なくとも) 2 つの理由があります。

  1. このサービス コンポーネントは可能な限り軽量になるように設計されているため、XPages の標準イベント (HTML フォーム全体を自動的にポストする) とは異なり、送信のみを行います。メソッドを呼び出すために必要なデータを受け取り、メソッドによって返されたデータのみを受け取ります。あなたの例では、メソッドは引数を取らないため、文字通り、サーバーが呼び出すメソッドを知るのに十分な情報を送信しています。同様に、ブール値を返すだけなので、文字通りそれだけが返されます。ブラウザの開発ツール (つまり、Firebug または Chrome の組み込みツール) を使用してネットワーク トラフィックを検査すると、これが各方向に送信される JSON パケットに反映されていることがわかります。その結果、サーバーは明示的に「伝え」ないことを「認識」しません。呼び出しているメソッドに明示的に関連していないものを投稿していないため、通常のイベントよりも高速です...実行するために必要です。
  2. コンポーネントがパフォーマンスに重点を置いていることのもう 1 つの副作用は、JSF ライフサイクルの最後にあるコンポーネント ツリーのシリアル化をスキップすることです。現在のページをメモリに保存している場合は問題ありませんが、デフォルトのオプション (すべてのページをディスクに保存する) を使用している場合、サーバーはページに加えられた変更を「忘れて」しまいます。メソッド呼び出し中。ビューのルートにその状態をシリアライズするように直接指示することで、ケースバイケースでこの動作を明示的にオーバーライドできますが、これを手動で行う必要があることを忘れがちです。これは通常、インディケーション サーバーが表示されたときに多くの不満を引き起こします。 - 想定どおりに動作しているという側面がありますが、実際の Web ページにはそれが反映されていません。RPC メソッドを「読み取り専用」操作として扱うのが最善です。

私のアドバイスは、JSON-RPC を「SOAP から愚かなものを差し引いたもの」と考えることです。より丁寧に言えば、概念的には Web サービスと同じですが、Web サービスの複雑さはまったくありません。そのため、これらのタイプのサービスは、現在のページの状態に明示的に結び付けられることなく、現在のページのコンテキスト内で役立つデータ操作に最適です。

JSON-RPC メソッドが役立つ操作の例を次に示します。

  • 新しいアカウント用に選択しているユーザー名が既に使用されているかどうかを新しいユーザーに通知します。フォーム全体を送信する標準のキーアップ イベントをバインドする代わりに、1 つのフィールドの値のみをサービスに送信し、サイト登録レコードに対してクエリを実行し、ブール値を返します。
  • 頻繁に更新される傾向がある関連データのライブ ポーリング。CRM を開発していて、表示しているアカウントの会社の株価を表示したいとします。setInterval を使用して更新された株価を RPC に定期的に要求し、価格が変化した場合に手動でクライアント側の DOM 操作を行うと、ネットワーク オーバーヘッドを最小限に抑えながらやや複雑な操作を実行できます。

これは、書き込み操作に RPC を使用できないという意味ではありません... しかし、正しく実行するために完全で最新のコンテキスト (つまり、現在のページのすべてのフィールドの現在の値) を必要とする操作については、ほとんどの場合、標準のイベント ハンドラーの方が優れたアプローチです。

于 2012-07-06T06:55:32.060 に答える