ASP.NET 2.0 ページ モデル
ASP.NET 1.x では、開発者はインライン コード モデルと分離コード モデルのどちらかを選択しました。 分離コードは、 ディレクティブの Src 属性または CodeBehind 属性 @Page を使用して実装できます。 ASP.NET 2.0 では、開発者はインライン コードと分離コードのどちらかを選択できますが、分離コード モデルには大幅な機能強化が行われています。
ASP.NET 1.x では、開発者はインライン コード モデルと分離コード モデルのどちらかを選択しました。 分離コードは、 ディレクティブの Src 属性または CodeBehind 属性 @Page を使用して実装できます。 ASP.NET 2.0 では、開発者はインライン コードと分離コードのどちらかを選択できますが、分離コード モデルには大幅な機能強化が行われています。
Code-Behind モデルの機能強化
ASP.NET 2.0 の分離コード モデルの変更を完全に理解するために、ASP.NET 1.x に存在していたモデルをすばやく確認することをお勧めします。
ASP.NET 1.x のCode-Behind モデル
ASP.NET 1.x では、分離コード モデルは ASPX ファイル (Web フォーム) とプログラミング コードを含む分離コード ファイルで構成されていました。 2 つのファイルは、ASPX ファイルの @Page ディレクティブを使用して接続されました。 ASPX ページの各コントロールには、インスタンス変数として分離コード ファイルに対応する宣言がありました。 分離コード ファイルには、Visual Studio デザイナーに必要なイベント バインドと生成されたコードのコードも含まれていました。 このモデルはかなりうまく機能しましたが、ASPX ページのすべての ASP.NET 要素には分離コード ファイル内の対応するコードが必要であるため、コードとコンテンツの真の分離はありませんでした。 たとえば、デザイナーが Visual Studio IDE の外部の ASPX ファイルに新しいサーバー コントロールを追加した場合、分離コード ファイルにそのコントロールの宣言がないため、アプリケーションは中断します。
ASP.NET 2.0 のCode-Behind モデル
ASP.NET 2.0 は、このモデルを大幅に改善します。 ASP.NET 2.0 では、ASP.NET 2.0 で提供される新しい 部分クラス を使用して分離コードが実装されています。 ASP.NET 2.0 の分離コード クラスは、部分クラスとして定義されています。つまり、クラス定義の一部のみが含まれます。 クラス定義の残りの部分は、実行時または Web サイトがプリコンパイル時に ASPX ページを使用して、ASP.NET 2.0 によって動的に生成されます。 分離コード ファイルと ASPX ページの間のリンクは、 @ Page ディレクティブを使用して確立されます。 ただし、CodeBehind 属性または Src 属性の代わりに、ASP.NET 2.0 では CodeFile 属性が使用されるようになりました。 Inherits 属性は、ページのクラス名を指定するためにも使用されます。
一般的な @ Page ディレクティブは次のようになります。
<%@Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %>
ASP.NET 2.0 分離コード ファイルの一般的なクラス定義は次のようになります。
public partial class _Default : System.Web.UI.Page
Note
C# と Visual Basic は、現在部分クラスをサポートしている唯一のマネージド言語です。 したがって、J# を使用する開発者は、ASP.NET 2.0 では分離コード モデルを使用できません。
開発者は作成したコードのみを含むコード ファイルを使用できるようになるため、新しいモデルによって分離コード モデルが強化されます。 また、分離コード ファイルにはインスタンス変数宣言がないため、コードとコンテンツを真に分離することもできます。
Note
ASPX ページの部分クラスはイベント バインディングが行われる場所であるため、Visual Basic 開発者は分離コードのハンドル キーワード (keyword)を使用してイベントをバインドすることで、若干のパフォーマンスの向上を実現できます。 C# には同等のキーワード (keyword)はありません。
新しい @ ページ ディレクティブ属性
ASP.NET 2.0 では、 @ Page ディレクティブに多くの新しい属性が追加されます。 ASP.NET 2.0 では、次の属性が新しく追加されました。
Async
Async 属性を使用すると、ページを非同期的に実行するように構成できます。 このモジュールの後半の非同期ページについても説明します。
非同期タイムアウト
非同期ページのタイムアウトを指定しました。 既定値は 45 秒です。
Codefile
CodeFile 属性は、Visual Studio 2002/2003 の CodeBehind 属性に代わる属性です。
CodeFileBaseClass
CodeFileBaseClass 属性は、1 つの基底クラスから複数のページを派生させる場合に使用されます。 ASP.NET の部分クラスが実装されているため、この属性を使用しない場合、共有共通フィールドを使用して ASPX ページで宣言されたコントロールを参照する基底クラスは、ASP が正しく機能しません。NET コンパイル エンジンは、ページ内のコントロールに基づいて新しいメンバーを自動的に作成します。 したがって、ASP.NET 内の 2 つ以上のページに共通の基底クラスが必要な場合は、CodeFileBaseClass 属性で基底クラスを指定し、その基底クラスから各ページ クラスを派生させる必要があります。 この属性を使用する場合は、CodeFile 属性も必要です。
CompilationMode
この属性を使用すると、ASPX ページの CompilationMode プロパティを設定できます。 CompilationMode プロパティは、 Always、 Auto、 Never の値を含む列挙です。 既定値は Always です。 [自動] 設定では、ASP.NET が可能な場合にページを動的にコンパイルできなくなります。 動的コンパイルからページを除外すると、パフォーマンスが向上します。 ただし、除外されたページにコンパイルする必要があるコードが含まれている場合は、ページを参照するとエラーがスローされます。
イベント検証を有効にする
この属性は、ポストバック イベントとコールバック イベントを検証するかどうかを指定します。 これが有効になっている場合、ポストバックイベントまたはコールバックイベントの引数がチェックされ、最初にレンダリングされたサーバーコントロールから発生したことを確認します。
テーマを有効にする
この属性は、ページでテーマ ASP.NET 使用するかどうかを指定します。 既定値は false です。 ASP.NET テーマについては、 モジュール 10 で説明します。
LinePragmas
この属性は、コンパイル時に行プラグマを追加するかどうかを指定します。 行プラグマは、コードの特定のセクションをマークするためにデバッガーによって使用されるオプションです。
MaintainScrollPositionOnPostback
この属性は、ポストバック間のスクロール位置を維持するために、JavaScript をページに挿入するかどうかを指定します。 この属性は、既定では false です 。
この属性が true の場合、ASP.NET はポストバックに次のようなスクリプト> ブロックを追加<します。
<script src="/website/WebResource.axd?d=jBAvpwrdOM_V_Xzeox989A2 &t=632653133849531250" type="text/javascript"> </script>
このスクリプト ブロックの src は WebResource.axd であることに注意してください。 このリソースは物理パスではありません。 このスクリプトが要求されると、ASP.NET はスクリプトを動的にビルドします。
MasterPageFile
この属性は、現在のページのマスター ページ ファイルを指定します。 相対パスと絶対パスのどちらでも構いません。 マスター ページについては、 モジュール 4 で説明します。
スタイル シートのテーマ
この属性を使用すると、ASP.NET 2.0 テーマによって定義されたユーザー インターフェイスの外観プロパティをオーバーライドできます。 テーマについては、 モジュール 10 で説明します。
テーマの値
ページのテーマを指定します。 StyleSheetTheme 属性に値が指定されていない場合、Theme 属性はページ上のコントロールに適用されるすべてのスタイルをオーバーライドします。
タイトル値
ページのタイトルを設定します。 ここで指定した値は、レンダリングされたページの title> 要素に表示されます<。
ViewStateEncryptionMode
ViewStateEncryptionMode 列挙の値を設定します。 使用可能な値は、 Always、 Auto、 Never です。 既定値は Auto です。この属性が Auto の値に設定されている場合、viewstate は RegisterRequiresViewStateEncryption メソッドを呼び出すことによってコントロールによって要求されます。
@ Page ディレクティブを使用したパブリック プロパティ値の設定
ASP.NET 2.0 の @ Page ディレクティブのもう 1 つの新機能は、基底クラスのパブリック プロパティの初期値を設定する機能です。 たとえば、基底クラスに SomeText というパブリック プロパティがあり、ページが読み込まれるときに Hello に初期化するとします。 これを実現するには、@ Page ディレクティブの値を次のように設定するだけです。
<%@Page Language="C#" SomeText="Hello!" Inherits="PageBase" %>
@ Page ディレクティブの SomeText 属性は、基底クラスの SomeText プロパティの初期値を Hello! に設定します。 次のビデオでは、 @ Page ディレクティブを使用して、基底クラスのパブリック プロパティの初期値を設定するチュートリアルを示します。
![いずれかの行の [テキスト] 属性を示す赤い矢印が表示された Microsoft Visual Studio ウィンドウのスクリーンショット。](the-asp-net-2-0-page-model/_static/image1.png)
Page クラスの新しいパブリック プロパティ
ASP.NET 2.0 の新しいパブリック プロパティを次に示します。
AppRelativeTemplateSourceDirectory
ページまたはコントロールへのアプリケーション相対パスを返します。 たとえば、 にある http://app/folder/page.aspxページの場合、 プロパティは ~/folder/ を返します。
AppRelativeVirtualPath
ページまたはコントロールへの相対仮想ディレクトリ パスを返します。 たとえば、 にあるページ http://app/folder/page.aspxの場合、 プロパティは ~/folder/page.aspx を返します。
AsyncTimeout
非同期ページ処理に使用されるタイムアウトを取得または設定します。 (非同期ページについては、このモジュールの後半で説明します)。
ClientQueryString
要求された URL のクエリ文字列部分を返す読み取り専用プロパティ。 この値は URL エンコード済みです。 HttpServerUtility クラスの UrlDecode メソッドを使用してデコードできます。
ClientScript
このプロパティは、ASP の管理に使用できる ClientScriptManager オブジェクトを返します。クライアント側スクリプトの NET の出力。 (ClientScriptManager クラスについては、このモジュールの後半で説明します)。
EnableEventValidation
このプロパティは、ポストバック イベントとコールバック イベントに対してイベント検証を有効にするかどうかを制御します。 有効にすると、ポストバックまたはコールバック イベントの引数が検証され、最初にレンダリングされたサーバー コントロールから生成されたことを確認します。
EnableTheming
このプロパティは、ASP.NET 2.0 テーマをページに適用するかどうかを指定するブール型 (Boolean) の値を取得または設定します。
フォーム
このプロパティは、ASPX ページの HTML フォームを HtmlForm オブジェクトとして返します。
ヘッダー
このプロパティは、ページ ヘッダーを含む HtmlHead オブジェクトへの参照を返します。 返された HtmlHead オブジェクトを使用して、スタイル シート、メタ タグなどを取得/設定できます。
IdSeparator
この読み取り専用プロパティは、ASP.NET がページ上のコントロールの一意の ID を構築するときにコントロール識別子を分離するために使用される文字を取得します。 コードから直接使用するためのものではありません。
IsAsync
このプロパティでは、非同期ページを使用できます。 非同期ページについては、このモジュールの後半で説明します。
IsCallback
ページがコールバックの結果である場合、この読み取り専用プロパティは true を 返します。 コールバックについては、このモジュールの後半で説明します。
IsCrossPagePostBack
ページがページ間ポストバックの一部である場合、この読み取り専用プロパティは true を 返します。 クロスページ ポストバックについては、このモジュールの後半で説明します。
アイテム
ページ コンテキストに格納されているすべてのオブジェクトを含む IDictionary インスタンスへの参照を返します。 この IDictionary オブジェクトに項目を追加すると、コンテキストの有効期間を通じてアイテムを使用できるようになります。
MaintainScrollPositionOnPostBack
このプロパティは ASP.NET ポストバックが発生した後にブラウザーでページのスクロール位置を維持する JavaScript を出力するかどうかを制御します。 (このプロパティの詳細については、このモジュールで前に説明しました)。
Master
この読み取り専用プロパティは、マスター ページが適用されているページの MasterPage インスタンスへの参照を返します。
MasterPageFile
ページのマスター ページ ファイル名を取得または設定します。 このプロパティは、PreInit メソッドでのみ設定できます。
MaxPageStateFieldLength
このプロパティは、ページの状態の最大長をバイト単位で取得または設定します。 プロパティが正の数に設定されている場合、ページビューステートは複数の非表示フィールドに分割され、指定されたバイト数を超えないようにします。 プロパティが負の数の場合、ビューステートはチャンクに分割されません。
PageAdapter
要求元のブラウザーのページを変更する PageAdapter オブジェクトへの参照を返します。
Previouspage
Server.Transfer またはページ間ポストバックの場合に、前のページへの参照を返します。
Skinid
ページに適用する ASP.NET 2.0 スキンを指定します。
StyleSheetTheme
このプロパティは、ページに適用されるスタイル シートを取得または設定します。
TemplateControl
ページのコントロールを含む への参照を返します。
テーマ
ページに適用される ASP.NET 2.0 テーマの名前を取得または設定します。 この値は、PreInit メソッドの前に設定する必要があります。
タイトル
このプロパティは、pages ヘッダーから取得したページのタイトルを取得または設定します。
ViewStateEncryptionMode
ページの ViewStateEncryptionMode を取得または設定します。 このモジュールの前半で、このプロパティの詳細な説明を参照してください。
Page クラスの新しい保護されたプロパティ
ASP.NET 2.0 の Page クラスの新しい保護されたプロパティを次に示します。
アダプター
要求したデバイス上のページをレンダリングする ControlAdapter への参照を返します。
AsyncMode
このプロパティは、ページが非同期的に処理されるかどうかを示します。 これは、コード内で直接ではなく、ランタイムで使用することを目的としています。
ClientIDSeparator
このプロパティは、コントロールの一意のクライアント ID を作成するときに区切り記号として使用される文字を返します。 これは、コード内で直接ではなく、ランタイムで使用することを目的としています。
PageStatePersister
このプロパティは、ページの PageStatePersister オブジェクトを返します。 このプロパティは、主に ASP.NET コントロール開発者によって使用されます。
UniqueFilePathSuffix
このプロパティは、キャッシュ ブラウザーのファイル パスに追加される一意のサフィックスを返します。 既定値は __ufps= で、6 桁の数字です。
Page クラスの新しいパブリック メソッド
次のパブリック メソッドは、ASP.NET 2.0 の Page クラスの新機能です。
AddOnPreRenderCompleteAsync
このメソッドは、非同期ページ実行用のイベント ハンドラー デリゲートを登録します。 非同期ページについては、このモジュールの後半で説明します。
ApplyStyleSheetSkin
ページ スタイル シートのプロパティをページに適用します。
ExecuteRegisteredAsyncTasks
このメソッドは非同期タスクです。
GetValidators
指定されていない場合は、指定した検証グループまたは既定の検証グループの検証コントロールのコレクションを返します。
RegisterAsyncTask
このメソッドは、新しい非同期タスクを登録します。 非同期ページについては、このモジュールの後半で説明します。
RegisterRequiresControlState
このメソッドは、ページ コントロールの状態を永続化する必要があることを ASP.NET に指示します。
RegisterRequiresViewStateEncryption
このメソッドは、ページビューステートに暗号化が必要であることを ASP.NET に伝えます。
ResolveClientUrl
イメージなどのクライアント要求に使用できる相対 URL を返します。
SetFocus
このメソッドは、ページが最初に読み込まれるときに指定されたコントロールにフォーカスを設定します。
UnregisterRequiresControlState
このメソッドは、制御状態の永続化を必要としないため、渡されたコントロールの登録を解除します。
ページ ライフサイクルの変更
ASP.NET 2.0 のページ ライフサイクルは大幅に変更されていませんが、注意すべき新しい方法がいくつかあります。 ASP.NET 2.0 ページのライフサイクルの概要を次に示します。
PreInit (ASP.NET 2.0 の新機能)
PreInit イベントは、開発者がアクセスできるライフサイクルの最も初期のステージです。 このイベントを追加すると、ASP.NET 2.0 テーマ、マスター ページ、ASP.NET 2.0 プロファイルのアクセス プロパティなどをプログラムで変更できます。ポストバック状態の場合は、Viewstate がライフサイクルのこの時点でコントロールにまだ適用されていないことを認識することが重要です。 したがって、開発者がこの段階でコントロールのプロパティを変更すると、ページのライフサイクルの後半で上書きされる可能性があります。
Init
Init イベントは、ASP.NET 1.x から変更されていません。 ここでは、ページ上のコントロールのプロパティを読み取りまたは初期化します。 この段階では、マスター ページ、テーマなどです。は既にページに適用されています。
InitComplete (2.0 の新機能)
InitComplete イベントは、ページ初期化ステージの最後に呼び出されます。 ライフサイクルのこの時点で、ページ上のコントロールにアクセスできますが、その状態はまだ設定されていません。
PreLoad (2.0 の新機能)
このイベントは、すべてのポストバック データが適用された後、Page_Loadの直前に呼び出されます。
[読み込み]
Load イベントは、ASP.NET 1.x から変更されていません。
LoadComplete (2.0 の新機能)
LoadComplete イベントは、ページ読み込みステージの最後のイベントです。 この段階では、すべてのポストバックデータとビューステートデータがページに適用されています。
Prerender
ページに動的に追加されるコントロールに対して viewstate を適切に維持する場合は、PreRender イベントが最後に追加されます。
PreRenderComplete (2.0 の新機能)
PreRenderComplete ステージでは、すべてのコントロールがページに追加され、ページをレンダリングする準備が整いました。 PreRenderComplete イベントは、pages viewstate が保存される前に発生した最後のイベントです。
SaveStateComplete (2.0 の新機能)
SaveStateComplete イベントは、すべてのページ ビューステートとコントロール状態が保存された直後に呼び出されます。 これは、ページが実際にブラウザーにレンダリングされる前の最後のイベントです。
レンダー
Render メソッドは、ASP.NET 1.x 以降は変更されていません。 ここで HtmlTextWriter が初期化され、ページがブラウザーにレンダリングされます。
ASP.NET 2.0 でのページ間ポストバック
ASP.NET 1.x では、ポストバックは同じページに投稿する必要がありました。 ページ間ポストバックは許可されませんでした。 ASP.NET 2.0 では、IButtonControl インターフェイスを使用して別のページにポストバックする機能が追加されています。 新しい IButtonControl インターフェイス (サードパーティのカスタム コントロールに加えて Button、LinkButton、ImageButton) を実装するコントロールは、PostBackUrl 属性を使用してこの新機能を利用できます。 次のコードは、2 番目のページにポストバックする Button コントロールを示しています。
<asp:Button ID="SubmitReport" PostBackUrl="~/Default.aspx" runat="server" Text="Submit Report" />
ページがポストバックされると、ポストバックを開始する Page には、2 番目のページの PreviousPage プロパティを使用してアクセスできます。 この機能は、ASP.NET 2.0 が別のページにポストバックしたときにページにレンダリングされる新しいWebForm_DoPostBackWithOptionsクライアント側関数を介して実装されます。 この JavaScript 関数は、クライアントにスクリプトを出力する新しい WebResource.axd ハンドラーによって提供されます。
次のビデオは、ページ間ポストバックのチュートリアルです。
![[レポートの送信] オプションを表示するインターネット エクスプローラー ブラウザー ページを示す、ページ間ポストバックのビデオ チュートリアルのスクリーンショット。](the-asp-net-2-0-page-model/_static/image2.png)
クロスページ ポストバックの詳細
Viewstate
クロスページ ポストバック シナリオでは、最初のページから viewstate に何が起こるかについて、既に自問している可能性があります。 結局のところ、IPostBackDataHandler を実装していないコントロールは viewstate を使用してその状態を保持するため、ページ間ポストバックの 2 ページ目でそのコントロールのプロパティにアクセスするには、ページの viewstate にアクセスできる必要があります。 ASP.NET 2.0 は、__PREVIOUSPAGE という 2 番目のページの新しい非表示フィールドを使用して、このシナリオを処理します。 __PREVIOUSPAGE フォーム フィールドには、最初のページの viewstate が含まれているため、2 番目のページのすべてのコントロールのプロパティにアクセスできます。
FindControl の回避
ページ間ポストバックのビデオ チュートリアルでは、FindControl メソッドを使用して、最初のページの TextBox コントロールへの参照を取得しました。 このメソッドはその目的に適していますが、FindControl はコストが高く、追加のコードを記述する必要があります。 幸いにも、ASP.NET 2.0 には、多くのシナリオで機能するこの目的のために FindControl の代替手段が用意されています。 PreviousPageType ディレクティブを使用すると、TypeName 属性または VirtualPath 属性を使用して、前のページへの厳密に型指定された参照を持つことができます。 TypeName 属性を使用すると、前のページの種類を指定できますが、VirtualPath 属性を使用すると、仮想パスを使用して前のページを参照できます。 PreviousPageType ディレクティブを設定したら、コントロールなどを公開する必要があります。パブリック プロパティを使用してアクセスを許可する。
ラボ 1 クロスページ ポストバック
このラボでは、ASP.NET 2.0 の新しいクロスページ ポストバック機能を使用するアプリケーションを作成します。
Visual Studio 2005 を開き、新しい ASP.NET Web サイトを作成します。
page2.aspx という名前の新しい Web フォームを追加します。
デザイン ビューで Default.aspx を開き、Button コントロールと TextBox コントロールを追加します。
- Button コントロールに SubmitButton の ID を指定し、TextBox コントロールに UserName の ID を指定します。
- Button の PostBackUrl プロパティを page2.aspx に設定します。
ソース ビューで page2.aspx を開きます。
次に示すように、 @ PreviousPageType ディレクティブを追加します。
page2.aspx の分離コードのPage_Loadに次のコードを追加します。
Response.Write(PreviousPage.UserName.Text);[ビルド] メニューの [ビルド] をクリックして、プロジェクトをビルドします。
Default.aspx の分離コードに次のコードを追加します。
public TextBox txtUserName { get { return this.UserName; } }page2.aspx のPage_Loadを次のように変更します。
Response.Write(PreviousPage.txtUserName.Text);プロジェクトをビルドします。
プロジェクトを実行します。
[テキスト ボックス] に自分の名前を入力し、ボタンをクリックします。
結果は何ですか?
ASP.NET 2.0 の非同期ページ
ASP.NET の競合の問題の多くは、外部呼び出しの待機時間 (Web サービスやデータベース呼び出しなど)、ファイル IO 待機時間などが原因です。ASP.NET アプリケーションに対して要求が行われると、ASP.NET はそのワーカー スレッドの 1 つを使用してその要求にサービスを提供します。 要求が完了し、応答が送信されるまで、その要求はそのスレッドを所有します。 ASP.NET 2.0 では、ページを非同期的に実行する機能を追加することで、これらの種類の問題に関する待機時間の問題を解決しようとしている。 つまり、ワーカー スレッドは要求を開始し、別のスレッドに追加の実行を渡すことができるため、使用可能なスレッド プールにすばやく戻ります。 ファイル IO、データベース呼び出し時など。が完了すると、要求を完了するためにスレッド プールから新しいスレッドが取得されます。
ページを非同期的に実行する最初の手順は、ページ ディレクティブの Async 属性を次のように設定することです。
<%@ Page Async="true" %>
この属性は、ページの IHttpAsyncHandler を実装するように ASP.NET に指示します。
次の手順では、PreRender より前のページのライフサイクルのポイントで AddOnPreRenderCompleteAsync メソッドを呼び出します。 (このメソッドは通常、Page_Loadで呼び出されます。AddOnPreRenderCompleteAsync メソッドは、2 つのパラメーターを受け取ります。BeginEventHandler と EndEventHandler。 BeginEventHandler は IAsyncResult を返し、パラメーターとして EndEventHandler に渡します。
次のビデオは、非同期ページ要求のチュートリアルです。
Note
非同期ページは、EndEventHandler が完了するまでブラウザーにレンダリングされません。 間違いなく、一部の開発者は非同期要求を非同期コールバックに似ていると考えるでしょう。 そうではないことを認識することが重要です。 非同期要求の利点は、新しい要求を処理するために最初のワーカー スレッドをスレッド プールに返すことができるため、IO バインドなどによる競合が軽減されることです。
ASP.NET 2.0 のスクリプト コールバック
Web 開発者は、コールバックに関連するちらつきを防ぐ方法を常に探してきました。 ASP.NET 1.x では、SmartNavigation がちらつきを回避するための最も一般的な方法でしたが、SmartNavigation はクライアントでの実装が複雑なため、一部の開発者に問題を引き起こしました。 ASP.NET 2.0 では、スクリプト コールバックに関するこの問題に対処しています。 スクリプト コールバックは XMLHttp を使用して、JavaScript を介して Web サーバーに対して要求を行います。 XMLHttp 要求は、ブラウザーの DOM を介して操作できる XML データを返します。 XMLHttp コードは、新しい WebResource.axd ハンドラーによってユーザーに表示されません。
ASP.NET 2.0 でスクリプト コールバックを構成するには、いくつかの手順が必要です。
手順 1: ICallbackEventHandler インターフェイスを実装する
ASP.NET がスクリプト コールバックに参加しているページを認識するには、ICallbackEventHandler インターフェイスを実装する必要があります。 これは、次のように分離コード ファイルで行うことができます。
public partial class _Default : System.Web.UI.Page, ICallbackEventHandler
@ Implements ディレクティブを使用して、次のように行うこともできます。
<%@ Implements Interface="System.Web.UI.ICallbackEventHandler" %>
インライン ASP.NET コードを使用する場合は、通常@ Implements ディレクティブを使用します。
手順 2: GetCallbackEventReference を呼び出す
前述のように、XMLHttp 呼び出しは WebResource.axd ハンドラーにカプセル化されます。 ページがレンダリングされると、ASP.NET は WebResource.axd によって提供されるクライアント スクリプトである WebForm_DoCallback への呼び出しを追加します。 WebForm_DoCallback関数は、コールバックの__doPostBack関数を置き換えます。 __doPostBackプログラムによってページにフォームが送信されることを覚えておいてください。 コールバック シナリオでは、ポストバックを防ぐ必要があるため、__doPostBackで十分ではありません。
Note
__doPostBackは、クライアント スクリプトのコールバック シナリオでページにレンダリングされます。 ただし、コールバックには使用されません。
WebForm_DoCallbackクライアント側関数の引数は、通常は Page_Load で呼び出されるサーバー側関数 GetCallbackEventReference を介して提供されます。 GetCallbackEventReference の一般的な呼び出しは次のようになります。
// Set up the JavaScript callback string cbRef = cm.GetCallbackEventReference(this, "document.getElementById('ddlCompany').value", "ShowCompanyName", "null", true);
Note
この場合、cm は ClientScriptManager のインスタンスです。 ClientScriptManager クラスについては、このモジュールの後半で説明します。
GetCallbackEventReference には、オーバーロードされたバージョンがいくつかあります。 この場合、引数は次のようになります。
this
GetCallbackEventReference が呼び出されているコントロールへの参照。 この場合は、ページ自体です。
document.getElementById('ddlCompany').value
クライアント側のコードからサーバー側のイベントに渡される文字列引数。 この場合、Im は ddlCompany というドロップダウンの値を渡します。
ShowCompanyName
サーバー側コールバック イベントからの戻り値 (文字列) を受け取るクライアント側関数の名前。 この関数は、サーバー側のコールバックが成功した場合にのみ呼び出されます。 そのため、堅牢性のために、通常は、エラーが発生した場合に実行するクライアント側関数の名前を指定する追加の文字列引数を受け取る、オーバーロードされたバージョンの GetCallbackEventReference を使用することをお勧めします。
null
サーバーへのコールバックの前に開始したクライアント側関数を表す文字列。 この場合、このようなスクリプトは存在しないため、引数は null です。
true
コールバックを非同期的に実行するかどうかを指定するブール値。
クライアントで WebForm_DoCallback を呼び出すと、これらの引数が渡されます。 したがって、このページがクライアントにレンダリングされると、そのコードは次のようになります。
WebForm_DoCallback('__Page',document.getElementById('ddlCompany').value, ShowCompanyName,null,null,true)
クライアント上の関数のシグネチャが少し異なっている点に注意してください。 クライアント側関数は、5 つの文字列とブール値を渡します。 追加の文字列 (上記の例では null) には、サーバー側コールバックからのエラーを処理するクライアント側関数が含まれています。
手順 3: Client-Side コントロール イベントをフックする
上記の GetCallbackEventReference の戻り値が文字列変数に割り当てられていることに注意してください。 その文字列は、コールバックを開始するコントロールのクライアント側イベントをフックするために使用されます。 この例では、コールバックはページ上のドロップダウンによって開始されるため、 OnChange イベントをフックします。
クライアント側のイベントをフックするには、次のようにハンドラーをクライアント側のマークアップに追加するだけです。
// Hook the JavaScript function to the onchange event of the dropdown ddlCompany.Attributes["onchange"] = String.Format("javascript:{0}", cbRef);
cbRef は GetCallbackEventReference の呼び出しからの戻り値であることを思い出してください。 上に示したWebForm_DoCallbackの呼び出しが含まれています。
手順 4: Client-Side スクリプトを登録する
GetCallbackEventReference の呼び出しで、サーバー側のコールバックが成功したときに ShowCompanyName というクライアント側スクリプトが実行されることを指定したことを思い出してください。 そのスクリプトは、ClientScriptManager インスタンスを使用してページに追加する必要があります。 (ClientScriptManager クラスについては、このモジュールの後半で説明します)。次のように行います。
System.Text.StringBuilder clientScript = new System.Text.StringBuilder(""); ClientScriptManager cm = Page.ClientScript; // Create the client script clientScript.Append("function ShowCompanyName(companyName)"); clientScript.Append("{"); clientScript.Append("document.getElementById('CoClicked').innerHTML = \"You chose \" + companyName + \".\";"); clientScript.Append("}"); cm.RegisterClientScriptBlock(this.GetType(), "showCo", clientScript.ToString(), true);
手順 5: ICallbackEventHandler インターフェイスのメソッドを呼び出す
ICallbackEventHandler には、コードに実装する必要がある 2 つのメソッドが含まれています。 RaiseCallbackEvent と GetCallbackEvent です。
RaiseCallbackEvent は引数として文字列を受け取り、何も返しません。 string 引数は、クライアント側の呼び出しから WebForm_DoCallback に渡されます。 この場合、その値は ddlCompany というドロップダウンの value 属性です。 サーバー側のコードは RaiseCallbackEvent メソッドに配置する必要があります。 たとえば、コールバックが外部リソースに対して WebRequest を作成している場合は、そのコードを RaiseCallbackEvent に配置する必要があります。
GetCallbackEvent は、クライアントへのコールバックの戻り値を処理します。 引数を受け取り、文字列を返します。 返される文字列は、クライアント側の関数 (この場合は ShowCompanyName) に引数として渡されます。
上記の手順を完了すると、ASP.NET 2.0 でスクリプト コールバックを実行する準備が整います。
![A S P ドット NET 2 ポイント 0 でスクリプト コールバックを実行するビデオ チュートリアルのスクリーンショット。[Microsoft] ドロップダウンが強調表示されています。](the-asp-net-2-0-page-model/_static/image4.png)
ASP.NET のスクリプト コールバックは、XMLHttp 呼び出しの作成をサポートするすべてのブラウザーでサポートされています。 これには、現在使用されているすべての最新のブラウザーが含まれます。 インターネット エクスプローラーは XMLHttp ActiveX オブジェクトを使用し、他の最新のブラウザー (今後の IE 7 を含む) では組み込みの XMLHttp オブジェクトを使用します。 ブラウザーがコールバックをサポートしているかどうかをプログラムで判断するには、 Request.Browser.SupportCallback プロパティを使用します。 要求側クライアントがスクリプト コールバックをサポートしている場合、このプロパティは true を返します。
ASP.NET 2.0 でのクライアント スクリプトの操作
ASP.NET 2.0 のクライアント スクリプトは、ClientScriptManager クラスを使用して管理されます。 ClientScriptManager クラスは、型と名前を使用してクライアント スクリプトを追跡します。 これにより、同じスクリプトがプログラムによってページに複数回挿入されるのを防ぐことができます。
Note
ページにスクリプトが正常に登録されると、その後同じスクリプトを登録しようとすると、スクリプトが 2 回目に登録されなくなります。 重複するスクリプトは追加されません。例外は発生しません。 不要な計算を回避するために、スクリプトが既に登録されているかどうかを判断するために使用できるメソッドがあり、複数回登録を試みないようにします。
ClientScriptManager のメソッドは、現在のすべての ASP.NET 開発者にとってよく知られている必要があります。
RegisterClientScriptBlock
このメソッドは、レンダリングされたページの上部にスクリプトを追加します。 これは、クライアントで明示的に呼び出される関数を追加する場合に便利です。
このメソッドには、2 つのオーバーロードされたバージョンがあります。 4 つの引数のうち 3 つが一般的です。 これらは次のとおりです。
type (string)
type 引数は、スクリプトの型を識別します。 一般に、ページの型 (これは) を使用することをお勧めします。型の GetType())。
key (string)
key 引数は、スクリプトのユーザー定義キーです。 これは、スクリプトごとに一意である必要があります。 既に追加されているスクリプトと同じキーと種類のスクリプトを追加しようとすると、追加されません。
script (string)
script 引数は、追加する実際のスクリプトを含む文字列です。 StringBuilder を使用してスクリプトを作成し、StringBuilder で ToString() メソッドを使用して スクリプト 引数を割り当てることをお勧めします。
3 つの引数のみを受け取るオーバーロードされた RegisterClientScriptBlock を使用する場合は、スクリプトにスクリプト要素 (<スクリプト> と </script>) を含める必要があります。
4 番目の引数を受け取る RegisterClientScriptBlock のオーバーロードを使用することもできます。 4 番目の引数はブール型 (Boolean) で、スクリプト要素 ASP.NET 追加するかどうかを指定します。 この引数が true の場合、スクリプトにはスクリプト要素を明示的に含めないようにしてください。
スクリプトが既に登録されているかどうかを判断するには、IsClientScriptBlockRegistered メソッドを使用します。 これにより、既に登録されているスクリプトを再登録しようとするのを回避できます。
RegisterClientScriptInclude (2.0 の新機能)
RegisterClientScriptInclude タグは、外部スクリプト ファイルにリンクするスクリプト ブロックを作成します。 これには 2 つのオーバーロードがあります。 1 つはキーと URL を受け取ります。 2 つ目は、型を指定する 3 番目の引数を追加します。
たとえば、次のコードは、アプリケーションの scripts フォルダーのルートにあるjsfunctions.jsにリンクするスクリプト ブロックを生成します。
ClientScriptManager cm = Page.ClientScript; if(!cm.IsClientScriptIncludeRegistered("jsfunc")) { cm.RegisterClientScriptInclude(this.GetType(), "jsfunc", "/scripts/jsfunctions.js"); }
このコードは、レンダリングされたページで次のコードを生成します。
<script src="/scripts/jsfunctions.js" type="text/javascript"></script>
Note
スクリプト ブロックは、ページの下部にレンダリングされます。
IsClientScriptIncludeRegistered メソッドを使用して、スクリプトが既に登録されているかどうかを確認します。 これにより、スクリプトの再登録を回避できます。
RegisterStartupScript
RegisterStartupScript メソッドは、RegisterClientScriptBlock メソッドと同じ引数を受け取ります。 RegisterStartupScript に登録されたスクリプトは、ページが読み込まれた後、OnLoad クライアント側イベントの前に実行されます。 1.X では、RegisterStartupScript に登録されたスクリプトは閉じる </form> タグの直前に配置され、RegisterClientScriptBlock に登録されたスクリプトは開始 <フォーム> タグの直後に配置されました。 ASP.NET 2.0 では、両方とも /form> タグを閉じる<直前に配置されます。
Note
RegisterStartupScript に関数を登録した場合、その関数はクライアント側コードで明示的に呼び出すまで実行されません。
IsStartupScriptRegistered メソッドを使用して、スクリプトが既に登録されているかどうかを判断し、スクリプトの再登録を回避します。
その他の ClientScriptManager メソッド
ClientScriptManager クラスの他の便利なメソッドをいくつか次に示します。
| GetCallbackEventReference | このモジュールの「スクリプト コールバック」を参照してください。 |
|---|---|
| GetPostBackClientHyperlink | クライアント側のイベントからポストバックするために使用できる JavaScript 参照 (javascript:<call>) を取得します。 |
| GetPostBackEventReference | クライアントからポストバックを開始するために使用できる文字列を取得します。 |
| GetWebResourceUrl | アセンブリに埋め込まれているリソースへの URL を返します。 RegisterClientScriptResource と組み合わせて使用する必要があります。 |
| RegisterClientScriptResource | Web リソースをページに登録します。 これらはアセンブリに埋め込まれており、新しい WebResource.axd ハンドラーによって処理されるリソースです。 |
| RegisterHiddenField | 非表示のフォーム フィールドをページに登録します。 |
| RegisterOnSubmitStatement | HTML フォームの送信時に実行されるクライアント側コードを登録します。 |
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示