L'échantillon de code suivant utilise la propriété Application de l'objet Page pour ajouter un nom et une valeur à l'objet Application et affiche la valeur dans un contrôle d'étiquette. Etant donné que toutes les propriétés de l'objet Page sont présentées directement à l'ensemble des codes associés à la page, il n'est pas nécessaire de nommer de façon explicite la classe Page (c'est à dire, Page.Application ) pour accéder à la propriété Application.

Bien qu'il soit possible de récupérer une référence d'objet locale à l'instance HttpApplicationState pour l'application, l'exemple ci-après montre que la manière la plus fréquente d'utiliser cette propriété consiste à y accéder directement par le biais de la propriété Application.

L'échantillon de code suivant ajoute deux paires de noms et de valeurs à l'objet Cache à l'aide de la propriété Cache de la classe Page et affiche les valeurs dans un contrôle d'étiquette utilisant la propriété Page object's Cache:

Comme dans le cas de l'objet Application, il est plus fréquent d'accéder directement à l'objet Cache par le biais de la propriété Cache que par l'obtention d'une référence d'objet locale à l'instance Cache de l'application. Le chapitre 13 examine les cas dans lesquels il est préférable d'utiliser le Cache ASP.NET plutôt que la collection d'états Application, et inversement. La classe Cache comprend les éléments suivants:

L'échantillon de code suivant initialise la propriété ClientTarget de la classe Page à  downlevel, tout en indiquant que ASP.NET doit représenter la page pour un type de navigateur inconnu, avec pour résultat un document compatible HTML 3.2 . L'exemple affiche ensuite un message indiquant si oui ou non un ensemble de paramètres est pris en charge. Dans le cas de downlevel, aucun des paramètres indiqués n'est pris en charge.

Le ClientTarget peut également être spécifié à l'aide de l'attribut ClientTarget ou de la directive @ Page . Si l'on change la valeur de la propriété ClientTarget dans l'exemple en ie4, le résultat indiquera que tous les paramètres de la liste sont pris en charge.

Même si la plupart des contrôles de serveur retournent du HTML 3.2 pour l'ensemble des navigateurs, les contrôles de validation constituent un exemple de contrôles qui réagissent de façon différente, en fonction de la valeur de ClientTarget considérée. Si la propriété ClientTarget a pour valeur downlevel, la validation a lieu du côté serveur, ce qui signifie que si l'on voit la source, aucun script côté-client n'effectuera la validation. Si ClientTarget a pour valeur uplevel, les contrôles de validation émettent du JavaScript côté-client pour effectuer une validation côté-client également.

L'échantillon de code suivant utilise la propriété Context pour retourner le nom de l'utilisateur actuellement connecté. Il est également possible de se procurer cette donnée à partir de la propriété de la classe Page provenant du HttpContext associé à la requête actuelle.

Une utilisation fréquente de cette propriété consiste à fournir une référence au HttpContext de la requête actuelle à un objet business souhaitant accéder aux objets ASP.NET intrinsèques (requête, réponse, etc.). Outre un accès aux valeurs intrinsèques d'application, de requête, de réponse, de serveur et de session, la classe HttpContext fournit un accès aux informations en matière de Trace et d'Utilisateur pour la requête HTTP actuelle.

L'échantillon de code suivant confère à EnableViewState la valeur False à l'aide de l'attribut EnableViewState de la directive @ Page et affiche les valeurs correspondantes sur la page:

L'exemple ci-après montre qu'il est également possible de spécifier la propriété EnableViewState à l'aide de l'attribut EnableViewState de la directive @ Page . On peut constater les effets de la propriété EnableViewState en examinant le HTML source d'une page à l'aide d'une fonction View Source de navigateur. Si la propriété EnableViewState a pour valeur False, le code source aura l'aspect suivant:

<input type="hidden" name="_  _VIEWSTATE"
       value="dDwxMDA3MzE2MzEyOzs+" />

Si la propriété EnableViewState a pour valeur True, le code source aura l'aspect suivant:

