web-dev-qa-db-ja.com

Response.Writeと<％=％>

これはclassic aspの場合のことです。

これは、Response.Writeステートメント内に含まれるすべてのHTML、または<％=％>を介してHTMLに変数を挿入する方が優れています。
例えば

Response.Write "<table>" & vbCrlf
Response.Write "<tr>" &vbCrLf
Response.Write "<td class=""someClass"">" & someVariable & "</td>" & vbCrLf
Response.Write "</tr>" & vbCrLf
Response.Write "</table>" & vbCrLf

VS

<table>
  <tr>
     <td class="someClass"><%= someVariable %></td>
  </tr>
</table>

挿入する変数が複数ある場合に、サーバーへの影響が最も少ないのはパフォーマンスの観点からです。

技術的な違いがない場合、どちらを選択するのか？

asp-classicvbscript
25
Jon P

まず、注意すべき最も重要な要素は、メンテナンスのしやすさです。サーバーファームを購入するには、面倒なWebサイトを解読して維持する必要があります。

いずれにせよ、それは問題ではありません。 1日の終わりに、すべてのASPはスクリプトを実行するだけです！ASPパーサーはページを受け取り、<%= expression %>を直接変換しますスクリプトが呼び出され、HTMLの連続するすべてのブロックがResponse.Writeへの1つの巨大な呼び出しになります。ページがディスク上で変更されない限り、結果のスクリプトはキャッシュされ、再利用されます。これにより、キャッシュされたスクリプトが再計算されます。

現在、<%= %>を使いすぎると、最新バージョンの「スパゲッティコード」、つまり恐ろしい「タグスープ」につながります。ロジックの表と裏を作成することはできません。一方、Response.Writeを使いすぎると、レンダリングするまでページをまったく見ることができなくなります。必要に応じて<%= %>を使用して、両方の利点を最大限に活用してください。

私の最初のルールは、「可変テキスト」と「静的テキスト」の比率に注意を払うことです。

