ASP.NET-Pageのライフサイクル
4584 ワード
初期化(Initialization)
ページが要求するとき、最初に実行される常に構造関数(constructor).ここでは、カスタムプロパティやオブジェクトを初期化できます.しかし、pageはまだ完全に初期化されていないため、ここにはいくつかの制限があります.特に、HttpContextを使用する必要があります.Currentは、QueryString、Form、Cookiesコレクション、およびCacheオブジェクトにアクセスします.Sessionオブジェクトはconstructorではアクセスできません.
次に、pageを構成するすべてのサブコントロールをコントロールセットツリーに追加するAddParsedSubObjectメソッドを実行します.多くの高度なページテンプレートソリューションでは、この方法は通常、ページのコントロールを特殊なページテンプレートに追加するために上書きされます.この方法は再帰的な布団コントロール呼び出しであり,これらのサブコントロールはすべてこのときに初期化され,一番奥から始まる.
続いてDeterminePostBackModeメソッドです.この方法では、IsPostBackの値と関連するイベントに影響を与えることができます.データベースからViewStateをロードしてredirectする場合は、これが役に立つかもしれません.ViewStateはIsPostBackがtrueの場合にのみ復元されるためです.nullを返すことでpostbackを強制したり、Requestを返したりすることができます.強制するんだこの方法は、特別な場合を除き、他のイベントにも影響を与えるため、使用を推奨しません.
そしてOnInitメソッドです.通常、これは私たちが使用した最初の方法です.このとき、すべてのコントロールが初期化され、つまりすべての元の値が設定されます.ViewStateや他のpostの値はまだコントロールに適用されていません.すなわち,この時点でコードやユーザ操作によるすべての変更はまだ復元されていない.これは、通常、ダイナミックコントロールを作成または再作成するのに最適なタイミングです.
リカバリとロード(Restore and Load)
次のLoadPageStateFromPersistenceMediumメソッドは、PostBackでのみ実行されます.ViewStateを保存する方法を変更する場合(Sessionまたは他のカスタム保存方法を使用する)、この方法を上書きし、後のSavePageStateToPersistenceMedium方法を使用します.注:このメソッドは、ViewStateをpageおよびそのサブコントロールに実際にロードしません.
ViewStateが取り戻すと、LoadViewStateメソッドはそれらをpageに復元し、各サブコントロール(PostBackのもののみ)に再帰的に復元する.このとき、各コントロールは最後に実行された状態に復元されたが、ユーザpostの値はまだ適用されていない.これはViewStateに属しているからです.この方法は、イベントで作成されたすべてのダイナミックコントロールを復元する最良のタイミングです.
次はProcessPostDataメソッドです.PostBackでのみ実行されます.ページベースクラスで実装されるプライベートメソッドであるため、このメソッドは上書きできません.この方法は最終的にユーザpostの値をコントロールの名前に一致する方法でページに復元する.この時、pageは完全に回復しました.ダイナミックコントロールは、このメソッドの前に作成する必要があります.この方法は、後でchangedイベントにコントロール値の変更を記録することもできます.
そしてオンロード方法です.ほとんどのコードでは、pageのライフサイクルで最初のすべての値が復元された場所であるため、この方法が使用されています.IsPostBackプロパティをチェックすることで、不要なリセット状態を回避できます.また、IsValidプロパティを確認して検証することもできます.また、ここでダイナミックコントロールを作成することもできます.これらのコントロールのメソッドはすべて実行され、ViewStateを含む取得されます.しかし、再送の値はできません.
Raised Events
次のメソッド、ProcessPostDataメソッドは、実際には前のメソッドの2番目のエントリ(second pass)です.再送のみを処理し,プライベートメソッドであるため上書きできない.この方法は少しおかしいように見えますが、必要です.OnLoadメソッドで再構築されたダイナミックコントロールには、再送する値が必要です.このメソッドの後に作成されたすべてのダイナミックコントロールは、ViewStateのみがリカバリされ、再送された値はリカバリされず、変更イベントはトリガーされません.
次の方法は、RaiseChangedEventsであり、同様に再送時にのみ使用される.これはベースクラス実装のプライベートメソッドです.このときchangedイベントは本当にトリガーされます.これは,前のProcessPostDataメソッドで落札された返信の値の違いに基づいている.複数のchangedイベントがトリガーされると、その前後順は保証されません.
次はRaisePostBackEventメソッドです.再送にのみ使用され、ベースクラス実装のプライベートメソッドです.これはpostbackでない限り、formを本当にコミットする方法です.たとえば、ボタンやjavascriptでコミットされた他のコントロールがトリガーされます.Validatorsを使用している場合、手動でValidateメソッドを呼び出さない場合は、すでに呼び出されています.ieのバグにより、イベントを起こさずにフォームがコミットされる場合があります.
続いてOnPrenderメソッドです.これは、通常、ブラウザに描画される前にpageとそのサブコントロールを変更する最後の機会です.ここでダイナミックコントロールを作成することもできます.ただし、この場合はViewStateのみがキャプチャされ、posted valuesは受け入れられず、イベントはありません.上述ieのバグのため、ここではトリガイベントのないpost backをキャプチャするために用いることができる.
保存と描画(Save and Render)
次はSaveViewStateメソッドです.気にするかどうかにかかわらず各サブコントロールに再帰的に適用されます.ViewStateは一般的にaspxページとは異なるすべての属性を保存し、コードによってもユーザーによっても変更されます.注意:コントロールの値は、コントロールツリー内の位置によって保存されるため、その後にダイナミックコントロールを誤った位置に追加すると、ViewStateがクラッシュする可能性があります.
次はSavePageStateToPersistenceMediumメソッドです.それは本当にpageのViewStateを保存します.この方法はカバーできる.書き直すなら、ここはasp.Netのバグは、手動で設定する必要があります_VIEWSTATE、空の値でも.
続いてRenderメソッドです.各サブコントロールに再帰的に呼び出し、それぞれのhtmlを実際に描画し、ブラウザに送信します.一部のページテンプレートスキームでは、一般的なヘッダーとfooterをここに追加することが多い.サーバコントロールを使用しないでください.ここでできる変更は純粋なhtmlでなければならないことに注意してください.この時点でコントロールはすでに描画されているからです.
最後にOnUnloadメソッドです.Disposeメソッドを呼び出します.この方法は、ページで使用される非管理リソースをクリーンアップするために使用できます.特に、開いているファイルやデータベース接続を閉じるのと同様です.この方法は、ページがクライアントブラウザに送信された場合にのみ発生します.したがって、サービス側のオブジェクトにのみ機能します.だから彼はpageのtraceに表示されません.
上がpageのライフサイクルです.上記の手順は、新しいリクエストがあるたびに繰り返されます.
Listing 1:Pageのイベントのまとめ
Method
PostBack
Controls
Constructor
Always
All
AddParsedSubObject
Always
All
DeterminePostBackMode
Always
Page
OnInit
Always
All
LoadPageStateFromPersistenceMedium
PostBack
Page
LoadViewState
PostBack
All
ProcessPostData1
PostBack
Page
OnLoad
Always
All
ProcessPostData2
PostBack
Page
RaiseChangedEvents
PostBack
Page
RaisePostBackEvent
PostBack
Page
OnPreRender
Always
All
SaveViewState
Always
All
SavePageStateToPersistenceMedium
Always
Page
Render
Always
All
OnUnload
Always
All
原文:http://www.cnblogs.com/dudu/articles/118917.html
ページが要求するとき、最初に実行される常に構造関数(constructor).ここでは、カスタムプロパティやオブジェクトを初期化できます.しかし、pageはまだ完全に初期化されていないため、ここにはいくつかの制限があります.特に、HttpContextを使用する必要があります.Currentは、QueryString、Form、Cookiesコレクション、およびCacheオブジェクトにアクセスします.Sessionオブジェクトはconstructorではアクセスできません.
次に、pageを構成するすべてのサブコントロールをコントロールセットツリーに追加するAddParsedSubObjectメソッドを実行します.多くの高度なページテンプレートソリューションでは、この方法は通常、ページのコントロールを特殊なページテンプレートに追加するために上書きされます.この方法は再帰的な布団コントロール呼び出しであり,これらのサブコントロールはすべてこのときに初期化され,一番奥から始まる.
続いてDeterminePostBackModeメソッドです.この方法では、IsPostBackの値と関連するイベントに影響を与えることができます.データベースからViewStateをロードしてredirectする場合は、これが役に立つかもしれません.ViewStateはIsPostBackがtrueの場合にのみ復元されるためです.nullを返すことでpostbackを強制したり、Requestを返したりすることができます.強制するんだこの方法は、特別な場合を除き、他のイベントにも影響を与えるため、使用を推奨しません.
そしてOnInitメソッドです.通常、これは私たちが使用した最初の方法です.このとき、すべてのコントロールが初期化され、つまりすべての元の値が設定されます.ViewStateや他のpostの値はまだコントロールに適用されていません.すなわち,この時点でコードやユーザ操作によるすべての変更はまだ復元されていない.これは、通常、ダイナミックコントロールを作成または再作成するのに最適なタイミングです.
リカバリとロード(Restore and Load)
次のLoadPageStateFromPersistenceMediumメソッドは、PostBackでのみ実行されます.ViewStateを保存する方法を変更する場合(Sessionまたは他のカスタム保存方法を使用する)、この方法を上書きし、後のSavePageStateToPersistenceMedium方法を使用します.注:このメソッドは、ViewStateをpageおよびそのサブコントロールに実際にロードしません.
ViewStateが取り戻すと、LoadViewStateメソッドはそれらをpageに復元し、各サブコントロール(PostBackのもののみ)に再帰的に復元する.このとき、各コントロールは最後に実行された状態に復元されたが、ユーザpostの値はまだ適用されていない.これはViewStateに属しているからです.この方法は、イベントで作成されたすべてのダイナミックコントロールを復元する最良のタイミングです.
次はProcessPostDataメソッドです.PostBackでのみ実行されます.ページベースクラスで実装されるプライベートメソッドであるため、このメソッドは上書きできません.この方法は最終的にユーザpostの値をコントロールの名前に一致する方法でページに復元する.この時、pageは完全に回復しました.ダイナミックコントロールは、このメソッドの前に作成する必要があります.この方法は、後でchangedイベントにコントロール値の変更を記録することもできます.
そしてオンロード方法です.ほとんどのコードでは、pageのライフサイクルで最初のすべての値が復元された場所であるため、この方法が使用されています.IsPostBackプロパティをチェックすることで、不要なリセット状態を回避できます.また、IsValidプロパティを確認して検証することもできます.また、ここでダイナミックコントロールを作成することもできます.これらのコントロールのメソッドはすべて実行され、ViewStateを含む取得されます.しかし、再送の値はできません.
Raised Events
次のメソッド、ProcessPostDataメソッドは、実際には前のメソッドの2番目のエントリ(second pass)です.再送のみを処理し,プライベートメソッドであるため上書きできない.この方法は少しおかしいように見えますが、必要です.OnLoadメソッドで再構築されたダイナミックコントロールには、再送する値が必要です.このメソッドの後に作成されたすべてのダイナミックコントロールは、ViewStateのみがリカバリされ、再送された値はリカバリされず、変更イベントはトリガーされません.
次の方法は、RaiseChangedEventsであり、同様に再送時にのみ使用される.これはベースクラス実装のプライベートメソッドです.このときchangedイベントは本当にトリガーされます.これは,前のProcessPostDataメソッドで落札された返信の値の違いに基づいている.複数のchangedイベントがトリガーされると、その前後順は保証されません.
次はRaisePostBackEventメソッドです.再送にのみ使用され、ベースクラス実装のプライベートメソッドです.これはpostbackでない限り、formを本当にコミットする方法です.たとえば、ボタンやjavascriptでコミットされた他のコントロールがトリガーされます.Validatorsを使用している場合、手動でValidateメソッドを呼び出さない場合は、すでに呼び出されています.ieのバグにより、イベントを起こさずにフォームがコミットされる場合があります.
続いてOnPrenderメソッドです.これは、通常、ブラウザに描画される前にpageとそのサブコントロールを変更する最後の機会です.ここでダイナミックコントロールを作成することもできます.ただし、この場合はViewStateのみがキャプチャされ、posted valuesは受け入れられず、イベントはありません.上述ieのバグのため、ここではトリガイベントのないpost backをキャプチャするために用いることができる.
保存と描画(Save and Render)
次はSaveViewStateメソッドです.気にするかどうかにかかわらず各サブコントロールに再帰的に適用されます.ViewStateは一般的にaspxページとは異なるすべての属性を保存し、コードによってもユーザーによっても変更されます.注意:コントロールの値は、コントロールツリー内の位置によって保存されるため、その後にダイナミックコントロールを誤った位置に追加すると、ViewStateがクラッシュする可能性があります.
次はSavePageStateToPersistenceMediumメソッドです.それは本当にpageのViewStateを保存します.この方法はカバーできる.書き直すなら、ここはasp.Netのバグは、手動で設定する必要があります_VIEWSTATE、空の値でも.
続いてRenderメソッドです.各サブコントロールに再帰的に呼び出し、それぞれのhtmlを実際に描画し、ブラウザに送信します.一部のページテンプレートスキームでは、一般的なヘッダーとfooterをここに追加することが多い.サーバコントロールを使用しないでください.ここでできる変更は純粋なhtmlでなければならないことに注意してください.この時点でコントロールはすでに描画されているからです.
最後にOnUnloadメソッドです.Disposeメソッドを呼び出します.この方法は、ページで使用される非管理リソースをクリーンアップするために使用できます.特に、開いているファイルやデータベース接続を閉じるのと同様です.この方法は、ページがクライアントブラウザに送信された場合にのみ発生します.したがって、サービス側のオブジェクトにのみ機能します.だから彼はpageのtraceに表示されません.
上がpageのライフサイクルです.上記の手順は、新しいリクエストがあるたびに繰り返されます.
Listing 1:Pageのイベントのまとめ
Method
PostBack
Controls
Constructor
Always
All
AddParsedSubObject
Always
All
DeterminePostBackMode
Always
Page
OnInit
Always
All
LoadPageStateFromPersistenceMedium
PostBack
Page
LoadViewState
PostBack
All
ProcessPostData1
PostBack
Page
OnLoad
Always
All
ProcessPostData2
PostBack
Page
RaiseChangedEvents
PostBack
Page
RaisePostBackEvent
PostBack
Page
OnPreRender
Always
All
SaveViewState
Always
All
SavePageStateToPersistenceMedium
Always
Page
Render
Always
All
OnUnload
Always
All
原文:http://www.cnblogs.com/dudu/articles/118917.html