Exporter (0) Imprimer
Développer tout

Modèle d'événements du contrôle serveur Web ASP.NET

Mise à jour : novembre 2007

Une fonctionnalité importante d'ASP.NET est qu'il vous permet de programmer des pages Web en utilisant un modèle basé sur des événements similaire à celui des applications clientes. À titre d'exemple simple, vous pouvez ajouter un bouton à une page Web ASP.NET, puis écrire un gestionnaire d'événements pour l'événement Click du bouton. Bien que cette pratique soit courante dans les pages Web qui utilisent exclusivement un script client (gestion de l'événement onclick du bouton en DHTML), ASP.NET apporte ce modèle au traitement serveur.

Les événements déclenchés par les contrôles serveur ASP.NET fonctionnent quelque peu différemment des événements des pages HTML habituelles ou des applications Web clientes. La différence est principalement liée au fait que l'événement lui-même est séparé de l'emplacement où l'événement est géré. Dans les applications clientes, les événements sont déclenchés et gérés sur le client. Dans les pages Web ASP.NET, toutefois, les événements associés aux contrôles serveur proviennent du client (navigateur), mais sont gérés sur le serveur Web par la page ASP.NET.

Pour les événements déclenchés sur le client, le modèle d'événement de contrôle Web ASP.NET requiert que les informations sur l'événement soient capturées sur le client et qu'un message d'événement soit transmis au serveur, via une publication HTTP. La page doit interpréter la publication pour déterminer l'événement qui s'est produit, puis appeler la méthode appropriée de votre code sur le serveur afin de gérer l'événement.

ASP.NET se charge de capturer, transmettre et interpréter l'événement. Lorsque vous créez des gestionnaires d'événements dans une page Web ASP.NET, vous pouvez généralement le faire sans vous préoccuper de la façon dont les informations sur l'événement sont capturées et rendues disponibles pour votre code. Vous devez, plutôt, créer les gestionnaires d'événements de la même façon que vous le feriez pour un formulaire client traditionnel. Cependant, vous devez être conscient de certains aspects de la gestion d'événements dans les pages Web ASP.NET.

La plupart des événements Web ASP.NET nécessitant un aller-retour vers le serveur pour être traités, ils peuvent avoir une influence sur les performances d'une page. En conséquence, les contrôles serveur offrent un jeu limité d'événements, généralement des événements de type Click uniquement. Certains contrôles serveur prennent en charge des événements de modification. Par exemple, le contrôle serveur Web CheckBox déclenche un événement CheckedChanged dans le code serveur lorsque l'utilisateur clique sur la zone. Certains contrôles serveur prennent en charge des événements plus abstraits. Par exemple, le contrôle serveur Web Calendar déclenche un événement SelectionChanged qui est une version plus abstraite de l'événement Click.

