www.infkoffler.com - Site de cours d'informatique

Accueil

Java Standard Edition

Java EE 5

Visual Basic .Net 2005

Cours Javascript - DOM - DHTML

Nouveautés sur le site

Contacts

Accueil > Cours ASP .Net 2.0

____________________________________________________________________________________________________

Connexion

SOMMAIRE

I) GENERALITES

I.1) Un EDI formidable

I.2) Différentes manière d'inclure C# ou Visual Basic

I.3) L'objet Response

I.4) Les évènements

COURS ASP .NET 2.0

I) GENERALITES

Ce cours n'est pas complet. Je préciserai des points utiles à connaître de l'ASP .Net 2.0 .
L'environnement ASP .Net 2.0 est composé de deux parties. Une partie qui est un langage de programmation évolué, comme le C# ou Visual Basic .Net . La deuxième partie est le langage ASP .Net proprement dit. C'est-à-dire tous les contrôles serveurs ASP .Net. Je parlerai aussi, de manière ponctuelle, de tout l'environnement ASP .Net, vu de manière globale.

ASP .Net 2.0 est difficile d'accès si on essaye de l'aborder directement, sans même connaître Visual Basic .net ou C#, ni la programmation des bases de données dans ces langages, et sans connaître XHTML et CSS( voire Javascript).
Par conséquent, je vous conseille de ne pas vous lancer directement dans le développement sous ASP .net, car cela peut sembler décourageant, si on tente de se lancer directement. Il est préférable d'abord de maîtriser Visual Basic ou C#, ainsi que XHTML et CSS.

I.1) Un EDI formidable

L'EDI ( Environnement de Développement Intégré) de Visual Studio 2005 est formidable, notamment grâce à Intellisense( qui est une aide à la frappe). Cet EDI est également hors du commun, car il permet de saisir, et toujours avec Intellisense, tous les langages possibles en programmation ASP .net 2.0:
*Visual Basic 2005 .net
* C#
* Le langage ASP .net 2.0 proprement dit
* XHTML
* CSS( les feuilles de style)
* Javascript( eh oui!)
* L'ASP classique( ASP 3.0), donc le VB script

On dispose donc d'un formidable EDI pour chacun de ces langages, y compris l'aide Intellisense, ce qui est très appréciable!

Un autre intérêt de l'IDE est d'avoir une vue Design, qui permet de visualiser instantanément le résultat à l'écran, et aussi de créer sa page à partir de ce design, quand on le souhaite. Ce n'est donc pas uniquement un simple éditeur de texte.

I.2) Différentes manière d'inclure C# ou Visual Basic

Il existe 3 possibilités d'intégrer le code source C# ou Visual Basic.

I.2.1) Séparer le code ASP .net et le code C# dans deux fichiers distincts

La façon la plus simple et la plus claire pour intégrer le code C#( ou Visual Basic .net) est de le placer dans un fichier distinct( d'extension .cs ou .vb). Ceci présente l'avantage que la lisibilité du programme est meilleure, car on n'a pas à rechercher dans son code ASP .net et XHTML, les parties qu'on a écrites en C#. Cette manière de faire est donc la plus conseillée. Cependant, elle ne suffit pas toujours.

I.2.2) Intégrer le code C# avec le code ASP, avec la balise <script>

Une deuxième façon de faire est de mélanger le code C# au code ASP .net, dans le fichier .aspx, en mettant le code C# dans des balises < script runat="server" > et </script> . Ceci ne présente pas beaucoup de différences avec la méthode de séparer les fichiers, et ne présente, à mon sens, pas beaucoup d'intérêt, car on perd beaucoup de lisibilité. En effet, il est difficile après de retrouver les parties en C# dans tout le code, quand il est mélangé avec le code ASP .net( et donc XHTML).
Cette méthode est strictement équivalente, en terme d'effet produit, à la méthode de séparer en 2 fichiers.
Une restriction gênante est qu'on ne peut pas mettre de code c# directement, sans qu'il ne soit inclus dans une fonction, ce qui peut ne pas répondre à tous les besoins. On peut faire d'ailleurs également ce reproche à la méthode de séparer le code.

I.2.3) Intégrer vraiment le code C# au code ASP .net

Une dernière possibilité est enfin possible, celle d'intégrer "réellement" le code C# au code ASP .net . C'est-à-dire de pouvoir écrire du code XHTML à l'intérieur même de vos lignes C#. Ceci est possible grâce à la balise <% %> .
Cette façon de procéder est la même que celle utilisée en ASP classique, et permet de faire ce qu'on réalise également en PHP. Dans certains cas, elle est irremplaçable, comme par exemple l'affichage de données d'une base de données, en les mettant en forme dans un tableau XHTML.
On n'est plus obligé de mettre le code C# dans une fonction, on peut commencer à l'écrire directement. Ceci est fondamental, car notre code n'est pas toujours fait pour faire partie d'une fonction liée( à un évènement). Ainsi, votre C# sera exécuté dans l'ordre d'affichage du XHTML et ASP .net de votre page, comme s'il en faisait partie. Ceci est une démarche naturelle et intuitive, qui est d'ailleurs celle du PHP et de l'ASP 3.0.
Le seul inconvénient est qu'on ne pourra plus utiliser de contrôles serveurs ASP .net, tels que les labels par exemple, dans notre fichier .aspx. Et on ne pourra pas non plus exécuter ces contrôles serveurs ASP .net en les mettant dans une fonction qu'on appellerait du fichier .aspx. Cependant, les fonctions liées qui exécutent des contrôles ASP .net sont toujours opérationnelles.
On ne perd rien avec cette méthode, car on garde les possibilités des autres méthodes( c'est-à-dire exécuter de l'ASP .net depuis les fonctions liées), et on a, en plus, d'autres possibilités.

