2

私のアプリケーションは、次のような階層データ選択 (タクソノミー選択) を広範囲に使用しています (正確ではありません)。

Country
  => State
    => City
      => Street

したがって、ユーザーが第 1 レベルのオプションを選択すると、JS AJAX が第 2 レベルをロードし、ユーザーが選択した後に AJAX が第 3 レベルをロードする、というように...

アプリケーションを高速化する 1 つの方法は、階層全体を JS ファイルとしてロードし、If-Modified-Since /* Last-Modified * と304応答コードを利用して JavaScript からこのデータを直接使用して、この大容量をキャッシュすることだと思います (50 KiB、12 after gzip)時間のかかる (DB からの取得に 300 ミリ秒) データ。

ホイールを発明することを恐れて、私はそのような技術をジェット実装しません。実装しようとすると、以下のテクニックを使用します...

Spring はLast-Modified HTTP 1.1 ヘッダーをサポートするようになりました。

@RequestMapping
public String myHandleMethod(WebRequest webRequest, Model model) {
    long lastModified = // 1. application-specific calculation
    if (request.checkNotModified(lastModified)) {
        // 2. shortcut exit - no further processing necessary
        return null;
     }
    // 3. or otherwise further request processing, actually preparing content
    model.addAttribute(...);
    return "myViewName";
}

Oracle では、 ALL_TAB_MODIFICATIONS/USER_TAB_MODIFICATIONSによるテーブルの変更を高速にチェックできます。

select timestamps from all_tab_modifications where table_name = 'COUNTRY';
select timestamps from all_tab_modifications where table_name = 'STATE';
...

階層データを使用する JSP ページには、js ファイルを含めます。

 <script src="<c:url value='js/db/units.js'/>"></script>

フォーム内の完全な階層データを使用 (このようにJava DWRを実行):

uniqPrefix.units = {
  "USA": {
      "Alabama": { 
          "Montgomery": ["Street 1", "Street 2"],
          "Birmingham": ["Street 3", "Street 4"],
      }, ...
   "UK": { ... }
}

Ajaxクエリなし<select>でJavaScriptコードで埋められたHTMLタグ...js/db/units.js

また、サーバー側では、ユーザーが最後にサイトにアクセスしてからテーブルが変更されていないjs/db/units.js場合Country、再生成しません...StateCityStreet

ブラウザのIf-Modified-Sinceリクエストパラメータと304 HTTPサーバーの応答を利用して、アプリケーションサーバーからJavaScriptにデータをキャッシュするのは正常ですか、それともこれはまったく壊れたアプローチですか?

4

2 に答える 2

4

他の HTTP クライアントと比較して、Javascript 駆動の HTTP クライアントについて特別なことは何もありません。あなたが説明しているのは、まさに 304 応答が設計されているものです。データが変更されていない場合、アプリケーションデータの再読み込みを避ける必要があります。

于 2013-04-03T10:29:15.980 に答える
1

サーバーから JS を再取得することを避けるためにキャッシングを使用するのはごく普通のことです。あなたのケースでそれが良いアイデアかどうかは、ページがどのように使用されるかによって異なります。典型的なユーザーが階層から複数の選択を行うことが予想される場合 (それ以外の場合は複数の AJAX 呼び出しが必要になります)、キャッシュは良いアイデアのように思えます。

パフォーマンスの観点からは、通常、多数の小さな呼び出しよりも 1 つの大きな呼び出しを行う方がはるかに優れています。サーバーへの個別の呼び出しには、それに関連するオーバーヘッドがあります。説明したように、すべての JS をキャッシュすることにより、このペナルティを 1 回だけ支払うことになります。

于 2013-04-03T10:28:36.490 に答える