Vue d'ensemble du cycle de vie des pages ASP.NET
Mise à jour : novembre 2007
Lorsqu'une page ASP.NET s'exécute, elle parcourt un cycle de vie au cours duquel elle exécute une série d'étapes de traitement. Ces étapes sont l'initialisation, l'instanciation des contrôles, la restauration et la conservation de l'état, l'exécution du code du gestionnaire d'événements et le rendu. Il est important que vous compreniez le cycle de vie de la page afin pouvoir écrire le code à l'étape précise du cycle de vie correspondant à l'effet que vous comptez obtenir. En outre, si vous développez des contrôles personnalisés, vous devez maîtriser suffisamment le cycle de vie de la page pour savoir initialiser des contrôles, remplir des propriétés de contrôle avec des données d'état d'affichage et exécuter tout code de comportement de contrôles. (Le cycle de vie d'un contrôle est basé sur celui de la page, mais la page déclenche davantage d'événements pour un contrôle qu'il n'y a d'événements disponibles pour une page ASP.NET seule).
Étapes globales du cycle de vie de la page
De façon générale, la page passe par les étapes décrites dans le tableau suivant. En plus des étapes du cycle de vie de la page, il existe des étapes d'application qui surviennent avant et après une demande sans être spécifiques à une page. Pour plus d'informations, consultez Vue d'ensemble du cycle de vie des applications ASP.NET pour IIS 5.0 et 6.0.
Étape |
Description |
---|---|
Demande de page |
La demande de page intervient avant que le cycle de vie de la page ne commence. Lorsque la page est demandée par un utilisateur, ASP.NET détermine si elle doit être analysée et compilée (déclenchant ainsi la vie de la page), ou s'il est possible de répondre à la demande en transmettant une version de la page mise en cache sans exécuter la page. |
Démarrage |
Pendant l'étape de démarrage, les propriétés de page telles que Request et Response sont définies. À ce stade, la page détermine également si la demande est une publication (postback) ou une nouvelle demande et définit la propriété IsPostBack. En outre, la propriété UICulture de la page est, elle aussi, définie lors de l'étape de démarrage. |
Initialisation de la page |
Pendant l'initialisation de la page, les contrôles présents dans la page sont disponibles et la propriété UniqueID de chaque contrôle est définie. Les thèmes éventuels sont également appliqués à la page. Si la demande actuelle est une publication, les données de publication n'ont pas encore été chargées et les valeurs de propriété des contrôles n'ont pas été ramenées à celles de l'état d'affichage. |
Chargement |
Pendant l'étape de chargement, si la demande actuelle est une publication, les propriétés des contrôles sont chargées à l'aide des informations récupérées dans l'état d'affichage et l'état du contrôle. |
Validation |
Pendant l'étape de validation, la méthode Validate de tous les contrôles validateurs est appelée, ce qui définit la propriété IsValid de chaque contrôle validateur et de la page. |
Gestion d'événements de publication |
Si la demande est une publication, tous les gestionnaires d'événements sont appelés. |
Rendu |
Avant le rendu, l'état d'affichage est enregistré pour la page et tous les contrôles. Pendant la phase de rendu, la page appelle la méthode Render pour chaque contrôle, en fournissant un writer de texte qui écrit sa sortie dans le OutputStream de la propriété Response de la page. |
Déchargement |
Le déchargement est appelé lorsque la page a été entièrement rendue, transmise au client et se trouve prête à être supprimée. À ce stade, les propriétés de page telles que Response et Request sont déchargées et le nettoyage éventuel est exécuté. |
Événements du cycle de vie
À chaque étape du cycle de vie d'une page, celle-ci déclenche des événements que vous pouvez gérer pour exécuter votre code utilisateur. Pour les événements de contrôle, vous devez lier le gestionnaire d'événements à l'événement, soit de façon déclarative à l'aide d'attributs tels que onclick, soit dans le code.
Les pages prennent également en charge le rattachement automatique aux événements (AutoEventWireup), ce qui signifie qu'ASP.NET recherche les méthodes portant certains noms et les exécute automatiquement lorsque certains événements sont déclenchés. Si l'attribut AutoEventWireup de la directive @ Page a la valeur true (ou s'il n'est pas défini, puisqu'il a par défaut la valeur true), les événements de page sont automatiquement liés aux méthodes qui utilisent la convention d'affectation de noms de Page_event, par exemple Page_Load et Page_Init. Pour plus d'informations sur le rattachement automatique aux événements, consultez Modèle d'événements du contrôle serveur Web ASP.NET.
Le tableau suivant répertorie les événements de cycle de vie de la page que vous utiliserez le plus souvent. Il existe davantage d'événements que ceux qui sont répertoriés ; toutefois, ils ne sont pas utilisés par la plupart des scénarios de traitement. Ils sont plutôt utilisés surtout par les contrôles serveur de la page ASP.NET pour s'initialiser et s'afficher. Si vous envisagez d'écrire vos propres contrôles serveur ASP.NET, vous devrez connaître ces étapes de façon plus approfondie. Pour plus d'informations sur la création de contrôles personnalisés, consultez Développement de contrôles serveur ASP.NET personnalisés.
Événement Page |
Utilisation courante |
---|---|
Utilisez cet événement dans les cas suivants :
|
|
Déclenché après que tous les contrôles ont été initialisés et tous les paramètres d'apparence ont été appliqués. Utilisez cet événement pour lire ou initialiser des propriétés de contrôle. |
|
Déclenché par l'objet Page. Utilisez cet événement pour les tâches de traitement qui nécessitent que toute initialisation soit terminée. |
|
Utilisez cet événement si vous devez exécuter un traitement sur votre page ou contrôle avant l'événement Load. Après avoir déclenché cet événement, la Page charge l'état d'affichage pour elle-même et tous les contrôles, puis traite toutes les données de publication incluses avec l'instance Request. |
|
La Page appelle la méthode d'événement OnLoad sur la Page, puis effectue la même opération de manière récursive pour chaque contrôle enfant, qui fait de même pour chacun de ses contrôles enfants jusqu'à ce que la page et tous les contrôles soient chargés. Utilisez la méthode d'événement OnLoad pour définir des propriétés dans les contrôles et établir des connexions de base de données. |
|
Événements de contrôle |
Utilisez ces événements pour gérer des événements de contrôle spécifiques, tels que l'événement Click d'un contrôle Button ou l'événement TextChanged d'un contrôle TextBox. |
Utilisez cet événement pour les tâches qui requièrent que tous les autres contrôles de la page soient chargés. |
|
Avant que cet événement ne se produise :
L'événement PreRender se produit pour chaque contrôle de la page. Utilisez l'événement pour apporter des modifications définitives au contenu de la page ou de ses contrôles. |
|
Avant que cet événement ne se produise, ViewState a été enregistré pour la page et pour tous les contrôles. Toute modification apportée à la page ou aux contrôles à ce stade sera ignorée. Utilisez cet événement pour effectuer des tâches qui requièrent l'enregistrement de l'état d'affichage, mais qui n'apportent aucune modification aux contrôles. |
|
Il ne s'agit pas d'un événement ; au lieu de cela, l'objet Page appelle cette méthode sur chaque contrôle à ce stade du traitement. Tous les contrôles serveur Web ASP.NET ont une méthode Render qui écrit le balisage du contrôle qui est envoyé au navigateur. Si vous créez un contrôle personnalisé, vous substituez en général cette méthode pour renvoyer le balisage du contrôle. Toutefois, si votre contrôle personnalisé incorpore uniquement des contrôles serveur Web ASP.NET standard et aucun balisage personnalisé, vous n'avez pas besoin de substituer la méthode Render. Pour plus d'informations, consultez Développement de contrôles serveur ASP.NET personnalisés. Un contrôle utilisateur (un fichier .ascx) incorporant automatiquement le rendu, vous n'avez pas besoin de restituer explicitement le contrôle dans le code. |
|
Cet événement se produit pour chaque contrôle, puis pour la page. Dans les contrôles, utilisez cet événement pour effectuer un dernier nettoyage pour des contrôles spécifiques, par exemple la fermeture des connexions de base de données spécifiques aux contrôles. Pour la page elle-même, utilisez cet événement pour effectuer un dernier nettoyage, par exemple la fermeture des connexions de base de données et des fichiers ouverts, ou la fin de journalisation ou d'autres tâches spécifiques à la demande.
Remarque :
Pendant l'étape de déchargement, la page et ses contrôles ont été rendus. Vous ne pouvez donc pas apporter de modifications supplémentaires au flux de réponse. Si vous essayez d'appeler une méthode telle que la méthode Response.Write, la page lèvera une exception.
|
Considérations supplémentaires sur le cycle de vie d'une page
Les contrôles serveur ASP.NET ont leur propre cycle de vie, semblable au cycle de vie d'une page. Par exemple, les événements Init et Load d'un contrôle se produisent au cours des événements de page correspondants.
Même si Init et Load se produisent de manière récursive sur chaque contrôle, ils surviennent dans l'ordre inverse. L'événement Init (et également l'événement Unload) pour chaque contrôle enfant se produit avant que l'événement correspondant ne soit déclenché pour son conteneur (de bas en haut). Toutefois, l'événement Load pour un conteneur se produit avant les événements Load pour ses contrôles enfants (de haut en bas).
Vous pouvez personnaliser l'apparence ou le contenu d'un contrôle en gérant les événements pour le contrôle, tels que l'événement Click pour le contrôle Button et l'événement SelectedIndexChanged pour le contrôle ListBox. Dans certaines circonstances, vous pourrez également gérer les événements DataBinding ou DataBound d'un contrôle. Pour plus d'informations, consultez les rubriques de références de la classe sur les contrôles individuels et Développement de contrôles serveur ASP.NET personnalisés.
Lorsque vous héritez d'une classe de la classe Page, outre la gestion des événements déclenchés par la page, vous pouvez substituer les méthodes de la classe de base de la page. Par exemple, vous pouvez substituer la méthode InitializeCulture de la page pour définir dynamiquement des informations de culture. Notez que lors de la création d'un gestionnaire d'événements à l'aide de la syntaxe Page_event, l'implémentation de base est appelée implicitement. Vous n'avez donc pas besoin de l'appeler dans votre méthode. Par exemple, la méthode OnLoad de la classe de la page de base est toujours appelée, que vous ayez ou non créé une méthode Page_Load. Cependant, si vous substituez la méthode OnLoad de la page avec le mot clé override (Overrides en Visual Basic), vous devez appeler explicitement la méthode de base. Par exemple, si vous substituez la méthode OnLoad dans la page, vous devez appeler base.Load (MyBase.Load en Visual Basic) pour pouvoir exécuter l'implémentation de base.
Événements de rattrapage pour les contrôles ajoutés
Si les contrôles sont créés de façon dynamique au moment de l'exécution ou de façon déclarative dans les modèles de contrôles liés aux données, leurs événements ne sont pas synchronisés initialement avec ceux d'autres contrôles de la page. Par exemple, pour un contrôle qui est ajouté au moment de l'exécution, les événements Init et Load peuvent se produire plus tard dans le cycle de vie de la page que les mêmes événements pour les contrôles créés de façon déclarative. Par conséquent, à partir du moment où ils sont instanciés, les contrôles ajoutés de façon dynamique et ceux des modèles déclenchent leurs événements l'un après l'autre jusqu'à ce qu'ils soient au niveau de l'événement pendant lequel ils ont été ajoutés à la collection Controls.
En général, vous n'avez pas à vous en soucier si vous n'avez pas de contrôles liés aux données imbriqués. Si un contrôle enfant a été lié aux données, mais que son contrôle conteneur n'a pas encore été lié aux données, les données dans le contrôle enfant et les données dans son contrôle conteneur peuvent être mal synchronisées. Tel est notamment le cas si les données dans le contrôle enfant exécutent le traitement selon une valeur liée aux données dans le contrôle conteneur.
Par exemple, supposez que vous avez un GridView qui affiche un enregistrement de société sur chaque ligne avec une liste des responsables de société dans un contrôle ListBox. Pour remplir la liste des responsables, vous liez le contrôle ListBox à un contrôle de source de données (tel que SqlDataSource) qui récupère les données du responsable de la société à l'aide des informations CompanyID dans une requête.
Si les propriétés de liaison de données du contrôle ListBox, telles que DataSourceID et DataMember, sont définies de façon déclarative, le contrôle ListBox essaiera de créer une liaison à sa source de données pendant l'événement DataBinding de la ligne conteneur. Toutefois, le champ CompanyID de la ligne ne contient pas de valeur jusqu'à ce que l'événement RowDataBound du contrôle GridView se produise. Dans ce cas, le contrôle enfant (le contrôle ListBox) étant lié avant le contrôle conteneur (le contrôle GridView), leurs étapes de liaison de données sont mal synchronisées.
Pour éviter cette condition, placez le contrôle de source de données pour le contrôle ListBox dans le même élément de modèle que le contrôle ListBox lui-même et ne définissez pas de façon déclarative les propriétés de liaison de données du ListBox. À la place, définissez-les par programme au moment de l'exécution pendant l'événement RowDataBound, afin que le contrôle ListBox ne soit pas lié à ses données tant que les informations CompanyID ne sont pas disponibles.
Pour plus d'informations, consultez Liaison à des données à l'aide d'un contrôle de source de données.
Événements de liaison de données pour les contrôles liés aux données
Pour vous aider à comprendre la relation entre le cycle de vie de la page et les événements de liaison de données, le tableau suivant répertorie les événements liés aux données dans les contrôles liés aux données, tels que les contrôles GridView, DetailsView et FormView.
Événement de contrôle |
Utilisation courante |
---|---|
Cet événement est déclenché par les contrôles liés aux données avant l'événement PreRender du contrôle conteneur (ou de l'objet Page) et marque le début de la liaison du contrôle aux données. Utilisez cet événement pour ouvrir manuellement les connexions de base de données, si nécessaire. (Les contrôles de source de données rendent souvent cette opération inutile.) |
|
RowCreated (GridView uniquement) ou ItemCreated (contrôles DataList, DetailsView, SiteMapPath, DataGrid, FormView, Repeater et ListView) |
Utilisez cet événement pour manipuler le contenu indépendant de la liaison de données. Par exemple, vous pouvez ajouter par programme la mise en forme à un en-tête ou une ligne de pied de page dans un contrôle GridView au moment de l'exécution. |
RowDataBound (GridView uniquement) ou ItemDataBound (contrôles DataList, SiteMapPath, DataGrid, Repeater et ListView ) |
Lorsque cet événement se produit, les données étant disponibles dans la ligne ou l'élément, vous pouvez mettre en forme des données ou définir la propriété FilterExpression sur les contrôles de source de données enfants pour afficher les données associées dans la ligne ou l'élément. |
Cet événement marque la fin des opérations de liaison de données dans un contrôle lié aux données. Dans un contrôle GridView, la liaison de données est terminée pour toutes les lignes et tous les contrôles enfants. Utilisez cet événement pour mettre en forme le contenu lié aux données ou initialiser la liaison de données dans d'autres contrôles qui dépendent des valeurs du contenu du contrôle actuel. (Pour plus d'informations, consultez « Événements de rattrapage pour les contrôles ajoutés », plus haut dans cette rubrique.) |
Événements des contrôles de connexion
Le contrôle Login peut utiliser des paramètres du fichier Web.config pour gérer automatiquement l'authentification d'appartenance. Toutefois, si votre application vous demande de personnaliser le fonctionnement du contrôle ou si vous voulez comprendre comment les événements de contrôle Login se rapportent au cycle de vie de la page, vous pouvez utiliser les événements répertoriés dans le tableau suivant.
Événement de contrôle |
Utilisation courante |
---|---|
Cet événement est déclenché pendant une publication, après que l'événement LoadComplete de la page s'est produit. Il marque le début du processus de connexion. Utilisez cet événement pour les tâches qui doivent se produire avant le début du processus d'authentification. |
|
Cet événement est déclenché après l'événement LoggingIn. Utilisez cet événement pour substituer ou améliorer le comportement d'authentification par défaut d'un contrôle Login. |
|
Cet événement est déclenché après l'authentification du nom d'utilisateur et du mot de passe. Utilisez cet événement pour rediriger vers une autre page ou définir de façon dynamique le texte dans le contrôle. Cet événement ne se produit pas en cas d'erreur ou d'échec de l'authentification. |
|
Cet événement est déclenché si l'authentification a échoué. Utilisez cet événement pour définir le texte dans le contrôle qui explique le problème ou diriger l'utilisateur vers une page différente. |
Voir aussi
Concepts
Modèle d'événements du contrôle serveur Web ASP.NET
Contexte de page et d'application dans les applications Web ASP.NET
Vue d'ensemble de l'état d'affichage ASP.NET
Liaison à des données à l'aide d'un contrôle de source de données
Référence
Validation des entrées d'utilisateur dans des pages Web ASP.NET
Vue d'ensemble des contrôles de connexion ASP.NET