1.1.1. Des événements particuliers
En tant que programmeur, nous sommes pratiquement tous habitués à entendre parler d'événements, nous venons encore de nous en servir dans notre première petite application. Nous connaissons ceux liés à une action comme "click", répondant à une action sur la souris. ASP.NET possède le même genre d'événements mais, certains sont assez particuliers et très importants pour le déroulement et le contrôle de ce genre d'application.
1.1.1.1. Application
| Evénement | Description |
| Application_Start | Exécuté lors du premier appel à une page du site depuis le démarrage de IIS |
| Application_End | Appelé lorsque l'application se termine, cela ne signifie pas que IIS s'arrête mais est d'office appelé si, pour une raison quelconque IIS est arrêté |
1.1.1.2. Session
| Evénement | Description |
| Session_Start | appelé lors de chaque nouvelle session d'un navigateur client |
| Session_End | fin de session : lors d'un timeout ou lors d'une destruction explicite (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. 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érénité des données véhiculées dans le site lui-même.
Un petit schéma pour mieux visualiser la différence entre "Application" et "Session" :
Soit trois utilisateurs U1, U2 et U3 qui envoient une requête vers le serveur IIS. Il y aura un seul objet "Application" commun à tous les utilisaterus du site mais trois objets "Session" correspondant chacun à un utilisateur précis.
Si U2 quitte son poste de travail sans couper son navigateur :
· s'il n'y a pas de timeout, les autres utilisateurs peuvent accéder à S2
· S'il y a timeout et que U2 revient visiter le site, une nouvelle session S4 sera créée
Par contre, si U2 coupe son navigateur, S2, persiste jusqu'à un éventuel timeout ou jusqu'à la fin de l'application
1.1.1.3. PostBack
Cet événement génère un appel au serveur. Dans ASP.NET 2.0, la page se rappelle continuellement en déclenchant cet événement. C'est au programmeur de créer les conditions de passage d'une page à l'autre.
Surtout, ne pas s'affoler, ces notions seront reprises maintes fois dans le développement du tutoriel mais sont nécessaires niveau vocabulaire pour évoluer dans la manipulation du code proprement dit.
1.1.2. Les Server Controls
Un petit mot sur les types de contrôles présents dans ASP.NET. Il existe deux jeux de contrôles s'exécutant côté serveur :
Les Web Controls, gérés par des événements, ils ressemblent plus aux objets utilisés dans du développement winforms c'est-à-dire qu'ils possèdent des propriétés ("font", "backcolor", ...) facilitant la mise en forme. Ils dépendent de "System.Web.UI.WebControls".
Les HTML Controls qui correspondent directement aux balises HTML. Les attributs des balises correspondantes sont accessibles via les propriétés de ces contrôles. Pour faire une analogie avec les "WebControls", ceux-ci ne possèdent qu'une balise "Style" pour la mise en forme, cela est plutôt limitatif.
Ces derniers dépendent eux de "System.Web.UI.HtmlControls".
1.1.3. ViewState
Comme dit lors du premier exemple de page aspx, le ViewState, nouveau concept introduit par Microsoft avec ASP.NET, représente l'état de l'ensemble des contrôles d'un page. Les informations sont sauvées sous forme d'un flux sérialisé dans la page HTML et le champ caché _VIEWSTATE permet le transit de ces informations entre le client et le serveur.
Il peut être désactivé au niveau d'un contrôle, au niveau d'une page ou au niveau d'une application en plaçant la propriété EnabledViewState à False.
Le plus intéressant est que le programmeur peut y ajouter ses propres informations sous forme d'objets indexés par une clé de type String.
Pour sauvegarder et lire une information, voici comment utiliser le ViewState, par exemple pour modifier un argument dans une requête de sélection :
|
1.1.4. Cookies
Les cookies permettent aux applications Web de stocker des informations spécifiques à l'utilisateur. Par exemple, lorsqu'un utilisateur visite votre site, les cookies peuvent vous servir à stocker ses préférences, ou d'autres informations. Lorsque cet u tilisateur revient visiter votre site Web, l'application peut récupérer les informations stockées précédemment.
§ Exemple de Création de cookie
Dim cookie As HttpCookie
Dim UserID As String
User = "neo"
cookie = New HttpCookie("User")
cookie.Values.Add("User", User)
Response.Cookies.Add(cookie)
§ Exemple de Lecture de cookie
Dim cookie As HttpCookie
cookie = Request.Cookies("User")
Dim User As String
User= cookie.Value()
§ Détecter si le navigateur supporte les cookies
Dim CoookiesSupported As Boolean = Request.Browser.Cookies
§ Supprimer un cookie
Vous ne pouvez pas supprimer directement un cookie sur l'ordinateur d'un utilisateur. Mais vous pouvez donner au navigateur de l'utilisateur l'ordre de supprimer le cookie en réglant la date d'expiration de ce cookie sur une date révolue. La prochaine fois que l'utilisateur soumettra une demande à une page dans le domaine ou le chemin d'accès où se trouve le cookie, le navigateur jugera que le cookie a expiré et le supprimera.
myCookie.Expires = DateTime.Now.AddDays(-1D)
1.1.5. Variable de session
"Session" est un objet qui s'utilise un peu comme le ViewState,
c'est-à-dire avec une clé mais se comporte plutôt comme une table de hachage. Prenons deux pages aspx :
page1.aspx : page dans laquelle nous encodons, par l'intermédiaire d'une TextBox, un nom de société
page2.aspx : page dans laquelle nous affichons le nom de la société (vous comprenez que le but est d'avoir une page d'affichage de données de société se trouvant par exemple dans une base de données)
Protected Sub cmdAfficheSoc (Byval sender As Object, ByVal e As System.EventArgs) Handles cmdAfficheSoc.ClickSession("NomSoc") = txtNomSoc.Text
Response.Redirect("page2.aspx") End SubCode de la page1.aspx : L'utilisateur introduit un nom de société dans la TextBox nommée "txtNomSoc". Cette information est sauvée en Session avant de passer à la page2.aspx
Protected Sub Page_Load (Byval sender As Object, ByVal e As System.EventArgs) Handles Me.Load If Session("NomSoc") IsNot Nothing ThenlblNomSoc.Text = CType(Session("NomSoc"), String)
Else Response.Write("Aucune société n'a été choisie !") End IfEnd SubCode de la page2.aspx : Un test est effectué pour savoir si la variable de session contient bien une donnée. Celle-ci est affichée en passant par un transtypage.
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) :
· Initialisation de l'objet Session : événements Session_Start et Session_End déclenchés par le serveur et accessibles via le fichier Global.asax
· Expiration de la session
· Session avec ou sans cookies
· Session sécurisée
1.1.6. Variable d'application
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.
Protected Sub Page_Load (Byval sender As Object, ByVal e As System.EventArgs) Handles Me.LoadDim cpt As Integer = 0
Application.Lock() If Application("Compteur") IsNot Nothing Thencpt = CType(Application("Compteur"), Integer)
End If cpt = cpt + 1 Application("Compteur") = cpt Application.UnLock() lblVisite.Text = "Page vue : " & cpt & " fois."End SubL'objet Application étant commun à tous les utilisateurs du site, il est préférable de bloquer l'accès lors de l'écriture et, bien entendu, de ne pas oublier l'action inverse.
0 التعليقات:
Post a Comment