Problème à signaler:


Télécharger Cours developpement web visual studio ASP.Net



★★★★★★★★★★3.5 étoiles sur 5 basé sur 1 votes.
Votez ce document:

Télécharger aussi :

Cours developpement web visual studio ASP.Net





 

Contenu

1. INTRODUCTION À 2.0 3

1.1.   GENERALITES 3

1.2.   TRAITEMENT DES REQUETES . 3

1.3.   NOTION DE CODE-BEHIND ET COMPILATION .. 4

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

5. MODULE 2 – ASP .NET 2 AVANCÉ .. 26

5.1.   PARTIE 1 – LES CONTRÔLES SERVEUR UTILISATEUR .. 26

5.1.1.   Chapitre 1 – Principe de base . 26 5.1.2. Chapitre 2 – Créer un contrôle utilisateur 26

    5.1.3.      Chapitre 3 – Les événements sur un contrôle utilisateur .. 30

5.2.   PARTIE 2 : ACCÈS AUX DONNÉES .. 31

5.2.1.   Le DataBinding .. 31 5.2.2. Les types de sources de données 32 5.2.3. ObjectDataSource . 33 5.2.4. Affichage de données 35

5.3.   PARTIE 3 : DEBUG, TRACE, CACHE . 39

5.3.1.   Debuger une application 39 5.3.2. Utiliser les informations de trace .. 39

    5.3.3.      Gestion du cache 41

5.4.   PERSONNALISATION ET NAVIGATION . 42

5.4.1.   Personnalisation 42

5.4.2.   Aide à la navigation . 44

1.      Introduction à 2.0

 

