3

最近、EventSource を発見しました。YUI3 には動作を正規化してフォールバックするための Gallery モジュールがあります。このフレームワークを既に使用しているため、この例で使用することを選択しました。

だから私はかなりのことを検索し、多くのブログ、投稿、および例を読みましたが、それらはすべてほとんど同じことを示しています: 基本的な SSE イベントのセットアップ方法. これで、open/message/error/close イベントが発生する 6 つの例が得られました。

私が持っていないもの (このリンクが私に与えてくれることを望んでいたもの) は、アプリケーションにとってより便利な SSE イベントを発生させる方法の例です。「更新」と呼ばれるものを試しています。

ここに私の基本的なテスト ページがあります: http://codefinger.co.nz/public/yui/eventsource/test.php (これは html ファイルである可能性があります。ここにはまだ php コードはありません)

EventSource コンストラクターの「message.php」は次のとおりです。

<?php
header('Content-Type: text/event-stream');
header('Cache-Control: no-cache'); // recommended to prevent caching of event data.

/**
 * Constructs the SSE data format and flushes that data to the client.
 *
 * @param string $id Timestamp/id of this connection.
 * @param string $msg Line of text that should be transmitted.
 */
function sendMsg($id, $msg) {
  echo "id: $id" . PHP_EOL;
  echo "data: $msg" . PHP_EOL;
  echo PHP_EOL;
  ob_flush();
  flush();
}
while(true) {
  $serverTime = time();
  sendMsg($serverTime, 'server time: ' . date("h:i:s", time()));
  sleep(10);
}

// I was hoping calling this file with a param might allow me to fire an event,
// which it does dutifully, but no browsers register the 'data : update' - though
// I do see the response in Firebug.
if( $_REQUEST['cmd'] ){
    sendMsg($serverTime, $_REQUEST['cmd'] );
}
?>

上記のライブの例から、YUI の io モジュールを使用して、「更新」ボタンをクリックしたときに「更新」イベントを発生させるためにパラメーターを指定してリクエストを送信しようとしたことがわかります。Firebug の [Net] パネルでわかるように、動作しているように見えますが、イベントが処理されていません (上記のスクリプトがそのループを再度実行することに気付きました。接続されたブラウザーでイベントを処理したいだけなので、削除します)。 /掃除）。

私はこの部分を間違っていますか？それとも、私が間違っているもっと根本的なことがありますか? UI の状態の変化に応じてイベントをプッシュしようとしています。

この SO の質問は近いように見えました。@tomfumb は、次の質問は「最初の接続が確立された後にクライアントに新しいイベントを送信する方法です。PHP は決して実行を停止する必要がないことがわかりました。」とコメントしました。しかし、確かに私はイベントが発生したときにのみ送信します...そして継続的にではありません...

4

1 に答える 1

3

あなたのアプローチにはいくつかの問題があります：

  1. クライアントにイベント データを送信する無限ループのため、cmd パラメータを読み取るサーバー側コードに到達できません。
  2. クライアントからサーバーにイベントを送信しようとしています。それは仕様名 - Server-Sent Events - サーバーがイベントの送信者であり、クライアントが受信者です。ここにオプションがあります：
    1. 双方向通信APIである Web Socketsと呼ばれるジョブに適切な仕様を使用する
    2. 目的のタイプの通信を可能にするロジックを作成する

SSE API を使用することを選択した場合、2 つのシナリオが考えられます

  1. 同じイベント ソース接続を再利用し、接続のプールをサーバーに保存します。ユーザーが update コマンドを使用して後続の XMLHttpRequest を送信すると、このビジターによって作成されたプールから EventSource 接続が取得され、それを使用してカスタム イベント タイプを指定する応答が送信されます。デフォルトのタイプはメッセージです。クライアントへの別の EventSource 接続を作成する無限ループに入らないようにすることが重要ですが、クライアントは EventSource ではなく XMLHttpRequest を使用して要求を行ったため、それを処理しません。
  2. すべてのリクエストは EventSource で行います。新しい EventSource リクエストを作成する前に、前のリクエストを閉じます。これは、クライアントまたはサーバーから実行できます。サーバーでパラメーターを確認してから、データをクライアントに送信します。

また、(長い) ポーリングで XMLHttpRequest を使用できるため、EventSource を使用する必要がなくなります。例が単純であるため、2 種類のリクエストを混在させる理由がわかりません。

于 2012-03-10T22:42:49.057 に答える