2

以前の質問で、なぜ私のサイトがとても遅いのかを解明しようとしていました. 下の Fiddler のスクリーンショットによると、特定のページのすべての JavaScript がキャッシュバスター パラメーターを使用して読み込まれていると、誰かが正しく答えました。

フィドラーのスクリーンショット

私が知る限り、以下の javascript への参照はすべて、トリックのない単純なバニラです。個別に含まれている場合もあれば、バンドルの一部として含まれている場合もあります。ビュー自体は非常に複雑なダッシュボードであり、多くの部分的なビューと、さまざまなウィジェットをロードするためのマルチスレッド スクリプトが含まれています。なぜ誰もがキャッシュバスターを入れようと考えたのか想像できません.

プログラマーの 1 人が偶然につまずいた可能性のある隠されたトリップワイヤーはありますか? この Fiddler レポートを読んで、どの特定のビューがキャッシュバスターをトリガーしているかを知る方法はありますか?

編集:バンドルの名前変更とその呼び出しを試してみたところ、問題のあるファイルは_Layout.cshtml. スクリプトを正常にロードする場合もあれば、キャッシュバスターでロードする場合もあります。実際のコード:

<body id="mainLayout">
@Styles.Render("~/Content/themes/base/css", "~/Content/css")
@Scripts.Render("~/bundles/modernizr")
@Scripts.Render("~/bundles/jquery")
@Scripts.Render("~/bundles/jqueryval")
... etc ...

それについて何も悪いことはありませんよね？では、_Layout に基づくビューは、すべてのスクリプトにキャッシュバスターを強制的に使用させるために何をしなければならないのでしょうか?

編集:同じ問題がKendo UI フォーラムで説明されています(この記事の執筆時点では未解決)。問題を引き起こす JavaScript コードは次のとおりです。

$(document).ready(function () {
    if ('@ViewBag.Loaded' != 'Y') {
        $.ajax({
            type: 'POST',
            url: "/CRCDashBoard/LoadCRCDashboard",
            success: function (data) {
                $("#mainLayout").html(data);
            },
            error: function (jqXhr, textStatus, errorThrown) {
                alert(errorThrown);
            }
        });
    }
    ...
}
4

1 に答える 1

2

最終的に、Kendo はそれが TabStrip コントロールのバグであることを発見しました。

実際には、ビューを再構築し、ポストバック データを部分ビューとして戻すという別の回避策を既に使用しています。したがって、それを使用するか、提案された解決策を使用する (キャッシュを明示的に true に設定する) ことができます。

于 2013-05-08T11:49:29.257 に答える