<input type="hidden" name="_  _VIEWSTATE"
value="dDwxMDA3MzE2MzEyO3Q8O2w8aTwxPjs+O2w8dDw7bDxpPDM+Oz47bDx0PHA8cDxsPF
RleHQ7PjtsPFZhbHVlIG9mIHRoZSBFbmFibGVWaWV3U3RhdGUgcHJvcGVydHkgaXMgVHJ1ZTs
+Pjs+Ozs+Oz4+Oz4+Oz4=" />

Les caractères supplémentaires de la valeur du champ masqué _ _VIEWSTATE indiquent l'état d'affichage de la page actuelle. L'état d'affichage de la page contient les propriétés transitoires des contrôles de serveur, comme BackColor ou ForeColor. Veuillez noter que les pages non dotées d'un élément <form> contenant l'attribut runat="server" n'enregistreront pas l'état d'affichage, quelle que soit la valeur de la propriété EnableViewState.

L'exemple ci-dessous modifie la propriété ErrorPage et affiche le résultat de la page en cas d'exception liée à une absence de traitement:

Sub Page_Load(  )
   Page.ErrorPage = "ErrorPage_Handler.aspx"
   Dim x, y, overflow As Integer
   x = 1
   y = 0
   overflow = x/y
   'This code will not be executed
   Message.Text = "Error Page is " & Page.ErrorPage & "."
End Sub

Le Page_Load pour ErrorPage_Handler.aspx figure ci-dessous:

Sub Page_Load(  )
   Message.Text = "We're sorry. An error occurred during the" & _
      " processing of your request. Please try again later."
End Sub

Il est également possible de spécifier la propriété ErrorPage à l'aide de l'attribut ErrorPage de la directive de @ Page .

L'échantillon de code ci-dessous utilise la propriété IsPostBack pour afficher différents messages dans le contrôle Label, selon que la page est chargée pour la première fois ou en tant que résultat du postback client. Lors du premier chargement de la page, la propriété IsPostBack retourne la valeur False, ce qui entraîne l'affichage de la chaîne "Non-PostBack". Le fait de cliquer sur le bouton force à nouveau la page à s'auto-appliquer et amène le retour de la valeur True par IsPostBack, ainsi que l'affichage de la chaîne "PostBack".

La propriété IsPostBack affichera une valeur True uniquement dans le cas des pages contenant un élément <form> doté de l'attribut runat="server" et d'au moins un contrôle générateur de postback. Il peut s'agir d'un contrôle Button, comme l'illustre l'exemple présenté ci-dessus, ou d'un autre contrôle, de type DropDownList par exemple, et dont la propriété AutoPostBack a pour valeur True .

L'exemple utilise la propriété IsValid pour déterminer si la validation de la page actuelle a réussi ou non et affiche un message:

La propriété IsValid sert à déterminer si le processus général de validation effectué par un contrôle de programme de validation de formulaire a réussi ou pas. Si la page ne comporte pas de contrôles de programmes de validation, la valeur de la propriété est toujours True . Avant de vérifier la valeur de IsValid, vous devez soit invoquer la méthode Page.Validate, comme l'illustre l'exemple présenté ci-dessus, soit avoir soumis la page à un contrôle (de type Button, ImageButton ou LinkButton) dont la propriété CausesValidation a pour valeur True . Sinon, une exception se produira.

Dans l'exemple en question, la propriété EnableClientScript du contrôle RequiredFieldValidator a pour valeur False, ce qui désactive la validation côté-client. Par défaut, la validation côté-client est activée et la page n'est jamais soumise au serveur si la validation échoue. Les navigateurs de haut niveau effectuent une validation du client à l'aide de scripts côté-client, et ce n'est qu'en cas de succès de la validation que la soumission de la page a lieu. Il faut attendre la soumission de la page pour que le code de traitement d'événement côté-serveur soit exécuté et que le message soit affiché en fonction de la valeur de la propriété IsValid.

Il est important de vérifier la propriété IsValid, que la validation côté-client soit activée ou non, étant donné qu'il se peut qu'un client mal intentionné contourne la validation côté-client.

Les échantillons de code suivants utilisent la collection ServerVariables de l'objet HttpRequest pour afficher l'adresse IP du client qui formule la requête:

Comme dans le cas des propriétés Application et Cache, bien qu'il soit possible de récupérer une référence locale à l'instance HttpRequest associée à la requête, il est plus fréquent d'accéder à l'instance directement à l'aide de la propriété Request, comme l'illustre l'exemple présenté ci-dessus.

