24
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

ASP.NET 2.0 – Applications Web - easydata.e-monsite.comeasydata.e-monsite.com/medias/files/essentiel.pdf · Essentiel – ASP.NET 2.0 – Applications Web 3 / 24 1. Introduction

Embed Size (px)

Citation preview

Page 1: ASP.NET 2.0 – Applications Web - easydata.e-monsite.comeasydata.e-monsite.com/medias/files/essentiel.pdf · Essentiel – ASP.NET 2.0 – Applications Web 3 / 24 1. Introduction

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

Page 2: ASP.NET 2.0 – Applications Web - easydata.e-monsite.comeasydata.e-monsite.com/medias/files/essentiel.pdf · Essentiel – ASP.NET 2.0 – Applications Web 3 / 24 1. Introduction

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

Page 3: ASP.NET 2.0 – Applications Web - easydata.e-monsite.comeasydata.e-monsite.com/medias/files/essentiel.pdf · Essentiel – ASP.NET 2.0 – Applications Web 3 / 24 1. Introduction

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 :

Page 4: ASP.NET 2.0 – Applications Web - easydata.e-monsite.comeasydata.e-monsite.com/medias/files/essentiel.pdf · Essentiel – ASP.NET 2.0 – Applications Web 3 / 24 1. Introduction

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.

Page 5: ASP.NET 2.0 – Applications Web - easydata.e-monsite.comeasydata.e-monsite.com/medias/files/essentiel.pdf · Essentiel – ASP.NET 2.0 – Applications Web 3 / 24 1. Introduction

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

Page 6: ASP.NET 2.0 – Applications Web - easydata.e-monsite.comeasydata.e-monsite.com/medias/files/essentiel.pdf · Essentiel – ASP.NET 2.0 – Applications Web 3 / 24 1. Introduction

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.

Page 7: ASP.NET 2.0 – Applications Web - easydata.e-monsite.comeasydata.e-monsite.com/medias/files/essentiel.pdf · Essentiel – ASP.NET 2.0 – Applications Web 3 / 24 1. Introduction

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.

Page 8: ASP.NET 2.0 – Applications Web - easydata.e-monsite.comeasydata.e-monsite.com/medias/files/essentiel.pdf · Essentiel – ASP.NET 2.0 – Applications Web 3 / 24 1. Introduction

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.

Page 9: ASP.NET 2.0 – Applications Web - easydata.e-monsite.comeasydata.e-monsite.com/medias/files/essentiel.pdf · Essentiel – ASP.NET 2.0 – Applications Web 3 / 24 1. Introduction

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 : .

Page 10: ASP.NET 2.0 – Applications Web - easydata.e-monsite.comeasydata.e-monsite.com/medias/files/essentiel.pdf · Essentiel – ASP.NET 2.0 – Applications Web 3 / 24 1. Introduction

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.

Page 11: ASP.NET 2.0 – Applications Web - easydata.e-monsite.comeasydata.e-monsite.com/medias/files/essentiel.pdf · Essentiel – ASP.NET 2.0 – Applications Web 3 / 24 1. Introduction

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";

Page 12: ASP.NET 2.0 – Applications Web - easydata.e-monsite.comeasydata.e-monsite.com/medias/files/essentiel.pdf · Essentiel – ASP.NET 2.0 – Applications Web 3 / 24 1. Introduction

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.

Page 13: ASP.NET 2.0 – Applications Web - easydata.e-monsite.comeasydata.e-monsite.com/medias/files/essentiel.pdf · Essentiel – ASP.NET 2.0 – Applications Web 3 / 24 1. Introduction

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.

Page 14: ASP.NET 2.0 – Applications Web - easydata.e-monsite.comeasydata.e-monsite.com/medias/files/essentiel.pdf · Essentiel – ASP.NET 2.0 – Applications Web 3 / 24 1. Introduction

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.

Page 15: ASP.NET 2.0 – Applications Web - easydata.e-monsite.comeasydata.e-monsite.com/medias/files/essentiel.pdf · Essentiel – ASP.NET 2.0 – Applications Web 3 / 24 1. Introduction

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)

{

Page 16: ASP.NET 2.0 – Applications Web - easydata.e-monsite.comeasydata.e-monsite.com/medias/files/essentiel.pdf · Essentiel – ASP.NET 2.0 – Applications Web 3 / 24 1. Introduction

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é.

Page 17: ASP.NET 2.0 – Applications Web - easydata.e-monsite.comeasydata.e-monsite.com/medias/files/essentiel.pdf · Essentiel – ASP.NET 2.0 – Applications Web 3 / 24 1. Introduction

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 />

Email

<asp:TextBox ID="TxtEmail" runat="server" />

<asp:RegularExpressionValidator ID="MyRegularExpressionValidator"

Page 18: ASP.NET 2.0 – Applications Web - easydata.e-monsite.comeasydata.e-monsite.com/medias/files/essentiel.pdf · Essentiel – ASP.NET 2.0 – Applications Web 3 / 24 1. Introduction

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))

Page 19: ASP.NET 2.0 – Applications Web - easydata.e-monsite.comeasydata.e-monsite.com/medias/files/essentiel.pdf · Essentiel – ASP.NET 2.0 – Applications Web 3 / 24 1. Introduction

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.

Page 20: ASP.NET 2.0 – Applications Web - easydata.e-monsite.comeasydata.e-monsite.com/medias/files/essentiel.pdf · Essentiel – ASP.NET 2.0 – Applications Web 3 / 24 1. Introduction

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 :

Page 21: ASP.NET 2.0 – Applications Web - easydata.e-monsite.comeasydata.e-monsite.com/medias/files/essentiel.pdf · Essentiel – ASP.NET 2.0 – Applications Web 3 / 24 1. Introduction

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 :

Page 22: ASP.NET 2.0 – Applications Web - easydata.e-monsite.comeasydata.e-monsite.com/medias/files/essentiel.pdf · Essentiel – ASP.NET 2.0 – Applications Web 3 / 24 1. Introduction

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

Page 23: ASP.NET 2.0 – Applications Web - easydata.e-monsite.comeasydata.e-monsite.com/medias/files/essentiel.pdf · Essentiel – ASP.NET 2.0 – Applications Web 3 / 24 1. Introduction

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.

Page 24: ASP.NET 2.0 – Applications Web - easydata.e-monsite.comeasydata.e-monsite.com/medias/files/essentiel.pdf · Essentiel – ASP.NET 2.0 – Applications Web 3 / 24 1. Introduction

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.