Professional Documents
Culture Documents
TDI2 GB 2008/2009Sommaire
Voici donc ce qui se passe lorsque vous, utilisateur désirant naviguer sur
une page web, générez comme action si l'application que vous désirez
atteindre est développée en ASP.NET 2.0 :
• 1 = vous tapez une url dans votre navigateur et donc, envoyez une
requête pour une page aspx d'un client web vers le serveur IIS
• 2 = la requête est analysée et le traitement est transféré au runtime, un
processus est créé pour exécuter l'application
• --> S'il s'agit de la première exécution du code de cette page, le
compilateur JIT (Just In Time) compile le code en binaire natif et le
stoque en mémoire.
• --> Si ce n'est pas la première exécution, le code binaire est chargé
depuis le cache.
• 3 = ce code binaire est exécuté puis renvoyé vers le serveur IIS
• 4 = IIS renvoie la réponse sous la forme de code HTML strict vers
l'utilisateur. Ce code HTML est affiché dans votre navigateur.
Si framework .NET n'a pas été installé après le serveur IIS, vous aurez des
problèmes d'exécution des pages aspx.
Pour remédier à cet inconvénient à postériori, vous pouvez exécuter une
commande du type :
C:\Windows\Microsoft.Net\Framework\v2.0.xx\aspnet_regiis.exe -i ou xx est la
version du Framework 2.0 présente sur votre ordinateur.
1.2.3.1. Etape 1
1.2.3.2. Etape 2
Ouvrez le bloc-notes et créez un fichier avec ce code :
1.2.3.3. Etape 3
Exécutez cette page aspx dans votre navigateur en tapant son adresse
dans la barre de navigation :
http://localhost/PremierePage/bonjour.aspx
Vous venez donc de créer votre première page ASP.NET s'exécutant sur
un serveur IIS sans avoir ouvert Visual Studio comme support de
programmation.
Il est bien évident qu'un EDI digne de ce nom vous offre une multitude
d'avantages comme la complétion du code, l'initialisation automatique
de vos pages, les contrôles utilisateurs, ... malgré que, dans quelques
cas, il est parfois plus avantageux de coder directement son contrôle
dans la page HTML plutôt que de passer par le Designer de l'EDI.
Que vous utilisiez Visual Studio ou Visual Web Developper (EDI gratuit
et téléchargeable sur le site de Microsoft France), le démarrage de votre
application sera presque le même. La seule différence vient du fait que
Visual Studio étant un EDI qui regroupe plusieurs possibilités de
développement, vous devrez spécifier que vous désirez travailler avec
un nouveau projet web avant d'arriver sur cette page de configuration :
Reprenons notre EDI et, après avoir bien configuré les données au
niveau du serveur et du nom de l'application, l'interface doit maintenant
ressembler à ceci :
Vous pouvez remarquer que l'interface des applications ASP.NET diffère des
applications Winforms mais nous y retrouvons quand même pas mal de points
communs, notamment :
A ce point, nous avons des contrôles placés sur une page aspx, mais
encore aucune action n'est définie. Vous avez beau taper un nom dans
"TextBox1" et cliquer sur le "Button1", rien ne se passe. En effet, il faut
associer un événement au bouton "Cliquez". Pour ce faire, double-
cliquez sur le bouton en mode design et l'environnement de
développement va créer une méthode associée à l'événement "Click" du
bouton :
Par défaut, le débogage n'est pas activé au niveau des applications web.
On vous conseille fortement de l'activer en répondant OK avec la
première option cochée.
1.3.2.1. Application
Evénement Description
Exécuté lors du premier appel à une page du site
Application_Start
depuis le démarrage de IIS
Appelé lorsque l'application se termine, cela ne
Application_End signifie pas que IIS s'arrête mais est d'office appelé
si, pour une raison quelconque IIS est arrêté
1.3.2.2. Session
Evénement Description
appelé lors de chaque nouvelle session
Session_Start
d'un navigateur client
fin de session : lors d'un timeout ou
lors d'une destruction explicite
Session_End
(Session.Abandon()) via un lien "Log
Out" par exemple
Il faut aussi savoir qu'une session peut stocker ses données en mode
"InProc" (dans le process en mémoire) ou en mode "Sql..." (dans une
BD SqlServer) via la base de données "AspNetState".
Application et Session sont des notions très importantes en ASP.NET.
Document Millésime Page
OFPPT @ C-A-001.doc février 09 10 - 45
Module 25 DEVELOPPEMENT DES APPLICATIONS WEB DYNAMIQUES
TDI2 GB 2008/2009Sommaire
Elles jouent en effet un rôle très actif au niveau de la vie d'un site et,
notamment, au niveau de la pérennité des données véhiculées dans le
site lui-même.
1.3.2.3. PostBack
IsPostBack
Une page ASP.NET est généralement utilisée plusieurs fois à la suite, dans une série
d'échanges avec l'utilisateur.
Supposons qu'une page d'accueil (accuei 1. htm) soit affichée. L'utilisateur clique
sur un lien qui conduit à la page saisie.aspx. Comme l'extension de la page est
Pour créer une application qui met en évidence la propriété IsPostBack, vous
pouvez effectuer les manipulations suivantes :
o Créez un nouveau projet Application Web ASP.NET.
o Supprimez la page initiale Default.aspx et ajoutez un nouveau formulaire Web
appelé Saisie.
TRAVEAUX PRATIQUES :
Private Sub
btnAfficheNom_Click(...)
Handles btnAfficheNom.Click
' Affiche le contenu de la variable
IblNom.Text = Nom End Sub
1.3.4. ViewState
Prenons un peu le temps de voir le code HTML de la page exécutée :
Vous constatez que des champs cachés ont été générés. Le champ
nommé _VIEWSTATE .
NOTE :Pour que l état d affichage soit opérationnel, il faut que la propriété EnableviewState de la
page soit True.
ViewState("Nom") = Value
Nom = ViewState("Nom")
on peut remplacer la déclaration de la variable Nom par une propriété de même nom et
qui utilise l'objet StateBag :
1.3.5. Cookies
Pour écrire un cookie, qui est un couple nom-valeur, il suffit de lui donner une valeur, en indiquant
son nom comme paramètre de la collection Cookies. Si le cookie existait déjà, il est remplacé,
dans le cas contraire, il est créé :
Un cookie écrit de cette façon n'est pas permanent : il n'existe qu'en mémoire, donc pendant la
durée de l'application. Il disparaîtra quand celle-ci s'arrêtera.
Pour rendre un cookie permanent, il faut indiquer une date d'expiration. Par exemple :
Le cookie sera alors écrit sur le disque de l'utilisateur et y restera jusqu'à la date d'expiration
ou jusqu'à ce qu'il soit effacé.
On peut lire un cookie en utilisant la même collection Cookies, maie appliquée à l'objet
HttpRequest. Voici le code qui relit le cookie écrit précédemment :
Si le cookie existait dans cette application, sa valeur est retournée. Dans le cas contraire, la valeur
de retour est une chaîne de caractères vide.
L'ensemble des cookies d'une application est transmis avec chaque demande de l'utilisateur. Il est
donc préférable de ne placer que de petites quantités de données dans les cookies, afin de ne pas
grossir la trame HTTP circulant sur le réseau, d'autant plus que la taille d'un cookie est elle-même
limitée.
La page exemple SaisieNom dispose d'un bouton Affiche avec cookie. Quand l'utilisateur
clique dessus, le contenu du champ de saisie est placé dans un cookie temporaire appelé
Nom. L'application est ensuite redirigée vers une autre page, à l'aide de la méthode Redi -rect de
l'objet HttpResponse :
Si la variable du nom indiqué existait déjà, sa valeur est remplacée, sinon elle est créée.
L'utilisation de variables d'application est donc extrêmement simple.
• Les variables d'application sont stockées dans le serveur Web qui les crée. Dans le cas
d'une ferme de serveurs (plusieurs serveurs qui jouent des rôles semblables), la
demande d'un utilisateur peut être dirigée vers un serveur ou un autre selon leur
charge. Une application peut donc ne pas disposer des données créées par la même
application sur un autre serveur.
• Lors de la modification de la valeur d'une variable d'application, il existe un risque que
d'autres utilisateurs effectuent un changement de la même variable au même
moment. Il convient donc de synchroniser l'accès à ces variables, comme cela est
montré dans l'exemple suivant.
•
On place donc généralement dans les variables d'application des données en lecture
seule. Ces variables sont alors utilisées comme une sorte de cache pour des
données qui ne varient pas ou peu pendant la durée de vie de l'application.
Il faut cependant bien initialiser les variables d'application quelque part. Cela peut être fait
quand l'application démarre, en plaçant du code spécifique dans le fichier global.asax de
l'application qui est ajouté à un projet Web par Visual Studio .NET lors de sa création. Ce
fichier comprend des données et du code globaux à l'application. On peut notamment y
ajouter des procédures qui seront appelées par le serveur Internet quand certains
événements se produiront. Il suffit, pour cela, de dériver une classe de la classe
HttpApplication et d'y écrire les programmes nécessaires.
Pour gérer les variables application, on peut écrire du code dans les procédures suivantes :
• Init et Application_OnStart sont appelées au démarrage de l'application. On y insère
donc généralement le code d'initialisation des variables.
• Dispose et Application_OnEnd sont appelées quand l'application se termine.
Une application démarre la première fois qu'un utilisateur appelle une page qui en
fait partie. Si le serveur
Web est arrêté, elle l'est aussi. D'autre part, si le fichier global .asax est modifié,
l'application est arrêtée puis redémarrée.
La page AfficheNomApplication affiche une donnée placée dans une variable Application
appelée Nom par la page appelante, SaisieNom. Celle-ci exécute le code suivant lors du clic
sur
le bouton Affiche avec application:
Private Sub btnOKApplication_Click(...) Handles btnOKApplication.Click
Application.Lock()
Application("Nom") = txtNom.Text -
Application.Unlock()
Response.Redirect("AfficheNomApplication.aspx")
End Sub
On peut remarquer dans ce code que l'affectation de la valeur à la variable Application est
accompagnée d'un appel aux méthodes Lock puis UnLock. Lock verrouille l'objet Application
afin d'éviter qu'une modification y soit effectuée en même temps par un autre thread.
Vous pouvez remarquer que le code de traitement de l'événement Load affiche également les
valeurs de deux autres variables (figure 7-10). Celles-ci ont été initialisées dans des procédures
événement de Global .asax :
End Sub
Sub Application_OnStart(ByVal sendèr As Object, ByVal e As EventArgs)
Application(“OnStart") = "Donnée initialisée dans Application_OnStart"
End Sub
End Class
(appelé Global par défaut) déclaré dans Global .asax. Cela n'est cependant
pas possible, car il peut exister plusieurs objets Application créés à partir de la
classe Global. Quand une page est appelée sur le serveur, ASP.NET peut, soit
fabriquer un nouvel objet Global, soit utiliser un objet existant. On ne peut donc
pas avoir de certitude sur l'objet Global employé par une page, et ses variables
d'instance ne peuvent donc pas être mémorisées d'un appel à l'autre.
Il est cependant possible de déclarer des variables partagées dans la classe Global avec le
mot-clé Shared. Une telle variable s'utilise indépendamment de la création d'un objet, elle
est donc globale à l'application.
Voici, par exemple, une variable déclarée dans Global .asax, dans la classe Global
La variable Nom peut alors être valorisée dans une page, comme dans la page SaisieNom
à la suite d'un clic sur le bouton Affiche avec variable Shared:
La notion de session
Pour mettre en uvre les variables de session, ASP.NET définit une
notion de session qui comprend l'ensemble des actions d'un utilisateur
dans une application. Une session est reconnue par un identificateur
de session créé par ASP.NET. Il s'agit d'une chaîne de caractères de
120 bits (par exemple, 302dvbynpstxl3iOrugglb45), dont l'unicité est
garantie grâce à l'utilisation d'un algorithme spécifique. De plus, la
structure de cette chaîne est non triviale, ce qui évite qu'elle soit
manipulée à l'insu du système (par exemple, pour se faire passer
pour quelqu'un d'autre).
Quand un nouvel utilisateur appelle une page d'une application
ASP.NET pour la première fois, un nouvel identificateur lui est attribué.
Celui-ci accompagne ensuite toutes les réponses du système et les
| IbISessionID.Text = Session.SessionID
<configuration>
<system.web
>
<sessionState
mode="InProc"
stateConnectionString="tcpi p=12 7 . 0 . 0 . 1 : 42424"
sqlConnectionString="datasource=127.0.0.1;user
id=sa;password="
cookieless="false"
timeout="20"
/>
</system.web>
</configuration>
| Session.Abandon
Cela peut être effectué, par exemple, en réponse à un clic de l'utilisateur sur un bouton de
déconnexion placé sur la page. Après la fermeture d'une session, automatiquement ou
manuellement, toutes ses données sont détruites.
I II n'est pas nécessaire de mettre en uvre un mécanisme de synchronisation pour les variables de session,
| car elles ne sont normalement rejointes que par un seul thread, n'étant liées qu'à un seul utilisateur.
L'initialisation des variables de session peut se faire dans une procédure Session_OnStart (ou
Session_Start) et Session_OnEnd permet d'effectuer les traitements de fin de session. Ces
deux procédures doivent être écrites dans le fichier global .asax, comme cela a été expliqué
dans la section relative aux variables d'application.
La page AfficheNomSession affiche une variable de session initialisée lors de la saisie du nom
de l'utilisateur dans la page Sai si eNom. Elle affiche également la valeur d'une variable
initialisée dans la procédure Session_OnStart .
La valorisation de la variable à la suite de la saisie du nom est effectuée par le code suivant
Private Sub btnOKSession_Click(...) Handles btnOKSession.Click
Session("Nom") = txtNom.Text
Response.Redi rect("AfficheNomSessi
on.aspx")
End Sub
L'initialisation des variables dans global .asax est :
Sub Application_OnStart(ByVal sender As Object, ByVal e As EventArgs)
Application("OnStart") = "Donnée initiaïisée dans
Application_OnStart"
End Sub
Sub Session_Start(ByVal sender As Object, ByVal e As EventArgs)
Session("Start") = "Donnée initialisée dans
Session_Start" End Sub
Enfin, l'affichage des variables est réalisé par le code suivant
Private Sub Page_Load(...) Handles MyBase.Load
IblNom.Text = Session("Nom")
IbISessionID.Text = Session.SessionID
IblSession.Text = Session("Start")
IblSessionl.Text = Session("OnStart")
End Sub
Le contexte
La propriété Context d'une page retourne l'objet HttpContext associé à la page. Celui-ci fournit
des informations sur la requête HTTP ayant provoqué son appel. Parmi les membres de la classe
HttpContext, la propriété Handler donne accès à un objet HttpHandler qui représente la page à
l'origine de l'appel. Cela permet d'accéder à ses données.
Pour que le contexte permette de récupérer les données de la page précédente, il faut que l'appel de
la page se fasse à l'aide de la méthode Server.Transfer et non pas Response.Redirect.
|les données du contexte ne sont valides que pour la requête en cours. Elles sont donc perdues lors de la kequête
suivante.
Le cache
Le cache d'ASP.NET est un lieu de stockage de données qui peut être utilisé à la fois
pour cacher des pages, c'est-à-dire les mémoriser afin d'éviter de les régénérer à
chaque demande, et pour enregistrer des données. Pour le stockage de données, le
cache ressemble donc à l'objet Application dans la mesure où les valeurs qui y sont
placées sont privées à l'application. Mais le cache dispose également de
mécanismes complémentaires qui permettent de contrôler la durée de vie des
données qu'il contient en libérant la mémoire quand elle n'est pas utilisée, ou de
conditionner les données à des ressources externes.
Placer des données dans le cache se fait très simplement, comme pour l'objet
Application :
On peut également utiliser les méthodes Insert et Add de l'objet Cache pour ajouter
des données dans le cache. Ces méthodes peuvent recevoir des paramètres
complémentaires permettant de définir, notamment, la durée de vie des données.
L'obtention des données du cache se fait tout aussi simplement (figure 7-14) :
Résumé
Nous avons vu que si la gestion de l'état est un véritable problème pour les
applications Web, elle dispose également de nombreuses solutions. Plusieurs
mécanismes permettent de stocker les données d'une page sur le client, ou sur le
serveur. Des techniques nouvelles dans ASP.NET permettent même de stocker les
données sur un serveur partagé par plusieurs serveurs Web.
Il est évident que cet exemple est très simpliste et que l'objet Session
permet bien d'autres utilisations. Voici quelques points liés à l'objet
Session (liste non exhaustive) :
La grande différence avec l'objet Session se situe dans le fait qu'un objet
Application conserve des données pour l'ensemble des utilisateurs
d'un même site web. Il s'utilise de la même manière que l'objet Session.
1.3.10. QueryString
QueryString permet de faire passer des informations via l'URI d'une page
à une autre.
En reprenant l'exemple d'un ID de société sélectionné dans une page
dont les données sont présentées dans une autre page, on aurait très
bien pu indiquer cet ID via l'URI lors de l'appel à la deuxième page.
Pour récupérer l'ID dans la seconde page, il vous suffira de coder comme
suit :
<p>Vous avez choisi la société : &
Request.QueryString("idsoc")</p>
Les contrôles utilisateur sont beaucoup plus faciles à créer que les
contrôles personnalisés, dans la mesure où vous pouvez réutiliser des
contrôles existants. Il est donc particulièrement facile de créer des
contrôles comportant des éléments d'interface utilisateur complexes.
Cette rubrique fournit une vue d'ensemble de l'utilisation des contrôles
utilisateur ASP.NET.
Vous pouvez utiliser sur un contrôle utilisateur les mêmes éléments HTML (sauf
les éléments html, body ou form) et les mêmes contrôles Web que dans une
page Web ASP.NET. Par exemple, si vous créez un contrôle utilisateur afin de
l'utiliser comme barre d'outils, vous pouvez placer dessus une série de contrôles
serveur Web Button et créer des gestionnaires d'événements pour les boutons.
page contient un contrôle utilisateur, celui-ci passe par toutes les étapes du
traitement qu'effectuent tous les contrôles serveur ASP.NET.
La validation côté client est donc celle qui intervient la première et se fait en
général en JavaScript. ASP.NET fournit des contrôles de validation qui génèrent
le code javascript associé, vous évitant de connaître à fond le langage et de
devoir taper le code.
• RequiredFieldValidator
• RangeValidator
• CompareValidator
• RegularExpressionValidator
• CustomValidator
• ValidationSummary
1.5.1. RequiredFieldValidator
Le plus fréquemment utilisé car il est le seul qui peut s'assurer qu'un champ
n'est pas vide. En effet, tous les autres contrôles de validation acceptent un
champ vide donc, associer ce contrôle de validation aux autres contrôles permet
cette vérification essentielle.
Le RequiredFieldValidator a donc pour fonction de vérifier qu'un champ a été
modifié. Ses propriétés principales à renseigner sont :
Nom de la
Utilisation
propriété
ControlToValidate doit contenir le nom du contrôle à valider
message à afficher en cas d'erreur dans le
ErrorMessage
contrôle ValidationSummary
contient une valeur qui invalide le contrôle si
InitialValue
celui-ci est égal à cette valeur précise
Text texte affiché en cas de non validation
<asp:RequiredFieldValidator ID="RequiredFieldValidator1"
runat="server" ControlToValidate="TxtNom" ErrorMessage="Admin
n'est pas un nom valide" SetFocusOnError="True"
InitialValue="Admin">
</asp:RequiredFieldValidator>
<asp:RequiredFieldValidator ID="RequiredFieldValidator2"
runat="server" ControlToValidate="TxtNom" ErrorMessage="Le
champ nom est obligatoire" / >
Vous remarquez que pour valider le nom qui est obligatoire, il nous faut 2
contrôles RequiredFieldValidator.
Un pour signaler que le nom ne peut pas être un champ vide, l'autre pour
interdire l'utilisation du nom "Admin".
1.5.2. RangeValidator
Comme son nom l'indique, il sera utilisé pour valider l'encodage entre des
bornes données. Par exemple, encoder un nombre entre 1 et 10.
Les propriétés sont pratiquemment identiques à celles du contrôle
précédent :
1.5.3. CompareValidator
Comparaison à un type.
1.5.4. RegularExpressionValidator
1.5.5. CustomValidator
L'utilisateur définit lui-même une fonction pour effectuer la validation lorsque les
contrôles standards ne peuvent pas assumer ce rôle.
Dans ce cas, les propriétés sont un peu différentes :
La validation côté client s'effectue avec du code javascript soit entre les balises
ad hoc, soit dans un fichier ".js" séparé.
Ce genre de code est bien connu des développeurs javascript :
<script language="javascript">
function Validation (obj, args)
{
}
</script>
Dans le cas d'une validation côté serveur :
Placez le code de validation dans l'événement OnServerValidate
1.5.6. ValidationSummary