Déjà dans sa première mouture, 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’ 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 (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#, , 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 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 :


Le serveur transmet la requête au filtre ISAPI (). Le filtre transmet la demande au processus (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’ 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 . (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’ 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 est écrit en C#, le fichier contenant ce code sera nommé .

Comment se passe la compilation ?

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 . Cette classe est alors compilée par lors de la première exécution (ou bien lors de l’appel du Handler http ).

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

 

<%

@PageLanguage="C#"

DOCTYPEhtmlPUBLIC"

"

scriptrunat="server">

//Le code C# sera placé ici script>

htmlxmlns= headrunat="server">

<title>Untitled Page head>

body>

<formid="form1"

<div>

</div>

</form> body> html>

%>

//W3C//DTD XHTML 1.0 Transitional//EN"">

";>

/title>

="server">

 <!

< 

</

</

</

</

-

runat

Code Behind – Fichier

 

<%

@ Page Language="C#" AutoEventWireup="true"  CodeFile="" Inherits="_Default" %>

DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "">

html xmlns="; > head runat="server">

<title>Untitled Page</title> head>

body>

<form id="form1" runat="server">

<div></div>

</form> body> html>

 <!

</

</

</

Code Behind – Fichier

using System; using ; using System.Configuration; using ; using .Security; using ;

using .WebControls; using .WebControls.WebParts; using .HtmlControls;

 publicpartialclass_Default : .Page

{

protectedvoid Page_Load(object sender, EventArgs e)     {

            //Le code C# placé ici s’exécutera lors du chargement

    } }

1.4.  et Visual Studio

Visual Studio est une des raisons qui fait que créer une application web avec 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.

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.

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 , 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 , 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 , l’ensemble des objets que nous utilisons sont issus de l’espace de nom .

Cet espace de noms fournit directement des classes pour les objets Application, Cache, Cookies, Request et Response que nous verrons dans ce chapitre.

Concernant les objets Session et Page, leur définition réside respectivement dans les espaces de noms .SessionState et .

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

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 .

Des évènements associés à l’application elle-même sont définis dans le fichier

(quand vous passez au mode code du fichier ). (Nous en parlons lors de la présentation du fichier 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.

1.6.3.   L’objet Session

Nous le disions un peu plus haut, l’espace de nom .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…

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

}

       //Ajout du cookie a la collection de cookies

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

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

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

-    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’ 2.0.

2.3.  Interaction Client/Server

Avant , 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 1.1, ceci est fait automatiquement !

Comment est-ce possible ? Grâce au principe de ViewState et également de ControlState depuis 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 :

<inputtype="hidden"name="__VIEWSTATE"id="__VIEWSTATE"

value="/wEPDwUKMTkwNjc4NTIwMWRkDQJ6u1ACZNW/dcngEmrRuFlabSw="/>

L’élément ViewState est automatiquement généré par . 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 ). Ceci pouvait être à l’origine de problèmes de performance en 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.


2.4.  Le principe de PostBack

Tout le système de programmation événementielle d’ 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.

protectedvoid Page_Load(object sender, EventArgs e)

    {

this.DropDownList1.Items.AddRange( newListItem[] {  newListItem("Alsace"),  newListItem("Paris"),  

newListItem("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 : 

this.DropDownList1.Items.AddRange( newListItem[] {  newListItem("Alsace"),  newListItem("Paris"),  newListItem("Valencienne") });

}

}

 

Un dernier aspect du principe de postback est apporté par la version 2.0 d’. 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 ne contient pas les contrôles d’une page , comment faire pour lui transmettre facilement les états des contrôles de cette dernière ? Il suffit de modifier la propriété PostBackUrl de en indiquant le chemin de .

Pour illustrer cette fonctionnalité, voici le code d’une , contenant une zone de saisie de texte, et un bouton de validation :

<asp:TextBoxID="TxtToFeed"runat="server"></asp:TextBox>

<asp:ButtonID="BtClickMe"runat="server"PostBackUrl=""

Text="Button"/>

Notez bien la propriété PostBackUrl du contrôle Button.

La page elle ne contient qu’un label, qui affichera le texte contenu dans le TextBox de , et ce uniquement lors d’un CrossPagePostBack.

protectedvoid Page_Load(object sender, EventArgs e)

{

if (PreviousPage != null && PreviousPage.IsCrossPagePostBack)

      { =                                 

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

La validation des contrôles se fait lorsqu’ appelle la méthode Page.Validate(). Attention, cette méthode est appelé par 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 :

runat="server"

ErrorMessage="L'adresse Mail n'est pas valide."

ControlToValidate="TxtEmail"

ValidationExpression="\w+([-+.']\w+)*@\w+([-.]\w+)*\.\w+([-

.]\w+)*"/><br/>

Age      

<asp:TextBoxID="TxtAge"runat="server"/>

<asp:RangeValidatorID="MyRangeValidator"runat="server"

ErrorMessage="Votre age n'est pas valide."

ControlToValidate="TxtAge"

MaximumValue="77"

MinimumValue="7"

Type="Integer"/>

<asp:ButtonID="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 :

<scripttype="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 :


        {



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:TextBoxID="TxtBox"runat="server"/>

<asp:CustomValidatorID="CustomValidator1"runat="server"

ControlToValidate="TxtBox"

ErrorMessage="Veuillez entrer un nombre pair."

ClientValidationFunction='EstPair_Clientvalidation'OnServerValidate="EstPair_ServerValidation" />

Un problème existant en 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.

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’ : les MasterPages (pages maîtres).

Une MasterPages est une page 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 :

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.

 

<%

@PageLanguage="C#"MasterPageFile="~/MasterPage.master"

AutoEventWireup="true"CodeFile=""Inherits="Home"

Title="Untitled Page"%> asp:ContentID="Content1"ContentPlaceHolderID="CPHContent"

Runat="Server"> asp:Content>

<

</

Voilà l’affichage de cette page dans Visual Studio en mode design :

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.

<>

    <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:LabelID="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 . 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:TextBoxID="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 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:TextBoxheight="200px"runat="server"/>

<asp:LabelFont-Bold="true"/>

Un theme contenant ce fichier rendra la police des Label en gras, et la hauteur des TextBox à 200 pixels.

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

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

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.


 

5.     ASP .NET 2 Avancé

 

5.1.     Partie 1 – Les contrôles serveur utilisateur

5.1.1.   Chapitre 1 – Principe de base

Vous avez vu dans, les cours précédents, l'existence de nombreux contrôles serveurs qui vous permettaient d'afficher diverses informations sur votre WebForm. Mais les contrôles proposés par ASP .NET 2 ne suffisent pas parfois aux développeurs pour la réalisation d'applications Web personnalisées et riches.

Pour répondre à ce problème, il existe un moyen de créer ses propres contrôles : ces contrôles sont des contrôles utilisateur, plus couramment appelés "User Controls". Vous allez donc pouvoir, avec les contrôles utilisateurs, créer des contrôles qui pourront être utilisés par plusieurs applications. Prenons un exemple simple d'utilisation : vous développer un site Web qui contient plusieurs modules. Vous voulez afficher un titre avant chaque module et faire en sorte que le nom du titre s'adapte au module. Il vous suffira alors de développer un contrôle utilisateur "MyTitre" en lui attribuant une propriété "Nom" qui changera d'un module à l'autre.

Les WebForms ont pour extension, comme vous le savez, "*.aspx". Les contrôles utilisateur ont eux pour extension ".ascx". Pour finir cette présentation, vous devez savoir que programmer une WebForm ou un contrôle utilisateur ne comporte guère de différence et vous n'aurez donc aucun mal à réaliser des contrôles utilisateur si vous avez déjà réalisé des WebForms.

5.1.2.   Chapitre 2 – Créer un contrôle utilisateur

Pour créer un nouveau "contrôle utilisateur Web" dans Visual Studio 2005, clic droit sur votre site Web, Ajouter un nouvel élément…

Figure 1 - Ajouter un nouvel élément


Après avoir spécifié un nom à votre contrôle, Visual Studio ajoute un fichier à votre projet avec l'extension *.ascx. Il créer également un fichier * qui contiendra le code de votre contrôle (uniquement si vous avez laissé coché la case "Placer le code dans un fichier distinct").

Vous pouvez éditer votre contrôle de la même manière qu'une WebForm, soit en mode design soit directement en code. Un contrôle utilisateur Web est en général défini au moyen d'un fichier d'extension *.ascx débutant par la directive <%@ Control %>. Ce fichier sera compilé par ASP .NET en une classe dérivée de la classe Control. Le nom de cette classe est précisé sous la directive ClassName. Voici ce à quoi ressemble votre contrôle utilisateur par défaut :

   

<%

@ Control Language="C#" AutoEventWireup="true"

CodeFile="" Inherits="WebUserControl"

%>

         

            Et le fichier * qui lui est associé :

using System; using ; using System.Configuration; using System.Collections; using ; using .Security; using ;

using .WebControls; using .WebControls.WebParts; using .HtmlControls;

public partial class WebUserControl : .UserControl

{

    protected void Page_Load(object sender, EventArgs e)     {

    }

}

On peut distinguer deux famille de contrôle utilisateur. Les contrôles utilisateur simple et les contrôles utilisateur composite. Les contrôles utilisateur composite sont, à l'instar de tous contrôles, un contrôle utilisateur peut avoir des contrôles serveurs enfants. 

Contrôle utilisateur simple :

 

<%

<%

@ Control Language="C#" ClassName="MyUserCtrl"

 

%>

 Response.Write("HTML du contrôle") ;

%>

             

Contrôle utilisateur composite :

          <asp:Button ID="Button1" Text="Soumettre"

OnClick="Btn_Click" runat="server" />

<asp:Label ID="Msg" runat="server" />

Comme vous pouvez le constater dans l'exemple précédent vous pouvez également écrire directement du code C# dans le fichier *.ascx du contrôle au moyen de balises Script.

Maintenant que nous avons vu comment créer un contrôle utilisateur, voyons comment l'utiliser. Voici un exemple d'une page cliente du contrôle précédent. On voit qu'une directive <%@ Register %> est nécéssaire pour importer le nom de la classe, le nom du fichier *.ascx qui la définie, ainsi qu'un préfixe qui joue le rôle d'un espace de nom :

   

<%

<%

@ Page Language="C#"

%>

@ Register Src="

TagPrefix="DEMO" 

html xmlns=

      <body>

          <form id="form1"

               <DEMO:

          </form>

      </body> html>

 

%>

" TagName="MyUserCtrl"

"; >

 runat="server">

MyUserCtrl ID="MyUserCtrl1" runat="server" />

 
   

</

 

•    Src : représente le chemin du contrôle utilisateur.

•    TagName : C'est le nom du contrôle utilisateur. On peut spécifier un nom différent du nom original du contrôle utilisateur.

•    TagPrefix : Représente le namespace du contrôle utilisateur. Plusieurs contrôles utilisateur ayant le même nom vont pouvoir être ainsi différenciés par leur namespace.

Une fois votre contrôle enregistré dans votre page grâce à la balise "Register", vous pouvez ensuite atteindre votre contrôle utilisateur comme un simple contrôle en utilisant son "TagName".

Vous pouvez utiliser le mode design pour ajouter le contrôle à votre page en faisant un glisserdéposer de votre contrôle sur votre page depuis la fenêtre "Explorateur de solution".

La prochaine étape, c'est de rendre notre contrôle utilisateur paramétrable. Pour cela, on utilisera les propriétés dans la classe représentant notre contrôle. Nous allons prendre un exemple tout bête d'un contrôle utilisateur composé d'un label dont le texte pourra être changé en fonction du module du site dans lequel il est utilisé : 

<asp:Label ID="lblMyTitre" runat="server"></asp:Label>

Et la propriété correspondante à ce label, soit dans une balise script soit dans la page * associée :

        }

}

Vous pouvez désormais accéder, dans votre page, à votre propriété via son nom utilisé comme attribut :

   

<%



<%

@ Page Language="C#"

@ Register Src= html xmlns= body>

<form id="form1"

        <uc1:MyTitre ID

</form> body> html>

 

%>

%>

 TagName="MyTitre" TagPrefix="uc1" 

"; >

="server">

"MyTitre1" runat="server" Titre="Module 2" />

 

""

runat

=

 

</

</

 

Vous pouvez également intégrer ces propriétés dans l'environnement graphique de Visual

Studio. Pour pouvoir modifier vos propriétés de vos contrôles utilisateurs dans la fenêtre "Propriétés" de Visual Studio, nous devons utiliser des attributs. Voici une liste, nonexhaustive, des attributs que vous pouvez utiliser : 

•    Category : Définit la catégorie à laquelle la propriété appartient.

•    Description : Description relative à la propriété qui sera affichée dans la fenêtre propriétés.

•    Browsable : Booléen, définit si la propriété peut être modifiée ou non.

•    DefaultValue : Valeur par défaut de la propriété.

•    DefaultEvent : Spécifie l'événement par défaut.

[System.ComponentModel.Category("Configuration")]

[System.ComponentModel.Description("Le titre du module à afficher")]

[System.ComponentModel.Browsable(true)]

//OU

//[System.ComponentModel.Category("Configuration"),

//System.ComponentModel.Description("Le titre du module à afficher"),

//System.ComponentModel.Browsable(true)] public string Titre

{         get         {

            return ;

}         set          {

            = value;

        }

}

Vous pouvez combiner les attributs soit les uns en dessous des autres, soit les uns à  la suite des autres séparés par des virgules.

Figure 2 - Propriétés du contrôle utilisateur

5.1.3.   Chapitre 3 – Les événements sur un contrôle utilisateur

Vous avez la possibilité de créer vos événements (qu'on appelle aussi événements personnalisés)  dans un contrôle utilisateur et de vous y abonner à partir de la page cliente avec la syntaxe On[NomDeLévénement]. 

Notre contrôle utilisateur : 

   

<%

@ Control Language="C#" ClassName="MyUserCtrl" script Language="C#" runat="server"> public event EventHandler BlancSelected; void Btn_Click(Object sender, EventArgs e)

{ if (Couleur.SelectedItem.Value == "Blanc")

        {

BlancSelected(this, EventArgs.Empty);         }

} script> 

Couleur : <asp:DropDownList ID="Couleur" runat=

<asp:ListItem>Blanc</asp:ListItem>             <asp:ListItem>Noir</asp:ListItem>

</asp:DropDownList>

<asp:Button ID="Button1" Text="Soumettre"

OnClick="Btn_Click" runat="server" /> asp:Label ID="Msg" runat="server" />

 

%>

>

</

"server"

            Notre page cliente :

</script>

<html xmlns="; >

<body>

    <form id="form1" action="" method="post" runat="server">

        <DEMO:MyUserCtrl ID="MyUserCtrl1" runat="server"

OnBlancSelected="BlancSelectedHandler" />

        <asp:Label ID="Msg" runat="server" EnableViewState="false" />

</form>

</body>

</html>

5.2.      Partie 2 : Accès aux données

5.2.1.   Le DataBinding

Le DataBinding vous permet de lier un contrôle à une source de données. Les données seront alors automatiquement affichées dans le contrôle. Si le binding est bidirectionnel, une modification de la valeur dans le contrôle sera alors répercutée sur la source de données. Le DataBinding vous permettra donc d’écrire une application fonctionnelle avec peu de code, puisque tout est géré automatiquement.

Les expressions de DataBinding sont placées dans des balises particulières : <#%%>

DataBinding unidirectionnel

Le DataBinding unidirectionnel permet l’affichage de données, mais pas la mise-à-jour. Vous pouvez afficher le résultat de n’importe quel code, pourvu que sa portée vous le permette, comme le montre les exemples suivants :

Lier à :

Code

Une propriété

<%# AccountNumber %>

Une collection

<asp:ListBox DataSource="<%# someCollection %>" … />

Une expression

<%# item.Price * item.Count %>

Le résultat d’une méthode

<%# GetPrice(item) %>

Notez que nous utilisons la propriété DataSource pour lier une ListBox à une collection. Cela permet d’afficher le contenu de la collection dans la ListBox (la méthode ToString() sera appelée sur chaque objet pour définir la chaine qui sera affichée dans la liste).

Methode Eval()

La méthode Eval() est utilisable dans les templates de certains contrôles supportant le data-binding, comme le GridView, DetailsView, FormView, … (nous reverrons ces contrôles en détails plus tard).

Ces contrôles d’affichage de données affichent des enregistrements. Chaque enregistrement est composé de champs, à l’image d’un enregistrement dans une base de données.


La méthode Eval() permet de récupérer la valeur d’un champ de l’enregistrement courant. Vous pouvez donc vous en servir pour lier un contrôle (TextBox, Label, …), à un champ de l’enregistrement courant. Il s’agit d’un binding unidirectionnel ; autrement dit, cela permettra l’affichage de la valeur du champ, mais pas la mise-à-jour.

Cette méthode n’est utilisable qu’au sein d’une expression de data-binding, i.e. entre les balises <%# et

%>.

Exemple :

<asp:TextBox

      ID="EditFirstNameTextBox"

      RunAt="server"

      Text='<%# Eval("FirstName") %>'

/>

Notez l’utilisation de simple quottes au lieu des double quottes pour l’attribut Text.

Data-binding bidirectionnel, méthode Bind()

La méthode Bind() s’utilise de la même manière que la méthode Eval(), mais établit un data-binding bidirectionnel plutôt qu’unidirectionnel.

Le data-binding bidirectionnel permet d’une part l’affichage de donnée et d’autre part la mise-à-jour de ces données. Par exemple, en liant une TextBox à un champ de l’enregistrement courant avec la méthode Bind(), la TextBox affichera la valeur du champ, et une modification de la valeur de la TextBox sera répercutée sur le champ correspondant.

Exemple :

<asp:TextBox

      ID="EditFirstNameTextBox"

      RunAt="server"

      Text='<%# Bind("FirstName") %>'

/>

Méthode DataBind()

Les expressions de data-binding (entre les balises <%#%>) ne sont évaluées qu’à l’exécution, lors de l’appel à la méthode DataBind().

La méthode DataBind() peut être appelée sur la page, ou sur un contrôle supportant le data-binding. Lors d’un appel sur la page, DataBind() est automatiquement appelée sur tous les contrôles de la page supportant le data-binding.

La méthode DataBind() de certains contrôles (GridView, DetailsView, FormView, …) est automatiquement appelée lors de l’événement PreRender du contrôle.

Cependant, il vous sera parfois nécessaire d’appeler cette méthode manuellement sur ces contrôles ; par exemple : pour un rafraichissement de l’affichage par rapport à la source de donnée ou si vous définissez la source de données au moment de l’exécution.

5.2.2.   Les types de sources de données

Qu’est-ce qu’une source de données ?

Une source de données représente un ensemble de données provenant d’une source telle qu’une base de données, un fichier XML, etc…

Une source de données permet non seulement la lecture de ces données, mais également la modification, selon le pattern CRUD (Create, Read, Update, Delete).

Selon le type de source de données, vous aurez également accès à des fonctions telles que le tri, le filtrage, ou la pagination de vos données.

Cependant, une source de données ne possède aucune fonctionnalité d’affichage. Vous utiliserez généralement les contrôles serveurs mis à votre disposition tels que GridView, DataList… pour afficher les données provenant d’une source de données. 

Sources de données prédéfinies

Bien que vous puissiez créer vos propres types de source de données, vous utiliserez la plupart du temps les types qui vous sont proposés par la plateforme .NET, et qui sont prêts à l’emploi :

        -     SqlDataSource

Utilise les providers d’ pour la manipulation de données provenant de bases de données SQL Server, OLE DB, ODBC ou Oracle.

        -    AccessDataSource

                Une     source     de    données    donnant     accès     à    une     base    de     données    Access.

        -     XmlDataSource

Une source de données permettant de travailler avec un fichier XML. Cette source de données est particulièrement utile pour les contrôles qui présentent les données de manière hiérarchique, comme le TreeView ou le Menu.

        -     ObjectDataSource

Vous permet de créer une source de données à partir de des objets de votre couche métier. Vous pourrez par exemple utiliser une collection d’objets comme source de données. Nous reparlerons plus en détails de ce type de source de données plus tard.

        -     SiteMapDataSource

Permet d’utiliser un fichier XML qui contient, dans un format donné, le plan de votre site (liste des pages web, organisées hiérarchiquement) comme une source de données. Ce type de source est utilisé par des contrôles de navigation comme SiteMapPath, Menu ou TreeView.

5.2.3.   ObjectDataSource

ObjectDataSource est l’un des types de source de données prédéfinis dans la plateforme .NET. Une source de ce type vous permet d’effectuer un data-binding entre un contrôle d’affichage de données, comme le GridView, et les objets de votre couche métier.

L’ObjectDataSource permet la lecture, l’édition (pattern CRUD) et le tri de vos données.

Commençons par notre classe métier, qui définit une catégorie par un ID et un nom :

public class Category

{

      private int m_nID;        private string m_strName;

      public int ID

      {

            get { return m_nID; }

            set { m_nID = value; }

      }

      public string Name

      {

            get { return m_strName; }

            set { m_strName = value; }

      }

}

Remarquez qu’il est important d’utiliser des propriétés, plutôt que des membres publics, pour que le data-binding fonctionne (et de toute façon, ça ne serait pas propre ;)).

Il nous faut maintenant des fonctions implémentant le pattern CRUD.

public class DataManager

    public IEnumerable<Category> GetAllCategories()

    {

        // return ;

    } 

    public void CreateCategory(string name)

    {

        //

    } 

    public void UpdateCategory(int id, string name)

    {

        //

}      public void DeleteCategory(int id)

    {

        //

    }

}

Ces méthodes seront automatiquement appelées par la source de données. Elles doivent implémenter les accès aux données (sérialisation, base de données, etc…).

Créons maintenant notre source de données. Dans l’éditeur visuel, glisser/déposer un ObjectDateSource dans votre page. Choisissez Configure Data Source dans le SmartTag :

L’écran de configuration vous permet alors de sélectionner la classe de votre couche métier qui contient les définitions des méthodes du pattern CRUD (DataManager, dans notre cas). Vous pouvez ensuite sélectionner chaque méthode pour la sélection, la mise-à-jour, l’insertion et la suppression.

Une fois la configuration terminée, le code suivant est généré :

<asp:ObjectDataSource ID="ObjectDataSource1" runat="server"

    TypeName="DataManager"

    DeleteMethod="DeleteCategory" InsertMethod="CreateCategory"

    SelectMethod="GetAllCategories" UpdateMethod="UpdateCategory">

<DeleteParameters>

        <asp:Parameter Name="id" Type="Int32" />

</DeleteParameters>

<UpdateParameters>

        <asp:Parameter Name="id" Type="Int32" />

        <asp:Parameter Name="name" Type="String" />

</UpdateParameters>

<InsertParameters>

        <asp:Parameter Name="name" Type="String" />

    </InsertParameters>

</asp:ObjectDataSource>

On y retrouve le nom de notre classe métier, les noms des méthodes, et la liste des paramètres de chaque méthode, qui ont été automatiquement détectés.

Votre source de données est maintenant prête. Vous allez pouvoir l’utiliser, par exemple, avec un contrôle d’affichage des données qui supporte la data-binding, tel que le GridView, le DataList, etc…

5.2.4.   Affichage de données

La plateforme .NET vous propose plusieurs contrôles serveurs permettant l’affichage de données.

Le GridView

Le contrôle GridView va permettre d’afficher des informations de manière tabulaire à partir d’une source de données. Il propose plusieurs fonctionnalités telles que le tri de ces données, la pagination (permet de déterminer le nombre d’éléments affichés par page), la sélection, la suppression et  la modification d’un enregistrement.

Glissez/déposez un GridView sur votre page (celle qui contient l’ObjectDataSource ajouté dans la partie précédente). A l’aide du SmartTag, vous pouvez lier le GridView à la source de donnée précédemment créée. De plus, en cochant les cases « Enable Editing » et « Enable Deleting », le GridView ajoutera automatiquement des liens pour l’édition et la suppression

 

Renseignez la propriété DataKeyNames du GridView pour indiquer la ou les colonnes qui forment la clé primaire. Dans notre exemple, nous utiliserons :

DataKeyNames="ID"

Cela permet à de savoir quelle colonne doit être utilisée pour identifier un enregistrement lors des opérations de mise-à-jour et de suppression.

A ce stade, le GridView est fonctionnel, avec des capacités d’édition et de suppression, pourvu que ces fonctionnalités aient bien été implémentées dans le DataSource.

La liste des catégories est obtenue par un appel à la méthode définie par la propriété SelectMethod de la source de données (ObjectDataSource).

Un click sur le lien Edit fait apparaitre des contrôles qui permettent à l’utilisateur d’éditer la ligne :

Lors de la validation (click sur Update) la méthode définie par la propriété UpdateMethod de notre ObjectDataSource est appelée, les valeurs des champs étant passées en paramètre.

Grâce à l’option Autoformat du SmartTag, vous allez pouvoir modifier l’apparence de votre GridView pour lui appliquer l’un des styles prédéfinis. Par exemple, en sélectionnant le style « Professional », on obtient :

 

Le GridView est donc utile pour afficher un ensemble d’enregistrements. Cependant, il ne permet la saisie d’un nouvel enregistrement. Il existe d’autres types de contrôles d’affichage de données, plus ou moins appropriés selon les cas.



Le DataList

Le DataList permet l’affichage d’un ensemble d’enregistrements. Contrairement au GridView, le DataList utilise le principe des templates (modèles), plutôt qu’un tableau, pour afficher les enregistrements.

Par exemple, en liant le DataList à la précédente source de données (ObjectDataSource), le code suivant est généré :

<asp:DataList ID="DataList1" runat="server"

              DataSourceID="ObjectDataSource1">     <ItemTemplate>

        ID:

<%

# Eval("ID")

%>

        <asp:Label ID="IDLabel" runat="server"

                   Text='                 '></asp:Label><br />

        Name:

<%

# Eval("Name")

%>

        <asp:Label ID="NameLabel" runat="server"

                   Text='                   '></asp:Label><br />

        <br />

    </ItemTemplate>

</asp:DataList>

Vous avez donc un contrôle complet de la représentation d’un élément de la liste : il vous suffit d’éditer le code de présentation. Ici, l’éditeur a généré des Labels pour l’affichage des valeurs ID et Name.

Remarquez que le code de présentation se trouve dans une balise ItemTemplate. Il s’agit de la définition du template utilisé pour afficher un élément de la liste. Il existe d’autres templates, voici la liste complète :

AlternatingItemTemplate

(facultatif)

Ce modèle définit la représentation qui sera utilisée pour un élément sur deux. Cela permet d’alterner deux représentations différentes (effet de style).

EditItemTemplate

(facultatif)

Ce modèle définit la représentation d’un élément lorsqu’il est en cours d’édition. Ce modèle doit donc contenir des contrôles permettant la

saisie de données, comme les TextBoxes, etc…

SeparatorTemplate

(facultatif)

Ce modèle permet de définir des éléments qui seront placés entre chaque élément de la liste, utilisés comme séparateurs.

Vous pouvez éditer les templates visuellement en cliquant sur Edit Templates dans le SmartTag.

Bien sur comme pour le GridView, vous pouvez utiliser l’Autoformat pour utiliser l’un des styles prédéfinis :

 

Le FormView

Le FormView permet de travailler avec un enregistrement unique. Il permet l’affichage, l’édition, l’insertion et la suppression d’enregistrements. Ce contrôle est basé sur les templates : vous pouvez définir un template pour l’affichage, un template pour l’édition, etc… 

Le plus souvent, ce contrôle est utilisé conjointement avec un contrôle permettant de sélectionner un enregistrement dans une liste, comme le GridView ou le DataList. Il peut afficher un enregistrement dont l’ID est passé en paramètre de la page, par exemple. 

Le DetailsView

Le DetailsView permet de travailler avec un enregistrement unique. Il permet l’affichage, l’édition, l’insertion et la suppression d’enregistrements.

Contrairement au FormView, vous n’êtes pas libre de la mise en page de l’affichage car le DetailsView utilise un affichage tabulaire. Une colonne sera créée pour le nom du champ, puis une autre pour la valeur. Chaque ligne correspond à une colonne de l’enregistrement.

Exemple :

 

Le Repeater


Le Repeater est similaire au DataList, dans le sens ou il sert à afficher une liste d’éléments en répétant pour chaque élément un code de présentation que vous pouvez définir.

Cependant, il existe quelques différences majeures :

-    Le Repeater ne permet pas l’édition ou la sélection d’enregistrements.

-    Il est le seul contrôle qui permette de répartir des balises XHTML sur des templates différents.

Vous pouvez par exemple l’utiliser pour générer une liste d’éléments (balises <ul>…</ul>) :

-    Placer une balise <ul> dans le template t’entête (HeaderTemplate)

-    Placer une balise <li>…</li> dans le template d’affichage d’un enregistrement (ItemTemplate)

-    Placer une balise fermant la liste </ul> dans le template du pied de page (FooterTemplate)

Exemple :

<asp:Repeater runat="server" DataSourceID="ObjectDataSource1">

<%

# Eval("Name")

%>

    <HeaderTemplate><ul></HeaderTemplate>

    <ItemTemplate><li>                   </li></ItemTemplate>

    <FooterTemplate></ul></FooterTemplate> </asp:Repeater>

5.3.      Partie 3 : Debug, Trace, Cache

5.3.1.   Debuger une application

La plupart du temps, il est impossible de réaliser des applications parfaites sans erreurs dès le premier test. Parfois le développeur n’arrive pas à trouver les erreurs car certaines applications peuvent être très complexes.

Le Framework .NET met à disposition du développeur des outils de débogage qui vont permettre de faciliter la recherche d’erreurs en regardant pas à pas le fonctionnement d’une application . 

Pour activer le débogage au sein de vos applications , il faut que vous ajoutiez à votre fichier de configuration Web l’élément « Compilation » dans la section « Configuration » : 

<configuration>

      <>

            <compilation debug="true"/>

      <>

</configuration>

Vous pouvez ensuite placer des points d’arrêt dans le code de votre application pour ensuite la déboger pas à pas.

5.3.2.   Utiliser les informations de trace

Présentation

Pour déboguer une application, il est parfois utile d’afficher la liste de toutes les variables de l’application et d’y ajouter ses propres messages. Le trace va permettre tout cela. Nous allons voir qu’il existe deux types de traçage : 

•    Traçage au niveau de la page.

•    Traçage au niveau de l’application.

Traçage au niveau de la page

Il est possible d’ajouter un système de traçage au niveau de la page en ajoutant un attribut Trace dans la directive « Page » de votre fichier aspx :

 

<%

@ Page Trace="true"

%>

Pour afficher vos propres messages au sein du trace, il suffit d’utiliser les méthodes « Write » et « Warn » de la classe «Trace » : 

Trace.Write("My message");

("My message");

La seule différence entre la méthode « Write » et la méthode « Warn » est qu’avec la méthode Warn, le texte apparaîtra en rouge.

Ces Traces n’apparaissent que si le l’attribut Trace dans le source ASPX est positionné, ou alors si le Trace est activé dans le fichier de configuration. On peut tester le Trace pour savoir s’il est activé :

if (Trace.IsEnabled)     //

Traçage au niveau de l’application

Le Trace peut aussi se configurer au niveau de l’application, et il n’est plus alors nécessaire de l’activer dans chaque page puisqu’il sera effectif pour toutes les pages de votre application. L’avantage de passer par l’application est que le Trace affichera plus d’information, comme des informations de Session et d’Application, les paramètres du formulaire, …

Pour cela, il suffit d’ajouter l’élément « trace » dans le fichier de configuration Web : 

<configuration>

  <>

    <trace enabled="true"/>

  <>

</configuration>

Dans ce cas, toutes les informations que vous avez pu écrire dans vos pages via les méthodes « Write » et « Warn » apparaîtront à l’exécution dans vos pages. Pour accéder aux données de Trace complémentaires, utilisez une URL du style : où myapplication correspond à votre répertoire virtuel. Vous verrez ainsi apparaître les informations de statistiques sur votre application Web.

Dans le fichier de configuration, voici les paramètres de Trace :

•    enabled

Détermine si le Trace est activé ou pas. Par défaut la valeur est à « false ».

•    pageOutput

Indique si le Trace sera affiché à la fin de chaque page. Par défaut la valeur est à « false ».

•    requestLimit

Nombre maximum de Trace que peut stocker le serveur. Par défaut la valeur est à « 10 ».

•    traceMode

« SortByTime » et  « SortByCategory » sont les deux valeurs possibles. 

       ?    localOnly

Indique si le Trace n’est visible que localement sur le serveur. Par défaut la valeur est à « true ».

Exemple :

<configuration>

  <>     <trace       enabled="true"

      traceMode="SortByCategory"       requestLimit="40"       pageOutput="false"       localOnly="true"

    />

  <>

</configuration>

5.3.3.   Gestion du cache

Présentation

Le Cache est une technique permettant d’optimiser les réponses des applications. Cela consiste à stocker en mémoire des données qui ne changent que très rarement, pour éviter ainsi à chaque appel d’avoir à interroger la base de données par exemple. Sous , on peut mettre en Cache toute une page, une partie d’une page ou d’autres données. L’espace de nom .Caching fournit des classes pour l’objet Cache.

Cache d’une page

Par exemple, pour mettre une page en Cache, ajoutez la directive suivante en haut de votre fichier ASPX :

 

<%

@ OutputCache Duration="10" VaryByParam="None"

%>

« Duration » représente la durée de stockage de la page en Cache, exprimée en secondes. Dans l’exemple précédent, le Cache ne dépend d’aucun paramètre. Le Cache peut être dépendant des paramètres passés dans la requête GET ou dans la requête POST. Pour cela, on peut utiliser l’attribut « VaryByParam ».

Par exemple, si votre page affiche un enregistrement dont l’ID est passé en paramètre (en GET ou en POST), vous pouvez utiliser la directive suivante :

 

<%

@ OutputCache Duration="10" VaryByParam="ID"

%>

Dans l’attribut « VaryByParam », on peut mettre plusieurs paramètres, séparés par des points-virgules.


Note : Pour mettre en Cache des parties de page, il suffit d’utiliser des Contrôles Utilisateurs et d’y ajouter la directive OutputCache dans le fichier ASCX. Ainsi, seul ce fichier sera mis dans le cache, et non plus toute la page.

Cache de données

Il existe un objet global Cache permettant de stocker tout ce que vous voulez dans le Cache de votre application. Exemple :

Cache["mykey"] = myValue; myValue = Cache["mykey"];

Mais le Cache est beaucoup plus évolué qu’une simple gestion attribut = valeur puisqu’il permet :

•    D’enlever du Cache les données inutilisées

•    D’ajouter une date d’expiration (soit une date fixe comme 7h00, ou une durée comme 10 minutes depuis le dernier accès)

•    D’ajouter des dépendances sur des fichiers ou des clés de la base de registre (si le fichier est modifié, le contenu de ce fichier est automatiquement rechargé dans le Cache)

Par exemple, pour ajouter une dépendance vers un fichier, il faut utiliser la méthode suivante :

Cache.Insert("MyData", Source,                   new CacheDependency(Server.MapPath("Filename")));

5.4.     Personnalisation et navigation

5.4.1.   Personnalisation

La personnalisation est un procédé d'ASP .NET 2 qui permet de stocker des données non éphémères sur l'utilisateur. Le principe est simple, l'utilisateur saisie des informations qui seront enregistrées dans une base de données. Pour pouvoir utiliser cette méthode, il faut préalablement avoir configuré la base de données grâce à aspnet_regsql. Une fois cette étape réalisée, vous pourrez stocker toutes les informations voulues dans cette dernière.

Dans un premier temps il va falloir définir les informations que l'on désire stocker dans la base de données. Pour cela, nous allons modifier le fichier de configuration web.config.

Dans un premier temps, nous allons créer une section <profile> dans la section <>. Nous allons ensuite l'activer, pour cela rajouter l'attribut enabled="true" à profile. Puis il faut ensuite ajouter une nouvelle section <properties> dans cette dernière. Pour ajouter une nouvelle information, il faut créer un nœud <add /> avec les attributs suivants :

-    name : Représente le nom de l'information

-    type : Représente le type dans lequel sera stockée l'information

-    defaultValue : Cet attribut est facultatif, il permet de définir une valeur par défaut à l'information.

Le fichier de configuration pourrait être le suivant :

    <roleManager enabled="true" />

    <profile enabled="true" >

      <properties>

        <add name="Name" type="System.String" />

        <add name="Birthday" type="System.DateTime" />

        <add name="cnxCount type="System.Int32" defaultValue="0" />

      </properties>

    </profile>

  <>

</configuration>

Dans cet exemple, nous stockons le nom au format String, la date de naissance au format DateTime et le nombre de fois que l'utilisateur se connecte au format Int32.

Ensuite il pourrait être utile d'enregistrer et de consulter ces informations. Nous allons pour cela utiliser la classe Profile. Toutes les informations qui ont été saisies dans le fichier de configuration sont automatiquement ajouter comme attributs à la classe Profile. Ces propriétés sont accessibles en lecture et écriture. 

= "Toto";

Profile.Birthday = DateTime.Today; Profile.CnxCount++; = ;

= Profile.Birthday.ToString(); = Profile.CnxCount.ToString();

Dans cet exemple nous définissons le nom de l'utilisateur courant comme "Toto", la date d'anniversaire comme étant la date courante et nous incrémentons le compteur.

Avec cette méthode, si l'utilisateur n'est pas authentifié, il se produira une erreur. C'est pour cela que qu'il est également possible de stocker des informations pour des utilisateurs non authentifiés. Prenons l'exemple d'un site de vente en ligne, il est très fréquent que le client puisse avant de s'identifier mettre des articles dans un cadi. Ces informations seront alors stockées dans les cookies. Pour cela, il va falloir ajouter la ligne suivante dans la section <> :

<anonymousIdentification enabled="true" cookieless="AutoDetect" />

Ensuite pour chaque information, il faudra définir qu'elle peut être utilisée par un utilisateur anonyme, pour cela il faudra lui rajouter l'attribut allowAnonymous="true". Nous allons modifier le fichier de configuration précédent pour que toutes les informations puissant être utilisées par un utilisateur anonyme.

De plus, il serait utile, lorsque l'utilisateur s'authentifie, de récupérer les informations contenues dans son profil anonyme. Pour cela nous allons utiliser Profile_onMigrateAnonymous dans .

protected void Profile_onMigrateAnonymous(object sender, 

ProfileMigrateEventArgs e)

{

  ProfileCommon currentProfile = Profile.GetProfile(e.AnonymousID);   if (currentProfile != null)

  {

    = ;

  }

}

Dans cet exemple nous migrons le nom contenu dans le profile anonyme vers celui de l'utilisateur authentifié.



5.4.2.   Aide à la navigation

Dans un site web, il est indispensable, pour un utilisateur de pouvoir naviguer sur ce dernier. C'est pourquoi il faut le structurer et de créer un menu pour permettre à l'utilisateur de se déplacer dans cette hiérarchie. Il peut être long et fastidieux de mettre en place toute cette navigation, c'est pour cela que le framework 2 fourni un grand nombre d'outils pour réaliser ces différentes opérations. Dans cette partie, nous allons étudier tous ces composants et nous allons voir comment les utiliser. Il faut savoir qu'il existe principalement 3 contrôles :

-    treeview

-    menu

-    siteMapPath

Nous allons les étudiez un peu plus en détails dans la suite de ce cours. Dans un premier temps nous allons voir le fichier Web.sitemap sur lequel se base les autres contrôles.

Web.sitemap

Le fichier Web.sitemap permet de définir toute la structure de l'application ASP .NET. C'est dans ce dernier que sera définit la structure du site web. Pour l'ajouter, faire un clic droit sur le site web, faire "Ajouter un nouvel élément".

Un nouveau fichier nommé Web.sitemap a été créé. Ce fichier est au format XML.

  <siteMapNode url="" title="" description="">

    <siteMapNode url="" title="" description="" />

    <siteMapNode url="" title="" description="" />

  </siteMapNode>

</siteMap>

Comme on peut le constater, ce fichier n'est pas vide, il contient une esquisse de structure. En effet, le nœud <siteMapNode> permet de représenter un élément de la structure. On remarque donc que dans le fichier fournis, nous avons un premier nœud composé de deux autres. Bien entendu il est tout à fait possible de changer cela pour avoir sa propre structure. On remarque également qu'un nœud est composé des attributs suivant :

-    url : Représente la page correspondant au nœud

-    title : Représente le nom qui sera affiché dans le menu

-    description : Ceci est le texte qui apparaîtra lorsque l'on survolera l'élément dans le menu

Supposons que l'on veuille réaliser cette structure :

? Default page o Our activity

§  Our computing page

§  Our Hardware o Contact us

Le fichier XML correspondant sera le suivant :

<?xml version="1.0" encoding="utf-8" ?>

<siteMap xmlns="; >

  <siteMapNode url="" title="Default page" description="Default page of website">     <siteMapNode url="" title="Our activity" description="This page presents our activity">       <siteMapNode url="" title="Our computing page"                      description="View our computing skill" />       <siteMapNode url="" title="Our Hadware" description="Visit this page to view our hardware" />

    </siteMapNode>

    <siteMapNode url="" title="Contact us" description="Use this page to contact us" />

  </siteMapNode>

</siteMap>

Treeview

Le composant Treeview va permettre d'afficher en une seule fois toute la hiérarchie du site :

 

Pour que le contrôle Treeview puisse générer automatiquement toute la hiérarchie, il faut lui ajouter une source de données. Pour cela, il faut aller dans les propriétés du TreeView, pour DataSourceID, choisir "<New data source…>"


 

Il faut ensuite choisir l'élément "Site Map", il faut ensuite spécifier le nom de la source de donnée et cliquer sur "OK".

 

Le Treeview prendra automatiquement en compte toute la structure définie dans le Web.sitemap.

-    BackColor : Permet de spécifier la couleur d'arrière-plan du contrôle.

-    BorderColor : Permet de spécifier la couleur de la bordure.

-    DataSourceID : Permet de spécifier la source de données.

-    ExpandDepth : Cette propriété permet de choisir le niveau d'affichage de la hiérarchie

-    ImageSet : Permet de choisir une image prédéfinie pour représenter les nœuds.

Menu

Le composant Menu quand à lui permet d'afficher la structure mais de manière dynamique :

Comme précédemment, il faudra configurer la source de données pour pouvoir générer le menu. Voici quelques propriétés utiles :

-    BorderStyle : Permet de choisir le style de la bordure

-    DataSourceID : Permet de sélectionner la source de données

SiteMapPath

Le composant SiteMapPath permet d'afficher la location de l'utilisateur dans le site web :

Contrairement aux contrôles précédents, il n'est pas nécessaire de définir une source de données. Ainsi le SiteMapPath génèrera automatiquement sa hiérarchie en fonction du fichier Web.sitemap. Voici quelques propriétés utiles :

-    NodeStyle : Permet de définir le style du nœud.

-    PathDirection : Permet de choisir l'ordre d'affichage de la location

PathSeparator : Permet de choisir le séparateur pour l'affichage des différents niveaux de hiérarchies.



5