L'exemple suivant utilise la propriété Response de la page objet pour donner à la propriété ContentType de la classe HttpResponse la valeur text/xml . Le fait de définir cette propriété entraîne l'affichage du résultat de la page sous forme de balisage XML dans les versions 5.0 et suivantes de Microsoft Internet Explorer.

Comme dans le cas des propriétés Application et Cache, bien qu'il soit possible de récupérer une référence locale à l'instance HttpResponse associée à la requête, il est plus fréquent d'accéder à cette instance directement à l'aide de la propriété Request, comme l'illustre l'exemple présenté ci-dessus.

L'échantillon de code suivant utilise la propriété Server pour accéder à la méthode HtmlEncode de la classe HttpServerUtility, qui permet d'encoder des balises et des caractères HTML tels qu'ils apparaîtront aux utilisateurs, plutôt que de confier leur interprétation et leur représentation au navigateur:

Sub Page_Load(  )
   Message.Text = Server.HtmlEncode("<em>Hello, World!</em>")
End Sub

Le HTML présenté par cette page aurait l'aspect suivant:

<html>
   <head>
      <title>Server property example</title>
   </head>
<body>
   <span id="Message">&lt;em&gt;Hello, World!&lt;/em&gt;</span>
</body>
</html>

Comme dans le cas des propriétés Requête et Réponse, bien qu'il soit possible de récupérer une référence locale à l'instance HttpServerUtility associée à la requête, il est plus fréquent d'accéder à cette instance directement à l'aide de la propriété Server, comme l'illustre l'exemple présenté ci-dessus.

L'exemple utilise l'objet Session pour afficher la valeur de la propriété Mode, qui indique l'endroit où les informations concernant l'état de la session sont conservées:

Comme dans le cas des propriétés Requête et Réponse, bien qu'il soit possible de récupérer une référence locale à l'instance HttpSessionState associée à la requête, il est plus fréquent d'accéder à cette instance directement à l'aide de la propriété Session, comme l'illustre l'exemple présenté ci-dessus.

L'échantillon de code suivant confère à la propriété SmartNavigation la valeur True à l'aide de l'attribut SmartNavigation de la directive @ Page . Une fois la page réappliquée, seule la page actuelle sera conservée dans l'historique du navigateur et le bouton Retour sera par conséquent désactivé.

En plus d'éliminer le tremblement en cours de navigation ou de réapplication, SmartNavigation conserve la position actuelle du défilement en cas de réapplication d'une page et ne garde qu'une seule page dans l'historique du navigateur, ce qui empêche les utilisateurs de cliquer sur le bouton Retour du navigateur pour récupérer un état antérieur de la page. Même s'il est possible de définir cette propriété à partir du code, il est recommandé de le faire à l'aide de l'attribut SmartNavigation de la directive @ Page, comme l'illustre l'exemple présenté ci-dessus.

L'exemple déclenche le suivi par voie logicielle à l'aide de la propriété Trace de la classe Page :

Comme dans le cas des propriétés Requête et Réponse, bien qu'il soit possible de récupérer une référence locale à l'instance TraceContext associée à la requête, il est plus fréquent d'accéder à cette instance directement à l'aide de la propriété Trace, comme l'illustre l'exemple présenté ci-dessus. Pour plus de détails concernant le suivi d'application, reportez-vous au chapitre 10.

Cet exemple obtient le statut d'authentification et le nom de l'utilisateur à l'aide de la propriété User et l'affiche dans le navigateur:

Afin de peupler l'objet IPrincipal retourné par la propriété User, il faut prévoir une procédure d'authentification, soit dans machine.config, soit dans web.config, et définir au moins une règle d'authentification qui élimine la possibilité d'une utilisation anonyme. Dans le cas contraire, la propriété IsAuthenticated de l'objet IIdentity renverra la valeur False et la propriété Name renverra une chaîne vide.

L'échantillon de code suivant détermine la propriété ForeColor du contrôle Message, puis enregistre la valeur de cette couleur dans l'instance StateBag ViewState. Si la page est réappliquée, le code récupère la couleur enregistrée et, en fonction du nom de la couleur, la fait passer de Red à  Black, ou inversement.

