d'orénavant vous pourrez utiliser des appels dans votre page type
<% AfficherHeure(); %>
- Vous voulez faire du code-behind : très simple. Vous tapez votre code dans votrepage et vous l'appelez dans le corps de la page comme fait ci-dessus.
Vous devez décrire une classe qui héritera de et qui appartiendra au namespace du nom de votre projet. Autre modification, votre page aspx n'héritera plus de mais de votre classe.
Un classe d'une page
Les objets courants ASP sont encore présents : Request, Response, Session, Vous trouverez aussi Application et Cache, mais leur utilisation sort du cadre de ce cours.
Vous devez avoir maintenant votre site. Il comprend des pages .aspx, du code dans des fichiers , d'autres ressources (images, son, ). Comment l'installer sur votre serveur IIS (ou un distant) ?
Si vous l'installez chez un fournisseur de service, ce dernier vous donnera sûrement la marche à suivre, qui devrait ressembler à celle pour votre IIS.
- Créez un répertoire du nom de votre projet dans le répertoire de base des pages pour IIS. Typiquement : c:\InetPub\wwwroot\. Dans notre exemple, nous créons c:\InetPub\wwwroot\AlanZero.
- Copiez tout vos fichiers dans ce répertoire et créez y un répertoire bin\.
- Il va falloir maintenant faire le boulot que faisait dans notre dos : compiler. Sauf si vous n'avez que du code inline (vous êtes têtu !), vous devez donner un moyen à IIS d'utiliser vos pages. En effet, s'il comprend à merveille l' (si installé), il n'entend rien par contre au C# ou autre .
- Sachez que le filtre ISAPI (ce qui permet à IIS de comprendre ) va aller chercher tout code exécutable dans le sous répertoire bin\ et espère le trouver dans une DLL du nom . Rien ne vous empêche d'avoir d'autres assemblies installées dans ce répertoire, et que vos pages les utilisent. Par contre leurs codes à elles DOIVENT être dans cette DLL. Comment faire ?
Tapez ceci:
csc /t:library
- csc : c'est le compilateur C# (vous ne l'avez pas oublié tout de même !)
- : nous allons produire un fichier de sortie où il faut et bien nommé.
- /t:library : nous indiquons que nous souhaitons produire une DLL (Dynamic Link Library)
- : la liste des fichiers à compiler.
- Faites dans IIS de votre répertoire contenant vos pages une "application". Clic droit sur le répertoire -> Paramètres d'application -> Créer.
- Un petit tour pour voir si tout va bien : http://localhost/
NB : Tout ce que je vais raconter ici est égalementfaisableetvraisans utiliser Visual Studio .NET. Toutefois, l'intérêt présenté ici est que le développeurn'a plus à connaître le HTML! Ce qui n'est pas possible en faisant tout le code "à la main".
Quel est l'avantage d'utiliser plutôt qu'un autre éditeur ? Pourquoi ne pas tout faire à la main ?
Je n'ai pas envie de discuter sur les bienfaits des IDE (Integrated Developpement Environnement). Chacun fait comme il veut :P !
Par contre c'est avec que l' montre son réel pouvoir : permettre de faire des applications internet SANS CONNAITRE HTML NI ASP !!!!
On est en droit de se demander comment est-ce possible ? En effet, une application sur Internet passe par le HTML. Elle a beau le contourner, le "javascripter" ou "vbscripter", le DHTMLiser ou l'ASPiser, cela repose toujours sur des structures issues du HTML. Comment donc faire une application sans ? Où sont passées ces heures de tortures à essayer de faire fonctionner une page ASP ? A se torturer avec des chevrons barbares ? Et ne me dites pas qu'avec des outils clé en main, on fait plus simple, ce n'est pas forcément vrai. Et programmer quelque chose qui va plus loin que d'afficher l'heure ou de dire "hello world" devenait un casse tête.
Quand vous programmez une application avec GUI (IHM dans la langue de Voltaire) vous ne vous souciez pas de communiquer avec GDI et de sombres appels systèmes interminables. Vous "dessinez" (je vous le souhaite car à la main c'est ignoble) vos composants sur votre frame : boutons, labels, zone de texte,
Hop un double clic et on se branche sur tel ou tel évènement de tel contrôle. On manipule des propriétés et des méthodes simples et sympathiques : Name, Font, Text, OnClick(..), OnTextChanged(..),
Le plus important est que vous vous moquez (dans 95% des cas) de comment est géré l'affichage et tout ce qui touche à l'interface graphique ! Ce n'est pas votre problème. Et bien elle est là l'idée des WebForms
| Et cette idée, c'est de mettre le développeur devant une page blanche, avec ses boutons à dessiner, qui ont des propriétés simples, des noms avenants et les méthodes ad'hoc. Gérer les évènements ? Un aller retour client serveur hélas, mais c'est le prix des applications server-side.
Votre page est sur le serveur et on en envoie une version (statique) HTML au client à chaque demande. C'est une "sérialisation HTML" comme j'aime à dire.
J'en profite pour dire que celle-ci est optimisée pour le client. C'est à dire que si ce dernier supporte DHTML, la page produite en contiendra pour "délester" le serveur de quelques tâches. (le tout 100%Compliant) |
Fini la théorie ici. Prenons un cas concret (je sais, j'aime bien). Nous allons faire une page d'une application qui prendrait des RDV pour une personne à une certaine date (pour changer). Je ne ferai pas le code qui gère des fichiers, rdv, etc ce n'est pas le but.
Simple. Ce coup-ci, demandez à Visual Studio .NET de faire un nouveau " Web Application" que vous nommerez selon votre goût. Après quelques secondes de boulot, vous devriez vous trouver devant quelque chose ressemblant à ceci :
Une nouvelle application web
Je rappelle au passage qu'il faut que vous ayez IIS 5+ installé sur votre machine, et que les extensions soient bien enregistrées. Si ce n'est pas le cas pour X raison : soit vous désinstallez IIS + .NET et vous réinstallez, soit vous lancez
C:\WINDOWS\\Framework\la-version-du-framework\
Vous êtes maintenant face à une page qui ressemble à s'y méprendre (pour ceux qui connaissent) à celles de tout bon IDE. Vous allez faire une application web (le nom n'est pas usurpé). Voici la palette d'outils qui est à votre disposition. Vous remarquerez qu'elle est très proche de celle de l'environnement Windows.
La palette des contrôles serveurs
Ces contrôles sont nommés contrôles serveurs car, comme expliqué plus haut, ces derniers fonctionnent du côté serveur. N'est envoyé chez le client que la représentation HTML des objets affichés (avec un peu de JavaScript/VBScript si besoin).
Les contrôles "Zone de Texte" et autres "Boutons" que vous voyez ne sont pas les contrôles HTML courant. Ce sont des contrôles serveurs ! La preuve, vous les manipulez comme des contrôles windows. Regardez à droite la fenêtre des propriétés/évènements. Même la page en elle même est un objet . Vous manipulez ses propriétés comme vous le feriez avec ses contrôles.
| Les propriétés de la page principale | Les propriétés d'un bouton |
Vous pouvez bien entendu inclure dans votre page des contrôles HTML standard, mais à ce moment là, vous ne pourrez utiliser les avantages de . Réservez les à des fonctions décoratives, ou à des tâches où ils sont suffisants.
Vous reconnaîtrez les contrôles serveurs des contrôles HTML standard, car les contrôles serveurs ont tous un petit en haut à gauche.
Voici comme dit plus haut une page ASPX faite avec . J'y ai ajouté une zone de texte pour prendre un nom de personne, ainsi qu'un calendrier pour une date. Oui, un calendrier. Pas fait main, mais fait ASPX ! Entièrement customisable sur l'apparence, il rempli son rôle à merveille. Outre cela, un bouton de remise à zéro, un de validation, une bannière de pub, une zone de feed-back utilisateur et des jolies couleurs.
Une page de prise de rendez-vous
mais pas la voir tourner pour l'instant pas encore uploadé :(
Magique est peut-être un peu fort, mais qui facilitent la vie, c'est clair.
Par exemple les Validators. Ils fonctionnent du côté client, et permettent d'interdire l'envoi de la page tant qu'un certain critère n'est pas rempli. Bénéfice immédiat : vous réduisez la charge réseau de votre serveur ! La basse besogne de vérification est effectuée côté client par du javascript (généré automatiquement).
Dans mon exemple, j'ai ajouté un RequiredFieldValidator qui fait apparaître un certain message si l'utilisateur essaye d'envoyer le formulaire sans que ce champ contienne une valeur.
En mode design, on voit le RequiredFieldValidator
Pour lui indiquer quel contrôle serveur surveiller, il suffit de changer la propriété idoine.
Choix du contrôle à surveiller
Autre exemple : le calendrier Calendar. Impossible de faire plus simple ou plus utilisable. C'est simplement LA solution dès qu'on veut que l'utilisateur saisisse une date. ET évidemment on le customise à notre guise
Comment marche mon bouton "RAZ" ? En effet, ce n'est pas comme je l'ai dit un bouton HTML "classique" qui efface le contenu des contrôles d'un formulaire. Et bien comme promis, c'est du C#
On sélectionne l'événement "Click" du bouton, et on saisie du code :
Le code du bouton RAZ
NB :Avec Visual Studio .NET vous pouvez à tout instant voir le code HTML de votre page en cliquant sur le bouton idoine . Il est très déconseillé d'essayer de trifouiller soi-même le code HTML dans , car vos modifs pourraient passer à la trappe bien vite.
Voici à quoi ressemble une partie du code HTML de la Web Form. Vous remarquerez la présence de chevrons nouveaux, de la forme
<asp:le-type-du-contrôle id="le-nom-du-contrôle" style="les-infos-du-contrôle " runat="server" >
Quelques lignes d' d'un fichier .aspx
Vos contrôles sont dans un formulaire (chevrons
). Normal, ils doivent causer des post-backs (un "retour-d'information" au serveur), et c'est la seule solution. Eh oui, car c'est côté serveur où se trouve le code disant quoi faire. (comme en HTML, ne mettez pas plus d'un formulaire par page, l' est "tatillon" là-dessus)
Ayez toujours en tête qu'un aller retour client-serveur est coûteux, et que moins vous en faites, mieux tout le monde se porte (surtout le serveur !). Ainsi, évitez de définir un callback pour l'évènement "TextChanged" d'une zone de texte Votre page ferait un aller retour à chaque nouvelle lettre ! Imaginez le trafic !
Lors de l'envoi au client, votre page est transformée en son équivalent HTML (le seul langage à peu près universel du Web). Ainsi, votre client ne recevra JAMAIS de chevrons genre "
Côté SERVEUR
Les mêmes lignes côté CLIENT
a "sérialisé la page en HTML" et l'a envoyée au client. Vous retrouvez les mêmes objets, sous leur forme HTML. On peut se poser des questions : mais cette transformation ne peut être complète ? Où passe le reste des données "non HTML" ?
Ce qui n'est pas HTML va dans un champ invisible, dont vous ne connaissiez pas l'existence et que vous n'aurez pas à utiliser (directement en tout cas). C'est qui le génère pour sauvegarder (de manière cryptée) les données ne pouvant être codées de manière HTML. Ce contrôle est __VIEWSTATE.
Le contrôle __VIEWSTATE visible seulement côté client
C'est à partir de la page HTML et de __VIEWSTATE que le serveur "désérialize" ces données en un objet .NET (votre page).
Un aller-retour d'une page ASPX
NB : vous pouvez dèsactiver le fait qu'un contrôle sauvegarde son état dans le champ __VIEWSTATE en mettant sa propriété EnableViewState à false. C'est très utile pour les contrôles gourmands genre DataGrid, etc Inutiles de sauvegarder leur état chez le client et d'alourdir ainsi ET la page ET le volume à envoyer/retourner.
Casse tête, grand plaisir de notre métier : la chasse aux bugs. Avec l'ASP, je dois avouer que c'est MON PIRE SOUVENIR. Je n'ai jamais autant perdu de temps dans ma vie qu'en débuggant des pages ASP.
Mais m'a réconcilié (pas avec les bugs, mais avec leur chasse). Déjà, on tape du code d'un côté et on fait une interface de l'autre. On peut compiler le code de la page sans même avoir IIS : on élimine ainsi toutes les fautes de codage (mais pas celles d'exécution).
Ensuite, j'ai rarement vu des pages d'erreurs aussi bien faites et belles que celles générées par quand on essaye de voir une page que l'exécution à fait aller dans les choux (ça marche aussi avec "fraise"). Et ça continue …
vous permet d'obtenir pour chacune de vos pages une résumé très détaillé des sessions, cookies, en-têtes, variables serveurs et ceci très simplement.
Une page d'information générée par
Pour cela, il vous suffit d'affecter la propriété trace à true dans l'en-tête de votre page ASPX.
<%@ Page Language="C#" Inherits="" trace="true" %>
Vous pouvez mixer vos propres messages avec ceux générés automatiquement par . Ainsi, remplacez vos traces genre "Response.Write ("Variable A =" + A.ToString())" par des "Trace.Write(" ")" (ou encore des Trace.Warn() qui sont pareil MAIS en rouge donc plus visibles).
Vos traces dans le rapport d'
Et même, vous pouvez inclure une trace au niveau de votre application (et non simplement d'une page). Editez pour cela votre fichier web.config de votre application, et définissez dans le noeud configuration -> le noeud suivant :
enabled="true"
localOnly="true"
/>
Il sera ici question de base de données. Si vous n'êtes pas intéressé, sautez à la section suivante.
Je ne traiterai pas ici de l'utilisation des bases de données "comme en ASP mais avec " vu que c'est pareil !!!! Je ne parlerai ici que de la nouveauté : ADO.NET.
Je supposerai ici que mon lecteur a les notions de base concernant les bases de données, leur fonctionnement et qu'il ne panique pas devant une ligne de SQL
| Notez que tout ce qui est dit ici est aussi entièrement valable pour une application autre qu'une WebForm : n'est pas exclusif à , mais fait partie du système .NET. |
Les bases de données sont des outils indispensables de l'informaticien. Apprendre à les maîtriser est indispensable, quel que soit votre "arme" : génie logiciel, webmestre, réseau,
Le monde étant hétérogène (fort heureusement), les bases de données n'échappent pas à la règle. Résultat pour tenter d'harmoniser tout ça, Microsoft à développé différentes technologies, descendantes les unes des autres. La dernière en date était ADO (ActiveX Data Objects).
Son évolution est . Elle fonctionne comme ADO mais rajoute encore une couche d'abstraction. Ceci fait, certain codes qui pouvait être différent suivant les bases de données manipulées se trouvent être identiques (facilité d'implémentation, maintenance, ). est aussi plus adapté aux applications web gourmandes en trafic et ainsi bien souvent en connexions BD. Il comble même certaines lacunes d'ADO (nous n'en parlerons pas ici).
| Mais la différence principale tient en le fait qu' fonctionne en mode "asynchrone" ou "déconnecté". Vous possédez sur le serveur WEB une partie de la base de données que vous souhaitez modifier, vous effectuez votre tâche (tri, ajout, suppression, ), puis soumettez le résultat au serveur BD. Le transfert de donnée s'effectuant au format XML (au coeur de .NET) SAUF en local où on utilise la méthode normale (et plus efficace). |
Deux namespaces vont être utiles : .OleDb et .SQLClient . propose avec OleDb de pouvoir utiliser tout type de base de données mais en passant par plusieurs wrappeurs intermédiaires. Par contre SQLClient permet de "court-circuiter" et de parler de manière plus directe au driver, mais ceci seulement pour SQLServer. Une nouvelle fois, revoici le choix entre universalité et performance
Avec Acces, j'ai créé une petite base de données n'ayant qu'une table. La base est "" et la table se nomme Numeros. Elle associe à un chiffre sa représentation textuelle française et anglaise (que jusqu'à 7, je suis flemmard). Voici son schéma relationnel :
Numeros (Numero, Fr, En)
La base est stockée dans le sous répertoire db/ de mon application. Une nouvelle page est présente : qui (ô surprise) accède à notre BD.
Dans la page il n'y a rien d'autre qu'une zone de texte et un DataGrid. Je n'ai pas indiqué le nombre de colonnes, lignes, types . etc au DataGrid. Je n'ai rien fait d'autre que le créer et choisir ses couleurs d'affichage. (j'insiste car c'est important plus tard)
| Le design de la page dans | La page vue sous IE 6 |
Et bien pas tant de code que cela. Notez toutefois qu'utilisant une base Access, j'utilise des OleDb et non des SQLClient
Voici le code complet générant l'affichage.
| OleDbConnection maConnexion = null;
try
{
maConnexion = new OleDbConnection (
@".OLEDB.4.0;Data Source=""C:\Inetpub\wwwroot\AlanVSNET\bd\""");
();
OleDbDataAdapter monAdapter = new OleDbDataAdapter ("SELECT * FROM Numeros", maConnexion);
DataSet monDataSet = new DataSet ("monDataSet");
(monDataSet);
dg.DataSource = monDataSet;
dg.DataBind();
}
finally
{
if (maConnexion != null)
maConnexion.Close();
}
|
Découpons le en partie logique.
Pour accéder à la base de données, on a besoin d'une connexion. C'est le rôle des lignes suivantes (peu importantes ici, car idem qu'en ASP).
maConnexion = new OleDbConnection (" ");
();
maConnexion = newSqlConnection(" ");
();
La section et dans .NET Documentation.
OleDbDataAdapter monAdapterOleDb = new OleDbDataAdapter ("SELECT * FROM Numeros", maConnexion);
SqlDataAdaptermonAdapterSqlSrv = newSqlDataAdapter("SELECT * FROM Numeros", maConnexion);
C'est un ensemble de requêtes SQL qui vous servira à peupler un(des) DataSet(s).
C'est lui qui prends en charge la copie, gestion, exécution des requêtes, etc. Je ne rentrerai pas dans les détails, mais il regroupe les tables que vous lui fournissez à la création, et peut stocker vos différentes opérations dans un DataSet.
La section et dans .NET Documentation.
DataSet monDataSet = new DataSet ("monDataSet");
C'est le "coeur" d'. Ce n'est plus à la base de données que vous accédez mais à cet objet qui est une copie locale d'une partie de la base réelle. C'est en quelque sorte une base locale à votre application et qui vous permet de travailler en mode déconnecté.
Ainsi, une fois votre DataSet peuplé avec votre requête (ou ensemble de requêtes) vous pouvez vous déconnecter de la base de donnée ! Vous utilisez le DataSet comme vous l'auriez fait avec la base, mais sans trafic ! C'est de l'accès direct car la partie de la base que vous utilisez est en mémoire centrale.
Et pour répercuter les modifications sur la base, appelez la méthode Update(DataSet) de votre connexion (une fois reconnecté, évidement !).
Un DataSet est une image locale d'une partie de la base distante
Vous pouvez évidemment utiliser un curseur sur un DataSet (comme en mode connecté), mais aussi grâce aux méthodes DataBind() et DataSource() des différents contrôles .NET, avoir le travail mâché pour vous ! (comme dans l'exemple) Une partie des composants supportant ce traitement sont :
- DataGrid
- DataList
- ListBox
- DropDownList
- CheckBoxList
- RadioButtonList
Cela ne s'arrête pas là. Votre DataSet est nativement exportable en XML. Il peut vous donner à la demande les schémas relationnels de son contenu (au format XSD) et les données contenues (au format XML). Ainsi, c'est 100% de compatibilité avec tout autre système supportant XML et base de données. C'est pour cela que les DataSet sont universels quel que soit vote BD (il n'existe pas de OleDbDataSet, SqlDataSet, )
Exporter une structure d'un DataSet et/ou ses données est EXTREMEMENT simple. Voici les deux lignes s'acquittant de cette tâche
Pour écrire une structure de DataSet
Pour écrire les données du DataSet
Le résultat obtenu est deux fichiers XML complètement universels ! Partageable avec toute application de tout OS. (hé non, pas de tentative hégémoniste de Microsoft ici, n'en déplaise à certains)
| La structure en XML | Les données sous forme XML |
La section DataSet dans .
Pour afficher les données après la requête, prenez un des contrôles supportant DataSource/DataBind. Affectez lui comme source votre DataSet, et faites votre DataBind.
Notez qu'en , si vous avez plusieurs contrôles qui utilisent des DataSet, faites un DataBind de la page (Page.DataBind();) plutôt qu'un DataBind par contrôle : le contrôle Page répercutera le message à ses contrôles enfant.
Pour faire profiter le monde de vos pages , sois vous ouvrez votre propre site Web, sois vous vous faites hoster. Evidement, je vais vous parler de la seconde option ici (la première se limitant à installer IIS, et trouver un fournisseur de nom de domaine).
Beaucoup de ces sites proposent evidemement les deux formules (gratuit/payant), la première étant généralement une restriction de la seconde. Toutefois regardez bien ce qui vous est offert : accès base de données, espace disque offert, composants installés sur le serveur, extensions Front Page (pour faciliter les màj), accès FTP ou Web (sachant que les interfaces Web sont souvent TRÈS agaçantes),
- $$$
- $$$
- $$$ ou gratuit 15 jours :(
- $$$
- $$$
- $$$
Un host gratuit de est . Il propose 30 Mo d'espace et accès à Access (dire 10x rapidement). Pour l'instant on ne peut faire de code behind et on doit taper son code inline. C'est pas très cool, mais ça devrait bientôt changer
Personnellement, m'a réconcillié avec les applications web. Ayant contribué à en développer une dans un récent emploi, j'en avais gardé une idée de complexité, de code pas propre et de difficulté à gérer et maintenir. De plus je devais m'arracher les cheveux avec des considérations HTMLesques, qui ne faisaient que me compliquer ma tâche de développeur.
Mais c'est fini : on programme dans des langages propres, Objet, de notre choix (C#, , ), débuguable aisément. Le code que l'on produit est compilé donc plus rapide et .NET dépasse 1000x les possibilités de VB.
quand à lui apportera son lot de satisfactions aux développeurs travaillant avec plusieurs bases (d'une manière ou d'une autre). Et la possibilité de travailler en mode déconnecté soulagera tout les serveurs (et les admin, chasseurs de bande passante).
Merci à Laurent ELLERBACH pour sa sympathie, ses idées, et les opportunités qu'il m'a offert et continue à m'offrir. Et aussi pour sa relecture !!!
Merci aussi à Céline pour sa très gentille relecture, d'autant plus pénible qu'elle ne comprends pas ce que je dis ;)
- Formation à (poche, pas cher, très bien) ISBN : 2-84082-865-0 chez MSPress (et sur le web )
- Designing Microsoft Applications (cher) ISBN : 0-7356-1348-6 chez MSPress
- Applied Framework Programming (cher, très complet, mais ne parle pas d' ni d') ISBN : 0-7356-1422-9 chez MSPress