置換する可変テキストが数箇所しかない場合、<%= %>構文は非常にコンパクトで読みやすいです。ただし、<%= %>が蓄積し始めると、HTMLがますます不明瞭になると同時に、HTMLがロジックをますます不明瞭にします。原則として、ループについて始めたら、停止してResponse.Write`に切り替える必要があります。

他の多くのハードで速いルールはありません。特定のページ（またはページのセクション）について、どちらがより重要であるか、当然理解が難しいか、または壊れやすいかを決定する必要があります。ロジックまたはHTMLですか。それは通常どちらかです（両方の何百ものケースを見てきました）

ロジックがより重要な場合は、Response.Writeに重点を置く必要があります。それはロジックを際立たせます。 HTMLの方が重要な場合は、<%= %>を使用すると、ページ構造が見やすくなります。

時々私は両方のバージョンを書いてそれらを並べて比較し、どちらがより読みやすいかを決定しなければなりませんでした。これは最後の手段ですが、コードが新鮮であることを考慮してください。3か月後に変更を加えなければならないときに喜んでくれます。

41
Euro Micelli

個人的な好みの観点からは、静的コンテンツから可変コンテンツをより適切に分離できると感じている<％=％>メソッドを好みます。

12
Jon P

ここでの回答の多くは、2つのアプローチが同じ出力を生成すること、およびコーディングスタイルとパフォーマンスのいずれかを選択することを示しています。 <％％>外の静的コンテンツは単一のResponse.Writeになると考えられているようです。

ただし、<％％>の外のコードはBinaryWriteで送信されると言った方が正確です。

Response.Writeは、Unicode文字列を受け取り、それを現在のResponse.CodePageにエンコードしてから、バッファに配置します。 ASPファイル内の静的コンテンツに対しては、このようなエンコードは行われません。<％％>の外側の文字は、バイト単位でバッファにバイト単位でダンプされます。

したがって、Response.CodePageがASPファイルの保存に使用されたCodePageと異なる場合、2つのアプローチの結果は異なる場合があります。

たとえば、このコンテンツを標準の1252コードページに保存したとします。

<%
     Response.CodePage = 65001
     Response.CharSet = "UTF-8"
 %>
<p> The British £</p>
<%Response.Write("<p> The British £</p>")%>

最初の段落は文字化けしています。£はUTF-8エンコードを使用して送信されないため、提供されるUnicode文字列はUTF-8にエンコードされるため、2番目の段落は問題ありません。

したがって、パフォーマンスの観点からは、静的なコンテンツを使用するのが望ましいです。エンコードする必要はありませんが、保存されたコードページが出力コードページと異なる場合は注意が必要です。このため、UTF-8として保存し、<％@ codepage = 65001を含めて、Response.Charset = "UTF-8"を設定します。

9
AnthonyWJones

他の人が対処したコードの読みやすさ/保守性の問題はさておき、挿入する変数が複数ある場合のパフォーマンスについて具体的に質問しました。コードのフラグメントのようなものを複数回繰り返すことになると思います。その場合、改行をすべて連結せずに単一のResponse.Writeを使用することで、最高のパフォーマンスを得る必要があります。

Response.Write "<table><tr><td class=""someClass"">" & someVar & "</td></tr></table>"

ブラウザは、HTMLを解析するために改行、タブ、またはその他のきれいなフォーマットを必要としません。パフォーマンスを上げる場合は、これらをすべて削除できます。また、HTML出力を小さくして、ページの読み込み時間を短縮します。

単一の変数の場合は、それほど大きな違いはありません。ただし、複数の変数については、HTMLとASPの間のコンテキスト切り替えを最小限にしたい-あるものから別のものにジャンプするたびにヒットが発生します。

長いステートメントを作成するときに読みやすくするために、ソースコードでVBScriptの行継続文字とタブを使用して（出力ではなく）、パフォーマンスに影響を与えずに構造を表すことができます。

Response.Write "<table>" _
        & "<tr>" _
            & "<td class=""someClass"">" & someVar & "</td>" _
        & "</tr>" _
        & "<tr>" _
            & "<td class=""anotherClass"">" & anotherVar & "</td>" _
        & "</tr>" _
        & "<tr>" _
            & "<td class=""etc"">" & andSoOn & "</td>" _
        & "</tr>" _
    & "</table>"

HTMLバージョンほど読みやすくありませんが、多くの変数を出力（つまり、HTMLとASPの間の多くのコンテキスト切り替え）にドロップすると、パフォーマンスが向上します。

パフォーマンスの向上に価値があるかどうか、またはハードウェアのスケーリングを改善するほうがよいかどうかは別の問題です。もちろん、それが常に選択肢であるとは限りません。

更新：Response.Bufferでパフォーマンスを改善し、コンテキストの切り替えを回避する方法については、Len CardinalによるこのMSDN記事のヒント14と15を参照してください： http://msdn.Microsoft.com/en-us/library/ms972335.aspx#asptips_topic15 。

9
Simon Forrest

いくつかの理由により、ほとんどの状況で<％=％>メソッドを使用します。

  1. HTMLはIDEに公開されているため、ツールチップやタグの終了などを処理することができます。
  2. 出力HTMLでインデントを維持する方が簡単で、レイアウトを作り直すのに非常に役立ちます。
  3. すべてにvbCrLfを追加せずに出力行を確認するための改行。
3
ManiacZX

私のクラシックASPはさびていますが、：

Response.Write "<table>" & vbCrlf
Response.Write "<tr>" &vbCrLf
Response.Write "<tdclass=""someClass"">" & someVariable & "</td>" & vbCrLf 
Response.Write "</tr>" & vbCrLf 
Response.Write "</table>" & vbCrLf

これはそのまま実行されます。ただし、これは：

<table>
  <tr>
     <td class="someClass"><%= someVariable %></td>
  </tr>
</table>

結果は：

Response.Write"<table>\r\n<tr>\r\n<td class="someClass">"
Response.Write someVariable
Response.Write "</td>\r\n</tr>\r\n</table>"

ここで、\ r\nはvbCrLfです

つまり、技術的には2番目の方が高速です。ただし、差は1ミリ秒単位で測定されるため、心配する必要はありません。私は、一番上のものはほとんど保守不可能（HTML-UI開発者によるESP）であり、2番目のものは保守するのが簡単であることをもっと心配します。

@Euro Micelliの小道具-メンテナンスが鍵です（これは、Ruby、Python、および過去（まだ...）のような言語もC＃とJavaがCを突破した理由です） C++とアセンブリ-人間はコードを維持できます。これは、ページの読み込みから数ミリ秒を削るよりもはるかに重要です。

もちろん、C/C++などもその場所にありますが、これはそうではありません。 :)

2
Nic Wise

<%= %>これは、JavaScriptの開発を容易にするためです。このようにコントロールを参照するコードを書くことができます

var myControl = document.getElementById('<%= myControl.ClientID %>');

その後、ハードコードされたIDを気にすることなく、JavaScriptコードで任意の方法でそのコントロールを使用できます。

Response.Writeは一部のASP.NET AJAX=コードを破壊する可能性があるため、カスタムコントロールで特定のものをレンダリングするために使用しない限り、それを回避しようとします。

2
Dan Herbert

ASP/PHPを実行するときにMVCパラダイムを使用しようとします。保守、再設計、拡張が最も簡単になります。その点、私はモデルを表すページを持っている傾向があります。これは主にVB/PHPで、後でビューで使用するために変数を設定します。また、後でビューに含めるためにループするときにHTMLの塊を生成します。次に、ビューを表すページがあります。これは主に<％=％>タグで囲まれたHTMLです。モデルはビューに#include -dであり、先に進みます。コントローラーロジックは通常、JavaScriptの3番目のページまたはサーバー側で実行されます。

2
Jason Dufair

応答フォーマットは次のようにHTMLをレンダリングします：

<table>
<tr>
<td class="someClass">variable value</td>
</tr>
</table>

その結果、コードを生成する手段が読めなくなるだけでなく、結果が不適切にタブ化されます。他のオプションを使います。

2
Russell Myers

<％= Bazify（）％>は、HTMLとインラインで短い式からHTMLを生成する場合に便利です。

Response.Write "foo"は、いくつかのHTMLインラインを多くのコードでインライン化する必要がある場合に適しています。

技術的には同じです。

ただし、例について言えば、Response.Writeコードは＆を使用して多くの文字列を連結します。これは VBScriptでは非常に遅い です。また、 Russell Myersによると のように、他のコードと同じようにタブが付けられていないため、意図的ではない可能性があります。

1
Jacob Krall

私は Jason に同意します。これで、.NETは、最初はひどいWebフォーム/ポストバック/ ViewState .NETの代わりにMVCフレームワークを提供しています。

多分それは私が昔ながらの古典的なASP/HTML/JavaScriptであり、VBデスクトップアプリケーションプログラマではなかったためです。 "The Way of the Web Form？"ですから、私たちは一周して Jason のような方法論に戻っているようです。

それを念頭に置いて、私は常に、モデル/ロジックと<％=％>トークンを含むインクルードページを選択し、効果的なテンプレートHTML "ビュー"を選択します。 HTMLはより「読みやすく」なり、ロジックは従来のASPで可能な限り分離されます。その石で2羽の鳥を殺しています。

1
Sprogz

_<%= %>_と残りはResponse.Write()に展開されるので、最後は同じです。

1
Mark Cidade

Response.Writeへの切り替えによるパフォーマンスの向上はありません。また、ショートカット表記を使用すると、読み取りと保守がより高速になります。

1
Cade Roux

Classic ASP=アプリケーションを作成して維持する必要がある場合は、無料のKudzuASPテンプレートエンジンをチェックしてください。

100％のコードとHTMLの分離が可能で、条件付きコンテンツ、変数の置換、元のASPページのテンプレートレベルの制御が可能です。 If-Then-Else、Try-Catch-Finally、Switch-Case、およびその他の構造タグ、およびASPページまたは動的にロード可能なライブラリ（ASPコードファイル）に基づくカスタムタグを使用できます。構造タグは他の構造内に埋め込むことができますタグを任意のレベルに設定します。

カスタムタグとタグライブラリは簡単に記述でき、ASPページのコードレベルで、またはテンプレートレベルでincludeタグを使用して含めることができます。

マスターページは、マスターページレベルでテンプレートエンジンを呼び出し、2番目の子テンプレートエンジンを内部コンテンツに利用することで作成できます。

KudzuASPでは、aspページにはコードのみが含まれ、テンプレートエンジンが作成され、初期条件が設定され、テンプレートが呼び出されます。テンプレートにはHTMLレイアウトが含まれています。 ASPページがテンプレートを呼び出すと、テンプレートとそれに含まれる構造の評価によって完全に駆動されるイベント駆動型リソースになります。

1
Andrew

コードの再利用とコードの保守性（別名、可読性）の観点から、この質問を組み立てる必要があります。どちらの方法でも、パフォーマンスの向上はありません。

1
Jason Jackson