En plus d'un outil de gestion automatique de l'état des contrôles de serveurs, ViewState constitue l'endroit idéal pour la gestion de l'état ambiant des pages entre chaque requête. Non seulement la classe StateBag conserve les types de données d'origine comme les nombres entiers et les chaînes, mais elle peut aussi servir à enregistrer les objets, pourvu qu'ils soient sérialisables, comme c'est le cas de la structure Color dans l'exemple ci-joint. Lors de l'enregistrement d'un objet sérialisable dans ViewState, l'état de l'objet est automatiquement numérisé sous une forme susceptible d'être enregistrée dans ViewState et dessérialisé sous forme d'instance d'objet lorsqu'on refait appel à l'objet.

Etant donné que ViewState n'enregistre aucune information de type avec l'objet, il faut configurer l'objet récupéré dans ViewState avec le type approprié. Dans notre exemple, le type considéré est System.Drawing.Color. Finalement, réfléchissez bien avant d'enregistrer de gros objets (comme les ensembles de données) dans ViewState. Etant donné que ViewState est conservé en tant que champ masqué, il est envoyé au navigateur avec chaque requête. L'enregistrement de gros objets dans ViewState aura pour effet d'augmenter les temps de chargement des pages.

L'exemple de code utilise la propriété Controls pour afficher la propriété Count de l'instance de classe ControlCollection associée à la page. Puis il ajoute un nouveau contrôle Label à la collection et affiche la propriété Count mise à jour à l'aide de la nouvelle étiquette.

Comme dans le cas des propriétés Session et Trace, bien qu'il soit possible de récupérer une référence locale à l'instance Controls associée à la page, l'exemple ci-joint montre qu'il est plus fréquent d'accéder à cette instance directement à l'aide de la propriété Controls.

Veuillez noter qu'en cas d'ajout d'un contrôle à une page qui en contient déjà , le fait d'utiliser la méthode AddAt de la classe ControlCollection permet un placement plus précis du contrôle qu'avec la méthode Add, qui se contente de placer le contrôle à la fin de la collection. Dans cet exemple, l'utilisation de la méthode Add method aurait pour effet de faire apparaître le contrôle Label supplémentaire après la balise de fin de page </html>, ce qui ne se fait pas en HTML et pourait entraîner des problèmes de présentation dans certains navigateurs.

L'échantillon de code affiche un contrôle Textbox avec contrôles RequiredFieldValidator et RegularExpressionValidator joints. Dans Page_Load, le code se répète au travers de la variable ValidatorCollection retournée par la propriété Validators et affiche l'ID et la propriété ErrorMessage de chaque programme de validation de la collection:

Etant donné que seules sont affichées les propriétés des contrôles de programme de validation qui sont hérités du contrôle BaseValidator (duquel provient l'ensemble des contrôles de validation), il n'est pas nécessaire de paramétrer le programme de validation de façon particulière avant d'accéder aux propriétés. Cependant, si l'on veut afficher une propriété qui soit propre au type de programme de validation utilisé (comme la propriété ValidationExpression de la classe RegularExpressionValidator ), il faudra paramétrer le contrôle de façon appropriée. Dans Visual Basic .NET, cela se fait à l'aide du mot clé CType .

L'échantillon de code suivant utilise une expression de liaison de données pour appliquer l'attribut ForeColor d'une balise de contrôle d'étiquette à la valeur de la variable locale dénommée couleur. Quand on invoque la méthode DataBind dans in Page_Load, la valeur de la variable Color est assignée à l'attribut ForeColor (ce qui revient effectivement à définir la propriété ForeColor sous forme de code):

Si vous souhaitez effectuer une liaison de données sur un contrôle spécifique de la page, comme DataGrid ou DataList, il peut s'avérer plus efficace d'invoquer DataBind sur ce contrôle plutôt que sur la page, étant donné que le fait de l'invoquer sur le contrôle évitera d'avoir à se préoccuper d'invoquer DataBind sur des contrôles pour lesquels la liaison de données n'est pas nécessaire.

L'exemple suivant montre comment trouver un contrôle à l'aide de son ID et changer la couleur d'arrière-plan correspondante:

La méthode FindControl, qui est héritée de la classe Control (dont provient la classe Page ), est utile lors de l'utilisation de contrôles imbriqués ou de contrôles d'utilisateur appelés à manipuler un contrôle dans leur page parent. Par exemple, le code contenu dans un contrôle d'utilisateur pourra invoquer FindControl sur la page contenant le contrôle d'utilisateur pour localiser et manipuler un contrôle contenu dans la page (mais en dehors du contrôle d'utilisateur).

L'échantillon de code affiche un message indiquant si oui ou non la page comporte des contrôles dans sa collection Controls, en fonction de la valeur retournée par HasControls:

L'exemple utilise le LoadControl pour charger un contrôle d'utilisateur en cours d'exécution et l'ajoute à la collection Controls de la page:

Sub Page_Load(  )
   Dim Hello As UserControl = LoadControl("hello.ascx")
   Page.Controls.Add(Hello)
End Sub

Le contrôle d'utilisateur hello.ascx a l'aspect suivant:

<h1>Hello, World!</h1>

Dans l'exemple suivant, on relie le chemin virtuel de la page nommée à son chemin physique:

La méthode Page.MapPath dédouble la fonctionnalité de la méthode Server.MapPath.

L'exemple relie l'URL relative actuelle à une URL complète:

Reportez-vous à l'exemple concernant la propriété IsValid.

La méthode Validate est invoquée de façon automatique dès que l'utilisateur clique sur un contrôle HTML ou ASP dont la propriété CausesValidation est True .

L'échantillon de code suivant génère délibérément une exception de type overflow, puis la traite dans le programme Page_Error, en affichant de façon temporaire le texte de l'exception:

L'exception actuelle est obtenue à l'aide de la méthode GetLastError de la classe Server . Une fois le traitement de votre erreur terminé, vous pouvez soit effacer l'exception en invoquant Server.ClearError, comme dans l'exemple ci-joint, soit permettre à l'exception de gagner le niveau suivant de traitement d'erreur. On observera que les arguments Sender et e sont optionnels pour cet événement, comme dans l'exemple ci-joint. Si l'attribut AutoEventWireup de la directive @ Page a la valeur True (par défaut), ASP.NET invoquera de façon automatique le gestionnaire d'événement correspondant, pourvu qu'il soit doté de la signature Page_Error appropriée.

L'échantillon de code initialise une variable pour définir la propriété ForeColor d'une étiquette dans Page_Init, puis modifie cette valeur pour définir la propriété ForeColor d'une autre étiquette dans Page_Load:

On observera que les arguments Sender et e sont optionnels pour cet événement, comme dans l'exemple ci-joint. Si l'attribut AutoEventWireup de la directive @ Page a la valeur True (par défaut), ASP.NET invoquera de façon automatique le gestionnaire d'événement correspondant, pourvu qu'il soit doté de la signature Page_Init.

Reportez-vous à l'exemple concernant Init.

On observera que les arguments Sender et e sont optionnels pour cet événement, comme dans l'exemple ci-joint. Si l'attribut AutoEventWireup de la directive @ Page a la valeur True (par défaut), ASP.NET invoquera de façon automatique le gestionnaire d'événement correspondant, pourvu qu'il soit doté de la signature Page_Load appropriée.

Cet exemple montre l'effet de l'événement Unload en refermant un fichier affiché dans le gestionnaire d'événement Page_Load:

Alors que l'événement Unload est utile pour effectuer des tâches de nettoyage au niveau des pages, en ce qui concerne les ressources de type bases de données, pour lesquelles il se peut qu'une exception interrompe le flux normal de traitement des pages, il peut s'avérer préférable de placer le code de nettoyage de cette ressource dans le bloc Finally d'une instruction Try...Catch...Finally, ce qui garantira l'exécution systématique du code de nettoyage. Pour plus de détaisl concernant Try...Catch...Finally, reportez-vous au chapitre 10. On observera sur cet exemple que les arguments Sender et e sont optionnels dans le cas de cet événement. Si l'attribut AutoEventWireup de la directive @ Page a la valeur True (par défaut), ASP.NET invoquera de façon automatique le gestionnaire d'événement correspondant, pourvu qu'il soit doté de Page_Unload.