- A l'intérieur même d'une balise XHTML:
Il reste cependant un cas où il faut s'y prendre avec une syntaxe précise, pour intégrer du C# au XHTML: c'est le cas où on veut inclure du C# à l'intérieur même d'une balise XHTML. Par exemple, si on veut, dans une balise <a href= > XHTML, définir le lien href avec une variable C#. Dans ce cas, il faut procéder de la manière suivante:

<% int b=1; %>
<a href="Dest.aspx"> <%=b %> </a>

On remarque facilement que le code C# à l'intérieur de la balise <a> a une syntaxe particulière et inhabituelle. C'est une syntaxe qui est faite juste pour signifier qu'on veut que le compilateur insère le contenu de la variable b, d'où ce "=" écrit directement( on comprend intuitivement cette écriture). De plus, il ne faut pas ajouter de ";" à la fin de la ligne. Là aussi, on peut comprendre, car il ne s'agit pas d'une réelle ligne C#: on demande simplement une insertion dans une balise XHTML.

On peut s'en sortir aussi en utilisant Reponse.Write(), dont je parle ci-dessous. Il suffit alors de concaténer notre code XHTML qu'on passe à l'objet Response, à notre variable C# convertie en string.

*Remarque: on peut insérer la balise <% = %> à l'intérieur d'une chaîne de caractère XHTML, par exemple:

I.2.4) En utilisant la méthode Response.Write()

Il existe une quatrième possibilité de mélanger du XHTML à du C#.
Ceci est réalisable en utilisant la méthode Response.Write( ). On passe à la méthode une string, qui peut contenir du XHTML. Tout est donc possible, notamment d'inclure des variables C# à l'intérieur même d'une balise XHTML. Le résultat du Response.Write est exactement identique à si on avait écrit le code html dans un fichier html.
Bien sûr, l'inconvénient est que le code XHTML n'est plus coloré par l'IDE, et aussi qu'on n'a plus accès à Intellisense. Cette façon de procéder est donc à éviter.

I.3) L'objet Response

L'objet Response de la page courante, représente la réponse donnée au navigateur de l'internaute, par le serveur Web. Cela peut être du XHTML, dans ce cas, il est aisé de comprendre: c'est juste du code XHTML envoyé à l'internaute. Cela peut être aussi des instructions qu'on donne au navigateur de l'internaute, par exemple demander au navigateur de l'internaute de demander lui-même une autre page( dont Response précise l'url, bien sûr).

I.3.1) La méthode Response.Redirect()

   Cette fonction permet de rediriger vers une autre page, c'est à dire d'afficher une autre page. Ceci peut répondre à un besoin, dans certaines situations.
   Prenons l'exemple Response.Redirect( "~/destination.aspx" ) : dans ce cas, la réponse renvoyée à l'internaute est une demande de redirection vers la page destination.aspx. Le navigateur n'a donc plus qu'à exécuter cette demande, et à afficher cette page destination.aspx( c'est à dire, faire une demande au serveur web, comme d'habitude dans ce cas classique). Conclusion: le serveur web ne va pas chercher directement la page destination.aspx, lorsqu'on utilise Response.Redirect( ). Il va se produire un aller-retour vers l'internaute( serveur->navigateur, puis navigateur->serveur). Mais cet aller-retour est invisible aux yeux de l'internaute, et ne pose par conséquent aucun inconvénient.

- Contrainte du Response.Redirect( ):

   Il y a une contrainte à la méthode Response.Redirect( ): on ne peut pas écrire de code html avant de l'appeler, pour une raison que je préciserai. Je veux dire que dans les lignes qui précèdent la ligne du Response.Redirect( ), il ne doit pas y avoir de html. On ne peut donc pas faire de Response.Write( ) avant, car faire Response.Write équivaut à écrire en html. On peut utiliser le Response.Redirect( ) dans un fichier C# ou VB .net, bien sûr. Dans ce cas, le fait de ne pas mettre de html avant est moins gênant, car il y a du html surtout dans le fichier .aspx. On est donc moins gêné qu'en PHP, où existe le même problème pour la redirection, mais où n'existe pas la séparation en deux fichiers .cs et .aspx(par exemple).

I.4) Les évènements

I.4.1) Résoudre le problème que peut engendrer le postback des pages

Que se passe t'il lorsqu'un évènement tel que l'évènement click est déclenché?
Bien sûr, la procédure liée est appelée. Mais on peut remarquer que la page est réaffichée par post( d'ailleurs on voit que la page se réaffiche à l'écran). Ensuite la procédure liée au click est appelée. Par conséquent, la procédure load est appelée, avant la procédure liée. Cet appel du load en général n'est pas gênant et passe inaperçu. Cependant, le cas où par exemple on initialise le contenu d'une textbox dans le load, afin que la personne puisse modifier un contenu existant, peut être problématique. Car, à supposer que le click valide la saisie, la page sera réaffichée automatiquement par post. Par conséquent, le load sera exécuté à nouveau. Et donc, comme le load initialisait la textbox, cela pose problème, car la textbox sera de nouveau initialisée avec le contenu initial. Ce qui implique que la valeur entrée par l'internaute sera effacée, et remplacée par le contenu initial. Comment résoudre le problème? Il suffit d'utiliser la propriété this.IsPostBack ( this est la page courante). Cette propriété permet de savoir si c'est la première fois ou non, que la page est affichée, ou si c'est un réaffichage par postback. Voici un exemple de source démontrant mes propos:

protected void Page_Load(object sender, EventArgs e)
{
   (...)
   if (this.IsPostBack = = false)
{
txtMaSaisie.Text = chaine_depart;
   }
   (...)
}

RETOUR HAUT