Les événements qui se produisent fréquemment (et peuvent être déclenchés sans que l'utilisateur ne le sache), comme un événement onmouseover, ne sont pas pris en charge pour les contrôles serveur. Les contrôles serveur ASP.NET peuvent toujours appeler des gestionnaires côté client pour ces événements, comme il est expliqué ultérieurement sous Modèle d'événements du contrôle serveur Web ASP.NET.

Les contrôles et la page elle-même déclenchent également des événements de cycle de vie à chaque étape du traitement, comme Init, Load et PreRender. Vous pouvez tirer parti de ces événements de cycle de vie dans votre application. Par exemple, vous pouvez définir des valeurs par défaut pour les contrôles dans l'événement Load d'une page.

Les événements de pages et de contrôles ASP.NET serveur obéissent à un modèle .NET Framework standard pour les méthodes de gestionnaires d'événements. Tous les événements passent deux arguments : un objet représentant l'objet ayant déclenché l'événement et un objet événement contenant des informations propres à l'événement. Le second argument est généralement du type EventArgs, mais, dans le cas de certains contrôles, d'un type spécifique à ce contrôle. Par exemple, pour un contrôle serveur Web ImageButton, le second argument est du type ImageClickEventArgs, qui comporte des informations sur les coordonnées de l'endroit où l'utilisateur a cliqué.

y3bwdsh3.alert_note(fr-fr,VS.100).gifRemarque :

Les événements de la page (par exemple, l'événement Load de la page) peuvent accepter les deux arguments standard, mais aucune valeur n'est passée dans ces arguments.

Dans les contrôles serveur, certains événements, généralement des événements Click, entraînent la publication immédiate de la page sur le serveur. Les événements de modification dans les contrôles serveur HTML et les contrôles serveur Web, comme le contrôle TextBox, n'entraînent pas une publication immédiate. En revanche, ils sont déclenchés lors de la prochaine publication.

y3bwdsh3.alert_note(fr-fr,VS.100).gifRemarque :

Si le navigateur le prend en charge, les contrôles de validation peuvent vérifier les entrées d'utilisateur à l'aide d'un script client, sans aller-retour sur le serveur. Pour plus d'informations, consultez Validation des entrées d'utilisateur dans des pages Web ASP.NET.

Une fois la page publiée, les événements d'initialisation (Page_Init et Page_Load) de la page sont déclenchés, puis les événements de contrôle sont traités. Ne créez pas une logique d'application qui s'appuie sur les événements de modification déclenchés dans un ordre particulier, à moins que vous n'ayez une connaissance approfondie du traitement des événements de page. Pour plus d'informations, consultez Vue d'ensemble du cycle de vie des pages ASP.NET.

Si cela est utile pour votre application, vous pouvez spécifier que les événements de modification provoquent la publication de la page. Les contrôles serveur Web qui prennent en charge un événement de modification comportent une propriété AutoPostBack. Quand cette propriété a la valeur true, l'événement de modification du contrôle entraîne la publication immédiate de la page, sans attendre un événement Click. Par exemple, par défaut, l'événement CheckedChanged d'un contrôle CheckBox n'entraîne pas l'envoi de la page. Toutefois, si vous affectez la valeur true à la propriété AutoPostBack du contrôle, la page est envoyée au serveur pour être traitée dès qu'un utilisateur clique sur la case à cocher.

y3bwdsh3.alert_note(fr-fr,VS.100).gifRemarque :

Pour que la propriété AutoPostBack fonctionne correctement, le navigateur de l'utilisateur doit être configuré pour autoriser les scripts. Il s'agit du paramètre par défaut dans la plupart des cas. Cependant, certains utilisateurs désactivent les scripts pour des raisons de sécurité. Pour plus d'informations, consultez Script client dans les pages Web ASP.NET.

Les contrôles serveur Web tels que Repeater, DataList, GridView, FormView et DetailsView, peuvent contenir des contrôles de bouton qui déclenchent eux-mêmes des événements. Par exemple, chaque ligne d'un contrôle GridView peut contenir un ou plusieurs boutons créés dynamiquement par les modèles.

Au lieu que chaque bouton ne déclenche un événement, les événements des contrôles imbriqués sont envoyés au contrôle conteneur. Le conteneur déclenche ensuite un événement ItemCommand générique avec les paramètres qui vous permettent de découvrir le contrôle ayant déclenché l'événement d'origine. En répondant à ce seul événement, vous évitez de devoir écrire des gestionnaires d'événements pour les contrôles enfants.

L'événement ItemCommand contient les deux arguments d'événements standard, un objet faisant référence à la source de l'événement et un objet événement contenant les informations propres à l'événement.

y3bwdsh3.alert_note(fr-fr,VS.100).gifRemarque :

Les contrôles GridView, DataList et autres contrôles de données prennent en charge des événements supplémentaires, comme EditCommand, DeleteCommand et UpdateCommand, qui constituent des cas particuliers d'événements envoyés.

À l'aide des boutons, vous pouvez utiliser la propriété CommandArgument pour passer une chaîne spécifiée par l'utilisateur au gestionnaire d'événements pour vous permettre d'identifier le bouton qui a déclenché l'événement. Par exemple, dans un contrôle DataList, les boutons déclenchent l'événement ItemCommand. Vous pouvez affecter à la propriété CommandArgument de chaque bouton une valeur différente, par exemple celle d'un bouton est "ShowDetails" et celle d'un autre est "AddToShoppingCart", puis capturer ultérieurement ces valeurs dans le gestionnaire d'événements.

Un événement est un message tel que « l'utilisateur a cliqué sur un bouton », par exemple. Dans votre application, le message doit être traduit dans un appel de méthode dans votre code. La liaison entre le message d'événement et une méthode spécifique, c'est-à-dire un gestionnaire d'événements, s'effectue à l'aide d'un délégué d'événement. Pour plus d'informations, consultez Événements et délégués.

Dans les pages Web ASP.NET, vous ne devez pas coder explicitement les délégués si le contrôle est créé de façon déclarative (dans la balise) sur la page. La liaison d'événements peut être effectuée de plusieurs façons, en fonction de l'événement que vous liez et du langage de programmation que vous utilisez. Pour plus d'informations, consultez Comment : créer des gestionnaires d'événements dans les pages Web ASP.NET.

Liaison des événements de contrôle

Pour les contrôles déclarés sur la page, vous pouvez lier un événement à une méthode en définissant un attribut (propriété) dans la balise du contrôle. L'exemple de code suivant explique comment lier l'événement Click d'un contrôle Button ASP.NET à une méthode nommée ButtonClick.

<asp:button id="SampleButton" runat="server" 
   text="Submit" onclick="ButtonClick" />

Lorsque la page est compilée, ASP.NET recherche une méthode nommée ButtonClick et confirme que la méthode a la signature appropriée (il accepte deux arguments, un de type Object et un autre de type EventArgs). ASP.NET lie automatiquement l'événement à la méthode.

En Visual Basic, vous pouvez également lier des événements aux méthodes à l'aide du mot clé Handles dans la déclaration de gestionnaire d'événements, comme dans l'exemple de code suivant :

Private Sub ButtonClick(ByVal sender As System.Object, _
    ByVal e As System.EventArgs) Handles SampleButton.Click

Liaison des événements de page

Les pages ASP.NET déclenchent des événements de cycle de vie, tels que Init, Load, PreRender et autres. Par défaut, vous pouvez lier des événements de page aux méthodes à l'aide d'une convention d'affectation de noms de Page_eventname. Par exemple, pour créer un gestionnaire pour l'événement Load de la page, vous pouvez créer une méthode nommée Page_Load. Au moment de la compilation, ASP.NET recherchera des méthodes en fonction de cette convention d'affectation de noms et exécutera automatiquement la liaison entre l'événement et la méthode. Vous pouvez utiliser la convention de Page_eventname pour tout événement exposé par la classe Page.

y3bwdsh3.alert_note(fr-fr,VS.100).gifRemarque :

Les méthodes de gestion d'événements de page ne requièrent pas d'arguments.

Si vous le souhaitez, vous pouvez créer les gestionnaires explicitement. La liaison automatique des événements de page en fonction de la convention d'affectation de noms est contrôlée par une propriété de page nommée AutoEventWireup. Par défaut, cette propriété a la valeur true, et ASP.NET exécute la recherche automatique et la liaison décrite plus haut. Vous pouvez également affecter la valeur false à cette propriété en ajoutant l'attribut AutoEventWireup=false dans la directive @ Page. Vous pouvez créer ensuite des méthodes portant un nom quelconque et les lier explicitement aux événements de page. En Visual Basic, vous pouvez utiliser le mot clé Handles, comme dans l'exemple de code suivant :

Sub MyPageLoad(sender As Object, e As EventArgs) Handles MyBase.Load

L'inconvénient de l'attribut AutoEventWireup est qu'il exige que les gestionnaires d'événements de page aient des noms spécifiques et prévisibles. Cela restreint vos choix de noms à affecter à vos gestionnaires d'événements.

y3bwdsh3.alert_note(fr-fr,VS.100).gifRemarque :

Si vous incluez la liaison explicite pour les événements de page, vérifiez bien que la propriété AutoEventWireup a la valeur false afin que la méthode ne soit pas appelée deux fois par inadvertance.

Liaison explicite pour les contrôles dynamiques

Si vous créez des contrôles en les déclarant dans la balise, vous pouvez lier des événements aux méthodes à l'aide d'un attribut (par exemple, onclick) ou en Visual Basic, en utilisant le mot clé Handles. Si vous créez des contrôles dynamiquement (dans le code), vous ne pouvez pas utiliser l'une ou l'autre de ces méthodes, parce que le compilateur n'a pas de référence au contrôle au moment de la compilation.

Dans ce cas, vous devez utiliser la liaison d'événements explicite. En Visual Basic, vous pouvez utiliser l'instruction AddHandler pour lier un événement dans un contrôle créé dynamiquement à une méthode existante. En C#, vous créez un délégué et l'associez à l'événement du contrôle. L'exemple de code suivant explique comme vous pouvez lier une méthode nommée ButtonClick à l'événement Click d'un bouton :

Button b = new Button;
b.Text = "Click";
b.Click += new System.EventHandler(ButtonClick);
Placeholder1.Controls.Add(b);

Cette rubrique a expliqué comment utiliser les événements déclenchés dans le code serveur. Les contrôles restituent des éléments au navigateur, et ces éléments peuvent également déclencher des événements côté client que vous pouvez gérer dans le script client. À l'aide du script client, vous pouvez ajouter la gestion d'événements de souris et de clavier aux contrôles serveur ASP.NET. Pour plus d'informations, consultez Script client dans les pages Web ASP.NET et Comment : ajouter des événements de script client à des contrôles serveur Web ASP.NET.

Outre les événements de contrôle et de page, l'infrastructure de page ASP.NET vous permet d'utiliser des événements de cycle de vie qui peuvent être déclenchés lorsque votre application démarre ou s'arrête, ou qu'une session utilisateur particulière démarre ou s'arrête :

  • Les événements d'application sont déclenchés pour toute demande adressée à une application. Par exemple, l'événement BeginRequest de l'objet HttpApplication (Application_BeginRequest) est déclenché lors d'une demande de page Web ASP.NET ou de service Web XML dans votre application. Cet événement permet d'initialiser les ressources qui seront utilisées pour chaque demande adressée à l'application. Un événement correspondant, l'événement EndRequest de l'objet HttpApplication (Application_EndRequest), vous fournit la possibilité de fermer ou de supprimer les ressources utilisées pour la demande.

  • Les événements de session sont comparables aux événements d'application (événement Start et événement End), mais ils sont déclenchés avec chaque session unique de l'application. Une session commence quand un utilisateur demande une page de votre application pour la première fois et se termine quand votre application ferme explicitement la session ou quand celle-ci dépasse le délai imparti.

    y3bwdsh3.alert_note(fr-fr,VS.100).gifRemarque :

    L'événement Session_End n'est pas déclenché dans tous les cas. Pour plus d'informations, consultez End.

Vous pouvez créer des gestionnaires pour ces types d'événements dans le fichier Global.asax. Pour plus d'informations, consultez Vue d'ensemble du cycle de vie des applications ASP.NET pour IIS 5.0 et 6.0 et Syntaxe du fichier Global.asax.

Ajouts de la communauté

AJOUTER
Afficher:
© 2014 Microsoft