Upload
vuongkhanh
View
236
Download
0
Embed Size (px)
Citation preview
Page 1 / 2
Objectifs :
Connaître le fonctionnement du langage ASP.NET
Apprendre à développer des applications Web
Développer des services We
ASP.NET 2.0 – Applications Web Essentiel
Version : 0.9
ID Booster : 697
Release Date : 05/09/2008
Sommaire
1. INTRODUCTION À ASP.NET 2.0 ................................................................................................................. 3
1.1. GENERALITES .................................................................................................................................................. 3 1.2. TRAITEMENT DES REQUETES ............................................................................................................................ 3 1.3. NOTION DE CODE-BEHIND ET COMPILATION ..................................................................................................... 4 1.4. ASP.NET ET VISUAL STUDIO .......................................................................................................................... 6 1.5. CYCLE DE VIE .................................................................................................................................................. 8 1.6. OBJETS SERVEUR ............................................................................................................................................. 8
1.6.1. L’objet Page .............................................................................................................................................. 9 1.6.2. L’objet Application .................................................................................................................................. 10 1.6.3. L’objet Session......................................................................................................................................... 11 1.6.4. L’objet Cookies ........................................................................................................................................ 11 1.6.5. L’objet Request ........................................................................................................................................ 12 1.6.6. L’objet Response ..................................................................................................................................... 12
2. CONTROLES SERVEUR.............................................................................................................................. 13
2.1. GENERALITES ................................................................................................................................................ 13 2.2. PRESENTATION DE QUELQUES CONTROLES .................................................................................................... 13 2.3. INTERACTION CLIENT/SERVER ....................................................................................................................... 14 2.4. LE PRINCIPE DE POSTBACK ............................................................................................................................ 15 2.5. VALIDATION DE CONTROLES .......................................................................................................................... 16
3. FRAMEWORK DE PAGE ............................................................................................................................ 20
3.1. LES MASTERPAGES ....................................................................................................................................... 20 3.2. STYLE, SKIN, THEMES .................................................................................................................................... 22
4. FICHIERS DE CONFIGURATION ............................................................................................................. 24
4.1. ORGANISATION DES FICHIERS ........................................................................................................................ 24 4.2. PRISE EN COMPTE DES MISES A JOUR .............................................................................................................. 24
Essentiel – ASP.NET 2.0 – Applications Web 3 / 24
1. Introduction à ASP.NET 2.0
Déjà dans sa première mouture, ASP.NET avait été conçu dans l’optique d’améliorer la productivité
des développeurs d’applications web dynamiques grâce à de nombreuses fonctionnalités telles que les
contrôles serveur utilisateur, et la possibilité d’utiliser une grande partie des langages .NET.
Dans cette seconde version, Microsoft à relevé avec succès le challenge d’augmenter la rapidité et la
simplicité de développement en diminuant jusqu'à 70% la quantité de code à écrire pour réaliser une
application web, tout en multipliant le nombre de fonctionnalités.
1.1. Généralités
L’objectif principal d’ASP.NET 2.0 est donc de simplifier grandement la réalisation d’applications
web dynamiques.
Ceci est possible, notamment grâce au concept de programmation événementielle, basé sur celui que
l’on retrouve lors du développement d’applications Windows Forms. Une page est un formulaire,
contenant des contrôles serveur (une zone de saisie de texte, un bouton, une liste, …). Chacun de ces
contrôles possède un ensemble d’événements auxquels il est possible d’associer un comportement.
Les pages ASP.NET (d’extension .aspx) vont donc contenir les différents éléments susceptibles de
générer un rendu HTML, des éléments HTML, ainsi que le code correspondant aux événements. Ce
code doit être écrit dans un des langages du Framework .NET 2.0 (C#, VB.NET, etc.).
Chaque page aspx sera compilée en une librairie (dll), et sera exécutée par la CLR (Common
Language Runtime), dans le but de générer une page HTML, qui sera renvoyée au client.
1.2. Traitement des requêtes
Lorsqu’un client appelle une page aspx, c’est le serveur web qui traite la requête. Il s’agit en général
d’un serveur IIS (Internet Information Services), mais le système de filtre ISAPI permet d’héberger de
applications web dans d’autres serveur, notamment le serveur Webdev.Webserver.EXE basé sur le
serveur Cassini, qui est utilisé pour débuguer vos applications web avec Visual Studio.
Voici un schéma simplifié du traitement d’une requête aspx par IIS 5.0 :
Essentiel – ASP.NET 2.0 – Applications Web 4 / 24
Le serveur transmet la requête au filtre ISAPI (aspnet_isapi.dll). Le filtre transmet la demande au
processus aspnet_wp.exe (qui est indépendant du serveur). aspnet_wp génére la page HTML résultant
de la requête, et la renvoie au serveur IIS par l’intermédiaire du filtre ISAPI. Enfin, la page est
retournée au client.
Toutes vos pages aspx sont compilées. Le modèle de compilation d’ASP.NET 2.0 est tel que chacune
de vos pages ne seront compilées qu’une seule fois, jusqu'à la prochaine modification des fichiers
sources.
L’avantage d’une telle solution est que seul le premier appel à une page sera long. L’inconvénient est
bien évidemment le fait que le premier utilisateur exécutant la page après une modification des sources
devra attendre le traitement de la compilation avant d’avoir une réponse.
Il existe une solution simple pour remédier à ce problème : la précompilation. Vous pouvez en effet
compiler une application web vous-même après une modification des sources. Pour cela, il suffit
d’appeler le HTTP Handler http://chemindelapplication/precompile.axd. (Un HTTP Handler est un
moyen de gérer des requêtes qui effectuent un traitement sans pour autant forcément renvoyer de code
HTML).
1.3. Notion de code-behind et compilation
Nous avons vu en introduction qu’ASP.NET utilise le mode de programmation événementielle. Le
code qui gère les événements des contrôles serveur contenus dans une page aspx peut être directement
dans cette page il est appelé code-inline. Plus généralement, ces instructions sont placées dans un
fichier à part ; on parle alors de code-behind.
Comment est-ce que cela fonctionne ? Un fichier aspx possède une directive Page. Cette directive
permet, entre autre, de configurer, via l’attribut CodePage, le chemin vers le fichier contenant le code
behind qui est nommé comme son pendant aspx, suffixé de l’extension correspondant au langage
utilisé pour l’écrire. Ce fichier contient tout simplement une classe partielle.
Par exemple, si le code behind d’une page Default.aspx est écrit en C#, le fichier contenant ce code
sera nommé Default.aspx.cs.
Essentiel – ASP.NET 2.0 – Applications Web 5 / 24
Comment se passe la compilation ?
ASP.NET 2.0 génère une classe partielle à partir du fichier aspx. Cette classe partielle ainsi que celle
contenant le code-behind sont fusionnées en une seule classe, qui dévire de System.Web.UI.Page.
Cette classe est alors compilée par ASP.NET lors de la première exécution (ou bien lors de l’appel du
Handler http precompile.axd).
Voici un schéma récapitulant ce principe :
Pour illustrer les notions de code-inline et code-behind, voici un exemple de chaque :
Code Inline <%@ Page Language="C#" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<script runat="server">
//Le code C# sera placé ici
</script>
<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
<title>Untitled Page</title>
</head>
<body>
<form id="form1" runat="server">
<div>
</div>
</form>
</body>
</html>
System.Web.UI.Page
Classe partielle contenant le code-behind
Classe partielle générée à partir du fichier .aspx
MaClasse.dll
Fusionné en une seule classe qui dérive de Page
Compilé par ASP.NET à l’exécution
Essentiel – ASP.NET 2.0 – Applications Web 6 / 24
Code Behind – Fichier Default.aspx <%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs"
Inherits="_Default" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
<title>Untitled Page</title>
</head>
<body>
<form id="form1" runat="server">
<div></div>
</form>
</body>
</html>
Code Behind – Fichier Default.aspx.cs using System;
using System.Data;
using System.Configuration;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;
public partial class _Default : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
//Le code C# placé ici s’exécutera lors du chargement
}
}
1.4. ASP.NET et Visual Studio
Visual Studio est une des raisons qui fait que créer une application web avec ASP.NET est très simple.
Il met en effet à la disposition du développeur une interface graphique pour l’organisation des
composants graphiques en Glissé/Déposé, de la même façon qu’en développement d’application
WinForms.
Visual Studio .NET 2005 apporte une différence au niveau de la création d’un site web. Ceci se fait
différemment de la création d’un projet standard, contrairement à ce que proposait la version 2003.
Essentiel – ASP.NET 2.0 – Applications Web 7 / 24
Une nouveauté non négligeable est le fait que l’on puisse choisir de développer une application web en
la stockant sur le système de fichier, et non plus uniquement via IIS :
Visual Studio créé pour vous un certain nombre de fichier et répertoire, que vous pouvez voir via
l’exploreur de solution :
Notez le répertoire App_Data qui vous permettra de stocker des bases de données.
Essentiel – ASP.NET 2.0 – Applications Web 8 / 24
1.5. Cycle de vie
Malgré ce que l’on pourrait imaginer, le cycle de vie d’une application web n’a rien à voir avec la
durée pendant laquelle une page est disponible. Il s’agit en fait de l’ensemble des étapes par lesquelles
passe une page aspx lors du traitement d’une requête.
Ces étapes peuvent être regroupées en 6 grandes parties :
- La construction :
o Correspond à l’appel des constructeurs
- L’initialisation :
o Cette étape initialise le traitement de la requête, détermine si elle est de type PostBack
ou non (cf. 2.4), spécifie la page maître (cf 3.1)
- La restauration des états :
o Comme son nom l’indique, cette étape permet de restaurer les états des différents
contrôles de la page
- Le chargement de la page :
o Cette étape déclenche entre autre, la validation des contrôles (cf.2.5). C’est également
à ce moment que sont levés les évènements de PostBack
- Sauvegarde et création du rendu des contrôles
- Finalisation :
o Cette dernière étape est destinée à la libération des ressources non managées, telles
qu’une connexion à une base de données
Connaître ce cycle de vie peut être intéressant lorsque l’on souhaite optimiser ou redéfinir un
comportement par défaut. Ces étapes étant des évènements, des méthodes y sont abonnées par défaut.
La plupart de ces méthodes sont virtuelles, vous pouvez donc en redéfinir le contenu, pour l’adapter à
vos besoins. Plutôt que de redéfinir ces méthodes, vous pouvez vous abonner à certains évènements.
1.6. Objets serveur
Dans le chapitre sur le fonctionnement d’une application Web ASP.NET, nous voyons les processus
de communication de ce type d’application, basés sur l’architecture client / serveur.
Ce type d’architecture définit les communications comme étant des messages de requêtes et de
réponses, les requêtes étant envoyées par le client et les réponses, par le serveur (dans le cadre d’une
application ASP.NET, les serveurs des Serveurs Web).
Un message de requête contient une multitude d’informations permettant au Serveur Web de traiter au
mieux la demande. Parmi les informations envoyées, on peut trouver :
L’adresse URL de la page demandée
Le nom du navigateur client
L’adresse IP du client
…
Le développeur d’une application Web peut à tout moment accéder à ces informations à partir d’objets
serveur.
Dans une application ASP.NET, l’ensemble des objets que nous utilisons sont issus de l’espace de
nom System.Web.
Cet espace de noms fournit directement des classes pour les objets Application, Cache, Cookies,
Request et Response que nous verrons dans ce chapitre.
Essentiel – ASP.NET 2.0 – Applications Web 9 / 24
Concernant les objets Session et Page, leur définition réside respectivement dans les espaces de noms
System.Web.SessionState et System.Web.UI.
N.B : Chacun des objets que nous verrons fournit des propriétés et des méthodes permettant d’accéder
à d’autres objets (entre eux). Voyons-les d’un peu plus près.
1.6.1. L’objet Page
Nous ne cessons de le répéter : en .NET tout est objet. C’est-à-dire que pour .NET, une page Web est
aussi un objet.
L’objet Page permet de contrôler l’interface utilisateur de l’application Web. Il possède également des
propriétés et des méthodes permettant d’accéder aux objets de l’interface utilisateur (Objet Cache,
Request, Response, Session, …)
Quand un message de requête est transmis au serveur Web IIS, l’information sera transmise à
ASP.NET qui créé ensuite une instance de l’objet « Page » à partir des informations reçues, puis
affiche la page.
Quand une page de l’application est demandée, ASP.NET crée une instance de la page Web, et il est
possible d’ajouter des évènements à la page afin de contrôler l’interface et d’interagir avec
l’utilisateur.
Plusieurs évènements sont disponibles pour l’objet Page. Vous pouvez les lister dans l’onglet
« Propriétés » de votre Objet Page et en cliquant sur le bouton : .
Essentiel – ASP.NET 2.0 – Applications Web 10 / 24
L’événement le plus important est l’événement « Load ». Visual Studio .Net crée d’ailleurs
automatiquement une fonction « Page_Load » associée à l’événement « Load ».
Vous pourrez initialiser à cet endroit vos composants et variables, car l’événement « Load » sera
appelé à chaque chargement de votre page.
1.6.2. L’objet Application
Dans la hiérarchie des objets d’une application Web, c’est l’objet Application qui est situé au niveau le
plus élevé. Outre la configuration de l’application et la sauvegarde des informations d’état, il fournit
des propriétés et des méthodes permettant d’accéder aux objets Request, Response, Server, Session,
etc…).
Les informations d’état ou les « variables » d’état de l’objet Application peuvent stocker des éléments
qui pourront être utilisés et exploités par tous les utilisateurs de l’application.
La classe HttpApplication fournit les méthodes, les propriétés et les évènements communs aux objets
Applications dans une application ASP.NET.
Des évènements associés à l’application ASP.NET elle-même sont définis dans le fichier
Global.asax.cs (quand vous passez au mode code du fichier Global.asax). (Nous en parlons lors de la
présentation du fichier Global.asax un peu plus haut).
Un petit exemple :
//Executé à chaque requête de l’utilisateur protected void Application_BeginRequest (Object sender, EventArgs e)
{
//si le navigateur est IE if(Request.UserAgent.IndexOf("MSIE") {
//traitement }
}
Dans l’exemple, nous utilisons les objets Request et Browser de l’objet Application afin de déterminer
si le navigateur est Internet Explorer.
Essentiel – ASP.NET 2.0 – Applications Web 11 / 24
1.6.3. L’objet Session
Nous le disions un peu plus haut, l’espace de nom System.Web.SessionState contient des classes pour
l’objet Session. Grâce à celles-ci, nous allons pouvoir gérer (créer, sauvegarder, restaurer) des
éléments à l’état de Session.
L’état de session est un état dans lequel les variables d’état (Session) stockent des éléments que l’on
souhaite stocker localement pour une session courante (Une session est propre à un utilisateur). Cet
état est pratique (par exemple pour les utilisateurs qui ne supportent pas les cookies).
Parmi les classes existantes et proposant un support de l’objet Session, il y a la classe HttpSessionState
qui permet de gérer l’état de session.
Voici un petit exemple montrant comment créer une session :
Session["MySession"] = "MyValue" ;
Outre bien sûr la création de sessions, vous allez pouvoir gérer leur durée de vie, leur mode, leur
SessionID, etc…
ASP.NET gère par défaut l’état de Session pour chaque page de votre application. Il peut être possible
parfois que certaines pages n’en aient pas besoin. Vous avez donc la possibilité de désactiver cette
fonctionnalité afin d’améliorer les performances.
L’état de Session peut être désactivé de cette façon :
- Pour une page Web :
Dans la fenêtre de Propriétés de la page, changer la valeur de la propriété
EnableSessionState à False.
- Pour toute l’application :
Dans le fichier Web.config, la balise sessionState et l’attribut mode à false
Ex : <sessionState mode="False" …
1.6.4. L’objet Cookies
L’espace de nom System.Web fournit directement des classes pour l’objet Cookies.
Pour rappel, les cookies permettent de stocker des informations sur l’ordinateur du client. Cependant,
contrairement aux sessions, les cookies peuvent être refusés par le navigateur du client. (Cela peut être
problématique lors de vos développements…).
La classe HttpCookies permet de créer et manipuler des cookies. Nous aurons aussi la possibilité avec
d’autres objets de pouvoir étendre la gestion des cookies (support des cookies, ajout des cookies dans
la collection de cookies, etc…).
Voici un exemple pouvant illustrer cet objet :
//Executé au chargement de notre page
private void Page_Load(Object sender, EventArgs e) {
//si il s’agit de la première publication de notre page
if(!IsPostBack) {
if(Request.Browser.Cookies) {//Si le browser accepte les cookies
if((Request.Cookies["MyCookie"]) != null) { //si cookie existe
//traitement
} else {
//on créé le cookie
HttpCookie cookie = HttpCookie("cookieName");
cookie.Value = "myValue";
Essentiel – ASP.NET 2.0 – Applications Web 12 / 24
//Ajout du cookie a la collection de cookies
Response.Cookies.Add(cookie);
}
}
}
}
1.6.5. L’objet Request
L’objet Request contient des informations envoyées par le navigateur du client lorsqu’il envoie une
requête au serveur Web. Il possède comme d’autres objets vus précédemment des propriétés et
méthodes qui d’accéder à d’autres objets accompagnant les requêtes envoyées (Objets Cookies par
exemple).
Vous avez la possibilité d’avoir accès à la valeur de contrôles web en utilisant l’objet Request avec la
syntaxe suivante :
Request[id de votre contrôle] ;
Dépendant aussi de la méthode d’envoi de vos données au travers de vos formulaire, vous pourrez
utiliser les collections Form ou QueryString de l’objet Request afin de pouvoir récupérer vos données.
- Request.Form[id_ou_nom_devotre_objet] pour la méthode post
- Request.QueryString[id_ou_nom_devotre_objet] pour la méthode get ou alors la
récupération de paramètres dans une chaîne de requêtes (une URL).
1.6.6. L’objet Response
Avec l’objet Response, il sera possible de constituer la réponse que le serveur renverra au client (ou
plutôt à son navigateur). Tout comme quelques objets que nous avons vu précédemment, il possède
des propriétés et des méthodes qui permettent d’accéder à d’autres objets (de réponse) comme les
objets Cache et Cookies entre autre.
Un peu plus haut, dans l’exemple sur les cookies, nous avions ajouté le cookie à la collection de
cookies. Cet ajout est fait dans la réponse qui sera renvoyée par le serveur.
Essentiel – ASP.NET 2.0 – Applications Web 13 / 24
2. Contrôles serveur
2.1. Généralités
Un contrôle serveur est un objet permettant de générer des fragments de code HTML. Un tel objet est
une instance d’une classe dérivant de la classe de base System.Web.UI.Control.
L’avantage principal des contrôles serveur est leur capacité à lever des évènements. Par exemple, le
contrôle serveur asp:TextBox, qui correspond à une zone de saisie de texte, possède entre autres
l’évènement TextChanged qui sera levé chaque fois que le texte qu’il contient aura été modifié. Nous
verrons un peu plus loin comment, et quand, un tel évènement est levé.
Il est important de savoir que chaque contrôle serveur est potentiellement un conteneur de contrôle.
C’est pour cela qu’un contrôle serveur peut être composé d’un ou plusieurs autres. La propriété
Controls de la classe Control vous permet d’obtenir des différents contrôles contenus dans un autre.
On peut voir une page aspx comme une arborescence de contrôles, dont le point d’entrée est accessible
à partir de la collection Controls de l’objet Page (cet objet existe dans toute page aspx).
Enfin, il faut savoir qu’un contrôle serveur est toujours sous la forme <asp:NomDuControle />, et
qu’il possède toujours l’attribut runat="server". Cet attribut définit le fait que l’élément doit être traité
du côté du serveur et ne doit pas être renvoyé « tel quel » au client.
2.2. Présentation de quelques contrôles
Il serait inutile de présenter une liste exhaustive de tous les contrôles serveurs mais nous allons tout de
même énumérer les plus importants.
- Button
Le contrôle Button permet de valider un formulaire (et donc une page aspx). Il est utilisé pour envoyer
au serveur les différentes actions effectuées par l’utilisateur dans le but de réaliser un traitement en
rapport.
- TextBox
Comme son nom l’indique, ce contrôle permet la saisie de texte par l’utilisateur, c’est un des contrôles
serveurs les plus utilisés.
- CheckBox / RadioButton
Ces contrôles serveur permettent à l’utilisateur de choisir parmi une liste d’éléments. Les choix sont
soit exclusifs dans le cas des RadioButton, soit indépendants dans le cas des CheckBox.
- HyperLink / ImageButton
La différence entre un lien HTML standard et le contrôle serveur HyperLink est que ce dernier permet
de générer un retour vers le serveur (cf. 2.4). L’ImageButton, quant à lui, est un complément du
bouton standard.
Essentiel – ASP.NET 2.0 – Applications Web 14 / 24
- DropDownList
Ce contrôle permet d’afficher des éléments sous forme de liste déroulante. Il possède une propriété
Items, qui est une collection d’objets ListItem.
- Literal
Tous les contrôles précédents génèrent forcément un rendu HTML. Le contrôle Literal est un contrôle
un peu particulier, dont le seul rôle est de se substituer au texte contenu dans sa propriété Text.
- Contrôles évolués
Vous pouvez le constater dans la barre d’outils de Visual Studio, il y a de nombreux autres contrôles
serveur plus évolués, tels que le contrôle Calendar, permettant d’afficher un calendrier, et d’autre en
rapport avec la gestion des utilisateurs, ou encore de l’accès aux données. Mis à part le contrôle
calendrier, ces différents contrôles seront traités dans un autre module du cours d’ASP.NET 2.0.
2.3. Interaction Client/Server
Avant ASP.NET, c'est-à-dire avec ASP, la sauvegarde des différents états des contrôles d’une page
entre deux requêtes était plutôt difficile à mettre en œuvre. Il fallait analyser à chaque requête l’état de
chaque contrôle, puis de le restituer avant d’envoyer la réponse au client.
Depuis ASP.NET 1.1, ceci est fait automatiquement !
Comment est-ce possible ? Grâce au principe de ViewState et également de ControlState depuis
ASP.NET 2.0.
Le viewstate est un contrôle HTML (à ne pas confondre avec « contrôle serveur »), invisible (hidden)
qui contient une chaîne de caractères qui stock l’état de tous les contrôles de la page.
Exemple de viewstate : <input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE"
value="/wEPDwUKMTkwNjc4NTIwMWRkDQJ6u1ACZNW/dcngEmrRuFlabSw=" />
L’élément ViewState est automatiquement généré par ASP.NET. Il doit impérativement porter le nom
« __VIEWSTATE ». Vous pouvez activer ou désactiver la gestion de l’état d’un contrôle par le
viewstate en modifiant sa propriété EnableViewState.
Le viewstate contenant les états de tous les contrôles serveur, celui-ci risque de devenir énorme,
surtout lorsque l’on souhaite y stocker les valeurs d’une table (par exemple via un GridView, cf accès
aux données en asp.net). Ceci pouvait être à l’origine de problèmes de performance en ASP.NET 1.1.
Cet inconvénient est largement diminué actuellement grâce à l’introduction depuis la version 2.0 de la
notion de ControlState.
Les ControlStates ont le même but que le ViewState, la seule différence étant qu’ils sauvegardent
l’état d’un contrôle donné.
A noter que l’on ne peut pas directement voir les ControlState des contrôles d’une page aspx, sachant
qu’ils sont stockés comme une sous section du viewstate.
Essentiel – ASP.NET 2.0 – Applications Web 15 / 24
2.4. Le principe de PostBack
Tout le système de programmation événementielle d’ASP.NET est possible grâce à un principe qui
permet la communication des évènements du client vers le serveur. Ce mécanisme est appelé postback.
Le postback est l’envoi d’une requête POST vers le serveur suite à la levée d’un évènement dont
l’origine est une action de l’utilisateur. Ce type d’évènement nécessite en général un traitement
immédiat, c’est pourquoi un appel au serveur est nécessaire. L’exemple le plus parlant d’un tel
évènement est la validation d’un formulaire via un bouton.
Il existe également des évènements non-postback. Il s’agit d’actions de l’utilisateur ne nécessitant pas
un traitement immédiat, mais qui devra être pris en compte lors du prochain postback. Un bon
exemple d’évènement non-postback est l’évènement CheckedChanged d’un CheckBox, qui est levé
lorsque l’utilisateur coche la case du contrôle.
Ceci dit, il peut être intéressant de contraindre certains contrôles utilisateurs n’étant pas « PostBack »
par défaut à générer un postback. Il suffit pour cela de placer à true leur propriété AutoPostBack.
Notez que l’objet Page de chaque page aspx possède une propriété IsPostBack qui permet de vérifier si
la requête courante est issue d’un PostBack ou d’un appel volontaire de l’utilisateur (rafraichissement
de la page, ou premier affichage). Cela peut être très utile, surtout dans le cas de traitements qui ne
doivent s’exécuter qu’une seule fois.
Voici un cas de figure plutôt explicite, démontrant l’utilité de la propriété IsPostBack. Nous avons un
contrôle DropDownList qui est chargé lors de l’évènement Load de la page.
protected void Page_Load(object sender, EventArgs e)
{
this.DropDownList1.Items.AddRange(
new ListItem[] {
new ListItem("Alsace"),
new ListItem("Paris"),
new ListItem("Valencienne") });
}
Ce code est parfaitement fonctionnel et chargera bien la liste déroulante à chaque appel de la page. Le
problème survient lors d’un retour postback vers le serveur. Sachant le viewstate conserve l’état des
contrôles, le contenu de la liste est conservé, et la méthode AddRange va ajouter une fois de plus le
même contenu, ce qui n’est pas du tout l’effet désiré.
La solution à ce problème est de tester si la requête n’est pas un postback et de ne faire l’ajout que
dans le cas contraire. Voici la méthode Page_Load modifiée :
protected void Page_Load(object sender, EventArgs e)
{
if (!Page.IsPostBack)
{
Essentiel – ASP.NET 2.0 – Applications Web 16 / 24
this.DropDownList1.Items.AddRange(
new ListItem[] {
new ListItem("Alsace"),
new ListItem("Paris"),
new ListItem("Valencienne") });
}
}
Un dernier aspect du principe de postback est apporté par la version 2.0 d’ASP.NET. Il s’agit du
CrossPagePostBack. Derrière ce nom difficilement prononçable se cache la résolution d’un problème
simple : sachant qu’une page Page2.aspx ne contient pas les contrôles d’une page Page1.aspx,
comment faire pour lui transmettre facilement les états des contrôles de cette dernière ? Il suffit de
modifier la propriété PostBackUrl de Page1.aspx en indiquant le chemin de Page2.aspx.
Pour illustrer cette fonctionnalité, voici le code d’une Page1.aspx, contenant une zone de saisie de
texte, et un bouton de validation :
…
<asp:TextBox ID="TxtToFeed" runat="server"></asp:TextBox>
<asp:Button ID="BtClickMe" runat="server" PostBackUrl="~/Page2.aspx"
Text="Button" />
…
Notez bien la propriété PostBackUrl du contrôle Button.
La page Page2.aspx elle ne contient qu’un label, qui affichera le texte contenu dans le TextBox de
Page1.aspx, et ce uniquement lors d’un CrossPagePostBack.
protected void Page_Load(object sender, EventArgs e)
{
if (PreviousPage != null && PreviousPage.IsCrossPagePostBack)
{
this.LblDisplay.Text =
((TextBox)PreviousPage.FindControl("TxtToFeed")).Text;
}
}
Pour accéder aux différents éléments de la page ayant initié le CrossPagePostBack, il suffit de vérifier
si la propriété PreviousPage existe (non null), et si la propriété IsCrossPagePostBack de cet objet est à
true.
On peut alors accéder notamment aux différents contrôles de cette page et à leurs propriétés, grâce à la
méthode FindControl.
2.5. Validation de contrôles
Très souvent lors du développement d’applications web, il est impératif de vérifier la saisie des
utilisateurs. Cela va du fait qu’une zone de texte est bien renseignée au fait qu’une chaîne de
caractères ait un format voulu. ASP.NET simplifie grandement cela grâce aux contrôles de validation.
Chaque contrôle de validation possède au moins une propriété permettant de renseigner le contrôle
serveur à valider (ControlToValidate).
La validation d’un contrôle se fait en 2 étapes, une validation sur le client (en javascript) et une autre
sur le serveur. Vous pouvez éviter le contrôle côté client grâce à la propriété EnabledClientScript du
contrôle de validation concerné.
Essentiel – ASP.NET 2.0 – Applications Web 17 / 24
La validation des contrôles se fait lorsqu’ASP.NET appelle la méthode Page.Validate(). Attention,
cette méthode est appelé par ASP.NET après l’exécution de la méthode Page_Load(), vous ne pourrez
tester la valider d’une page (grâce à la propriété Page.IsValid) dans cette méthode QUE si vous
appelez Page.Validate() vous-même au préalable.
Il existe 5 contrôles de validation :
- Le contrôle RequiredFiledValidator, doit être associé à un contrôle qui doit obligatoirement
être renseigné.
- Le contrôle CompareValidator est à utilisé conjointement à deux zones de saisie de texte qui
doivent être identique. Par exemple, lors de la saisie d’un mot de passe et sa validation dans
une deuxième zone de texte. Notez que ce contrôle possède en plus de la propriété
ControlToValidate, une propriété ControlToComplete.
- Le contrôle RangeValidator quant à lui, est utilisé pour vérifier si une valeur numérique est
comprise entre deux bornes que vous spécifiez au contrôle de validation.
- Le contrôle RegularExpressionValidator permet de comparer le texte d’une zone de texte à un
motif (pattern). Il sert par exemple à vérifier la validité d’une adresse email. Sachez que vous
n’êtes pas obligé de créer vous-même les motifs de comparaison, il existe un certain nombre
de motifs prédéfinis et qui couvre une grande partie de l’utilisation courante de ce contrôle de
validation. Le pattern doit être placé dans l’attribut ValidationExpression.
- Enfin, le contrôle CustomValidator va vous permettre de créer vos propres contrôles de
validation.
Voici un exemple de formulaire d’inscription illustrant les contrôles de validations
Voici le code aspx en rapport avec ce résultat :
Nom
<asp:TextBox ID="TxtNom" runat="server" />
<asp:RequiredFieldValidator ID="MyRequiredFieldValidator"
runat="server"
ErrorMessage="Vous devez saisir un nom."
ControlToValidate="TxtNom"/><br />
Password <asp:TextBox ID="TxtPass" runat="server" TextMode="Password"
Width="147px"></asp:TextBox><br />
Validation password
<asp:TextBox ID="TxtPassValid" runat="server" TextMode="Password"/>
<asp:CompareValidator ID="MyCompareValidator" runat="server"
ErrorMessage="Les deux mots de passe doivent être identiques"
ControlToCompare="TxtPassValid"
ControlToValidate="TxtPass" /><br />
<asp:TextBox ID="TxtEmail" runat="server" />
<asp:RegularExpressionValidator ID="MyRegularExpressionValidator"
Essentiel – ASP.NET 2.0 – Applications Web 18 / 24
runat="server"
ErrorMessage="L'adresse Mail n'est pas valide."
ControlToValidate="TxtEmail"
ValidationExpression="\w+([-+.']\w+)*@\w+([-.]\w+)*\.\w+([-
.]\w+)*" /><br />
Age
<asp:TextBox ID="TxtAge" runat="server" />
<asp:RangeValidator ID="MyRangeValidator" runat="server"
ErrorMessage="Votre age n'est pas valide."
ControlToValidate="TxtAge"
MaximumValue="77"
MinimumValue="7"
Type="Integer" />
<asp:Button ID="MyButton" runat="server" OnClick="MyButton_Click"
Text="S'inscrire" />
Vous l’avez certainement compris, la propriété ErrorMessage permet de définir le message d’erreur
qui sera affiché si une validation échoue.
Voyons maintenant un exemple d’utilisation d’un CustomValidator. Pour cela nous allons créer un
validateur qui permettra de vérifier si un champ est un nombre pair.
Pour cela il nous faut écrire une fonction de vérification côté client, et une méthode de vérification
côté serveur. La fonction côté client sera écrite en Javascript :
<script type="text/javascript">
function EstPair_Clientvalidation(source, args)
{
if( args.Value % 2 == 0 )
{
args.IsValid = true;
}
else
{
args.IsValid = false;
}
}
</script>
Elle doit obligatoirement respecter cette signature (deux variable en paramètres). Le paramètre args,
permet de connaitre la valeur à valider, grâce à la propriété Value, et permet de définir si elle est
valide ou non, grâce à la propriété booléenne IsValid.
La méthode côté serveur possède également une signature particulière, elle prend en paramètre la
source, et un ServerValidateEventArgs :
<script runat="server">
void EstPair_ServerValidation(object source,
ServerValidateEventArgs e)
{
e.IsValid = false;
int temp;
if (Int32.TryParse(e.Value, out temp))
Essentiel – ASP.NET 2.0 – Applications Web 19 / 24
{
if (temp % 2 == 0)
{
e.IsValid = true;
}
}
}
</script>
Vous remarquerez que le principe est le même côté client et côté serveur.
Une fois ces deux code de validation écrits, il ne reste plus qu’a ajouter un CustomValidator, et à lui
préciser les méthodes de validation qu’il doit utiliser, grâce à sa propriété ClientValidationFunction,
pour la fonction javascript, et à l’évènement OnServerValidate pour la méthode côté serveur.
<asp:TextBox ID="TxtBox" runat="server"/>
<asp:CustomValidator ID="CustomValidator1" runat="server"
ControlToValidate="TxtBox"
ErrorMessage="Veuillez entrer un nombre pair."
ClientValidationFunction='EstPair_Clientvalidation'
OnServerValidate="EstPair_ServerValidation" />
Un problème existant en ASP.NET 1.1 survenait lorsqu’une page possédait plusieurs de contrôles
différents qui devaient être validés séparément. Prenons pour exemple une page possédant à la fois une
zone de saisie de texte pour effectuer une recherche rapide sur le site et une autre permettant de
s’inscrire à la newsletter. Il est facile d’imaginer qu’on ne souhaite pas valider l’adresse email saisie
pour l’inscription à la newsletter lorsque l’utilisateur souhaite effectuer une recherche.
La version 2.0 apporte donc une notion nouvelle : les groupes de validation.
Il est donc possible de regrouper les contrôles par groupes de validation, de manière à les contrôler
séparément. Pour cela il suffit de renseigner la propriété ValidationGroup des contrôles de validations
d’un groupe et du bouton associé avec la même valeur.
La majorité des sites web effectuant la validation de données saisies regroupe les messages d’erreurs
éventuels dans un endroit particulier, de façon à rendre plus facile la correction de celle-ci par
l’utilisateur. Ceci peut être fait très facilement grâce à la classe ValidationSummary. Le simple fait de
placer un contrôle ValidationSummary sur une page contenant des contrôles de validation centralisera
leurs messages à l’endroit où il se trouve.
Essentiel – ASP.NET 2.0 – Applications Web 20 / 24
3. Framework de page
3.1. Les MasterPages
Imaginez un site web standard, composé graphiquement d’un menu à gauche, un entête, un pied de
page et une zone centrale affichant le contenu des pages. Ceci ressemblerait schématiquement à cela :
Comment faire en sorte de ne pas avoir à mettre à jour toutes les pages du site web chaque fois que le
menu change, ou que le logo contenu dans l’entête du site est modifié ? Grâce à une nouveauté
apportée par la version 2.0 d’ASP.NET : les MasterPages (pages maîtres).
Une MasterPages est une page ASP.NET particulière, d’extension .master, permettant de définir un
squelette de page, qui pourra être réutilisé dans n’importe quelle autre page du site web. On peut voir
cela comme une sorte d’ « héritage graphique ».
C’est donc dans une MasterPage que nous définirons les éléments redondants d’un groupe de pages.
On définit les zones « personnalisables » dans chaque page associée à la MasterPage grâce à des
contrôles serveur ContentPlaceHolder.
Voici la MasterPage correspondant à la capture d’écran présenté plus haut :
Essentiel – ASP.NET 2.0 – Applications Web 21 / 24
Pour associer une page aspx à une MasterPage il suffit simplement de la définir grâce à l’attribut
MasterPageFile, puis de définir le contenu des différents ContentPlaceHolder de la masterPage pour
cette page grâce à des contrôles Content.
<%@ Page Language="C#" MasterPageFile="~/MasterPage.master"
AutoEventWireup="true" CodeFile="Home.aspx.cs" Inherits="Home"
Title="Untitled Page" %>
<asp:Content ID="Content1" ContentPlaceHolderID="CPHContent"
Runat="Server">
</asp:Content>
Voilà l’affichage de cette page dans Visual Studio en mode design :
Essentiel – ASP.NET 2.0 – Applications Web 22 / 24
On remarque bien que la seule zone éditable (non grisée) est le contrôle Content.
Pour pouvoir utiliser une masterpage dans un page aspx, il faut choisir cette dernière en cochant
"Select a master page" au moment de la création de la page.
Notez qu’il est possible d’encapsuler les MasterPages.
Lors de la mise en place de sites web importants, il peut être lourd de devoir renseigner la page maître
dans la propriété MasterPageFile de la directive de chaque page de l’application. Il est possible de
configurer une page maître par défaut pour toutes les pages aspx d’un site web dans le fichier de
configuration de celui-ci.
…
<system.web>
<pages masterPageFile="~/MasterPage.master" />
…
A partir de là, chaque page ne possédant pas d’attribut MasterPageFile et définissant les contrôles
Content nécessaire à l’utilisation de la MasterPage définie dans le fichier de configuration sera
associée à cette MasterPage.
Enfin, notez qu’il est possible d’accéder aux éléments publics d’une MasterPage à partir d’une page
qui lui est associée grâce à l’objet Master accessible dans cette dernière.
Supposons qu’il existe une MasterPage contenant un label :
<asp:Label ID="LblAccessible" runat="server" Text="Label" />
Dans une page utilisant cette MasterPage, voici le code permettant de modifier le texte du Label :
((Label)Master.FindControl("LblAccessible")).Text = "Some text";
3.2. Style, Skin, Thèmes
Les styles tels qu’on les connait en HTML sont tout à fait utilisables dans des application ASP.NET.
La classe de base commune à tous les contrôles serveur (WebControl) présente la propriété CssClass
qui permet de définir le nom d’un style à appliquer pour ce contrôle. Cette classe comprend également
plusieurs attributs fortement typés tels que par exemple : BackColor.
Supposons que notre application web contient la feuille de style suivante :
.TextBoxes
{
border: 5px;
}
Voici le code nécessaire à l’utilisation de la classe CSS TextBoxes sur un contrôle TextBox :
<asp:TextBox ID="MyTextBox" runat="server" CssClass="TextBoxes" />
Les thèmes sont un ensemble de styles qui peuvent être appliqué à un ensemble de pages,
statiquement, ou dynamiquement. Un thème est matérialisé par un répertoire : le nom du répertoire est
Essentiel – ASP.NET 2.0 – Applications Web 23 / 24
le nom du thème. Un tel répertoire doit être stocké dans le répertoire /App_Theme de l’application
web.
Pour configurer un thème pour un ensemble de pages, il est possible, soit de le configurer pour
l’ensemble de l’application via le fichier de configuration via l’élément <pages theme="Theme" />,
soit par la directive Page d’une page aspx via l’attribut Theme. Un Thème contient un ou plusieurs
fichier skin et zéro ou plusieurs fichiers CSS.
Les skins définissent l’apparence de contrôles web, un fichier d’extension .skin définissant celle d’un
type de contrôle web. La définition d’un fichier skin ressemble à la définition d’un contrôle mise à part
le fait que seules certaines propriétés peuvent être renseignées.
Voici un exemple de fichier skin :
<asp:TextBox height="200px" runat="server" />
<asp:Label Font-Bold="true" />
Un theme contenant ce fichier rendra la police des Label en gras, et la hauteur des TextBox à 200
pixels.
Essentiel – ASP.NET 2.0 – Applications Web 24 / 24
4. Fichiers de configuration
Un grand nombre de paramètres d’une application web peuvent être centralisés dans des fichiers de
configuration. Ce sont des fichiers XML dont l’élément principal est le nœud <system.web/>.
Il est également possible de définir ses propres paramètres dans un fichier de configuration
<appSettings/>.
Voici un exemple de paramètre propre ajouté dans le fichier de configuration :
<appSettings>
<add key="CaptainAge" value="42" />
</appSettings>
La variable CaptainAge sera accessible à partir de n’importe quel page de l’application grâce à la
collection statique AppSettings de la classe ConfigurationManager :
ConfigurationManager.AppSettings["CaptainAge"]
4.1. Organisation des fichiers
Une application web peut être configurée grâce à plusieurs fichiers de configuration, qui peuvent être
situés à quatre endroits différents sur le serveur :
- Le fichier Machine.Config, qui se trouve dans le répertoire d’installation du Framework .Net
- Le fichier Web.Config, qui se trouve dans le répertoire racine de tous les sites hébergés par le
serveur
- Le fichier Web.Config situé dans le répertoire racine d’une application
- Les fichiers Web.Config qui se trouve dans n’importe quel sous répertoire d’une application
web
Si deux paramètres se contredisent dans deux fichiers différents, il faut savoir que c’est le fichier le
plus « proche » d’une page qui prime. Par exemple, si un élément de configuration du fichier
Web.Config situé dans le répertoire racine d’une application est en contradiction avec celui situé dans
le fichier Machine.Config, c’est celui situé dans le fichier Web.Config qui sera pris en compte.
4.2. Prise en compte des mises à jour
ASP.NET utilise le système « shadow copy » qui consiste à ne pas utiliser directement en mémoire
les fichiers binaires d’une application web, mais des copies de ceux-ci. Cela permet de pouvoir mettre
à jour ces fichiers sans devoir arrêter l’application.
Ce principe permet de prendre en compte les modifications des éléments d’un fichier de configuration
sans avoir à redémarrer le serveur web.