0

状況

私はJSPFファイルを持っています（Java jspの「フラグメント」-実際に典型的なJSPとは異なる方法で処理されているかどうかはわかりません-それは単なる命名法だと思いますが、ドキュメントや私が見つけたスタックの回答でさえ不明です）。

この JSPF ファイルの上部と下部にあるインライン スクリプト タグの文字列にアラートを出すことができるので、タグが破損したり、他の HTML シェナニガンによって変更されたりすることはありません。

しかし、一番上の script タグで var を宣言すると、一番下のスクリプト タグでは使用できず、「未定義」と警告されます。

ただし、ウィンドウ オブジェクトのプロパティに割り当てて、そのプロパティ アラートを一番下のスクリプト タグで期待どおりに設定することはできます。ウィンドウオブジェクトを変更しているようには見えません。この JSP ファイルの上部と下部で、適切な型とウィンドウ メソッドが期待どおりに起動していることがわかります。

このページの明らかにひどいこと:

  • 2007年頃のprototype.jsライブラリを使用しています。これは、プロトタイプが本当に醜いことをした後であったと思います。オブジェクトのプロトタイプなどをいじっているようには見えません。

  • HTML のオーバーライドを許可しないロード バランサーからすべてが X-UA 互換性 = IE7 モードで提供されています。ただし、これは絶対にすべての応答ヘッダーにあります。画像、js ファイル、CSS ファイル。以前は、ドキュメント タイプは CSS/HTML の問題にのみ影響すると考えていましたが、リンクされた JS ファイルに配置したり、HTML に JS を含めたりすると、IE7 モードか何かに戻るようです。それまたは他の何かが、IE8で機能するはずのquerySelectorAllメソッドを無効にしていますが、これらのページでは機能しません。

  • 応答ヘッダーはすべて IE7 モードを適用しますが、HTML doc 自体は quirks モードに切り替わります。これは、一般的な標準モードを確立するために doctype を設定する試みだけで十分だと思っていたため、私を混乱させます。私たちの場合、doctype の上に空白があり、これは前半だけです。

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" " http://www.w3.org/TR/html4/loose.dtd ">

これは私たちが実際に持っているものです：

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" >

これは癖モードの原因かもしれませんが、IE8 (IE7 モードの IE8 については不明) は標準モードを確立するために古い Doctype を探しただけで、Doctype の前に空白を許可していると思いました。言うまでもなく、2番目の部分はバリデーター向けだと思いました。とにかく、なぜグローバル空間が核攻撃されたのか、私にはまだわかりません。また、HTML の配置が不適切なテーブルである可能性もあります (ネスト失敗ではなく、間違ったタグ)。

  • おそらく関係ありませんが、Java テンプレートは完全な災害です。ネストされたインクルードには、9 層の深さでネストされたコンテンツを提供する ajax リクエストが混在しています。このページがどのように構築されているかを理解するだけでも、多数の XML、JSP、および Java ファイルを調べる必要があります。モーダルなどを整理するための6つのXML構成ファイル...

私が除外したこと：

  • メタ タグを異なる方法で設定する条件付き IE コメントはありません。IE 以外のブラウザーでも同じ応答ヘッダーを確認できます。

  • これを引き起こすフレームまたは iframe がミックスにありません。もしあったとしても、window オブジェクトのプロパティが同じ値を持つとは思いません。

  • ウィンドウ オブジェクトは、壊れたり上書きされたりしているようには見えません。

  • いいえ、この特定のコードベースで行われているコーヒー スクリプトほど新しいものはありません。これはほとんどがプロトタイプであり、インライン スクリプトを介して JS に直接挿入された taglib データと、主にゼネラリスト/サーバーサイド開発者によって作成された非常にひどい JavaScript の束の不浄な組み合わせです。

  • まだプロファイリングを試みていませんが、メモリの問題ではないと思います。ページに十分な時間を費やして、ページがかなり安定していることを確認しました。ページが読み込まれる前にサーバー上で解決しなければならないがらくたの膨大な量を考えると、パフォーマンスは悪臭を放ちますが、ページが開いているときにメモリが不足したり、クラッシュ/フリーズしたりしません。これは頻繁に使用されるページであり、私たちは実稼働中の自動車販売店にサービスを提供しているため、このページを処理するのにエース マシンが必要だとは思いません。

コードベースの開発バージョンで、doctype を設定しているロード バランサー設定に相当するものを強制終了する必要がある場所をまだ整理していませんが、リンクされたファイルの quirksmode インライン HTML JavaScript と IE7 JavaScript が何らかの原因になっている可能性があります。グローバル空間を破壊する紛争の？しかし、どうにかしてウィンドウ オブジェクトを壊さずにグローバル スペースを破壊するにはどうすればよいでしょうか。それとも、私が知らないprototype.jsのいくつかの側面でしょうか?

4

1 に答える 1

0

わかりました。1 つのスクリプト タグで何かを宣言していますが、これはグローバルである必要がありますが、2 番目のスクリプト タグが実行されるとそこにはありません。特定のページの (javascript) グローバル スペースを複数の部分に「分割」することはできません。iframe のページがある場合...それは違います。それは2 つのページだからです。JavaScriptまたはリダイレクトを行うメタタグと同じです。あなたは2つの別々のページを扱っています。私は、それがここで起こっていることかもしれないと思います.javascriptのリダイレクトがあります。を別のページに設定するスクリプトdocument.location、または同じページを設定するがパラメータが異なるため、異なるスクリプト タグがドキュメントなどにレンダリングされて表示されます。

どの単一ページでも、ローカル宣言とグローバル宣言しかありません。単一のページの意味を緩和せずに、より多くのページを表示できる状況は他に考えられません (前に述べたように)。

（編集：繰り返しますが、グローバルスペースを「壊す」ことはできません。この質問にそのようなタイトルを付けることは、おそらくあなたの質問がかなり無意味であるため、反対票を投じられた理由です。「グローバルスペースを壊す」は、そのフレーズを比喩的に解釈できるという点でのみ意味がありますまた、実際には 2 つの異なるグローバル スペースを表示しているときに、グローバル スペースが「2 つに分割」されているように見えるユース ケースもいくつか考えられます。)

JSP を含む JSP と大量のスクリプト タグがあるので、Fiddler2 のような HTTP トレーサを使用して、どこで何が行われているのかを確実に把握する唯一の方法は、何がロードされるかに関するすべてのトラフィックをキャプチャすることだと私には思えます。特定のページがロードされたと考え、debug最上位のスクリプト ブロックにステートメント (おそらく.と評価します。骨の折れるプロセスであることはわかっていますが、これは、サーバー側のコードがクライアント側のコードと半分危険に混ざり合っている場合に行う必要があることです。ウェブサイトを開発するのは良い方法ではありません。

于 2013-02-11T04:25:06.057 に答える