Présentation générale de la POW
publicité
Présentation générale de la POW Séquence 1 Ü Contenu 1. Les différents types de sites Web 2. Les outils techniques Introduction La POW (Programmation Orientée Web) est l’ensemble de toutes les techniques et outils spécifiques à la création de sites Web, c’est-à-dire à la création d’applications accessibles via le Web. Ces techniques et outils relèvent, pour la plupart, des compétences des informaticiens. Au vu de l’importance croissante de l’Internet et du Web (prononcer « ouèbe »), vous comprendrez pourquoi nous estimons nécessaire de vous initier à certaines de ces technologies. La création de sites Web nécessite l’utilisation de langages de programmation dits de présentation, comme le si connu HTML, dont les mots clés servent à décrire la structure des pages Web. Cependant, pour créer des sites plus élaborés, on utilise aussi d’autres langages de programmation. Dans ce dernier cas, pour décrire les pages d’un site, on utilise de concert le langage HTML (ou un langage de la même famille) et un ou plusieurs autres langages de programmation. La conséquence de cette association de différents langages de développement de sites Web est que les architectures logicielles des sites sont souvent compliquées à comprendre, mais aussi à créer. C’est pourquoi ce support de cours se contente de poursuivre l’objectif modeste de vous initier aux techniques et outils les plus utilisés dans la programmation orientée Web. Qu’est-ce qu’un site Web ? Du point de vue technique, et pour faire simple, un site Web est généralement un répertoire contenant un ensemble de « pages Web » reliées entre elles par des liens. Le terme « reliées » signifie ici que les pages d’un même site sont accessibles les unes par rapport aux autres. Un site Web est stocké sur un serveur, spécialisé dans l’hébergement de sites, quelque part dans le monde. Dans d’autres cas, le site est sur le serveur d’un réseau local non ouvert sur Internet (on appelle ça un intranet). Qu’il soit ouvert sur le monde, ou au contraire confiné dans un réseau local, tout site est accessible via un navigateur Web ou browser, comme Netscape, Internet Explorer, Mozilla... 8 3950 TG PA 00 Séquence 1 Présentation générale de la POW À quoi sert le navigateur ? Un navigateur est un logiciel utilisé par l’utilisateur lorsqu’il souhaite accéder à des pages Web. Un utilisateur qui accède à des pages Web (familièrement, on dit « qui surfe », prononcer « kisseurf ») est appelé un internaute. Le rôle du navigateur est de charger, sur le poste de l’internaute, les fichiers (et éventuellement des dossiers) contenant la description de la page demandée par l’internaute et de traduire (on dit « d’interpréter ») cette description pour afficher la page dans la fenêtre du navigateur. La description d’une page Web est un fichier contenant les informations qui décrivent la page et éventuellement des instructions réglant certains de ses comportements (un exemple simple : un fichier qui s’appellerait « maPage.html » contiendrait la description de la page « maPage » et cette description serait écrite en langage HTML). En bref, un navigateur est un interpréteur de code source (ce code source est essentiellement composé de HTML). De même qu’un éditeur de texte interprète du code ASCII pour afficher du texte, le navigateur interprète le code source des pages pour les afficher. Ce qui transite sur le net, c’est le code source décrivant les pages, pas les pages. Les pages ne peuvent être visualisées que si on les ouvre depuis un navigateur, ou éventuellement depuis un autre logiciel sachant afficher des pages Web à partir de leur description (exemple : Microsoft Word est capable de visualiser des pages Web décrites en langage HTML). Le navigateur permet donc d’accéder aux pages disponibles sur le Web (en français, on dit « sur la TAM », TAM signifiant « Toile d’Araignée Mondiale »), ou bien il permet d’accéder aux pages Web d’un Intranet (une structure qui ressemble à l’Internet, mais qui n’est pas « ouverte » à des accès extérieurs). L’internaute accède à des pages Web en indiquant au navigateur leur adresse Internet ou URL, ce sigle anglais signifiant Uniform Resource Locator (avec l’accent, prononcer « Younifôme Ouisauce Locaiteu ») ou encore adresse réticulaire, en français. C’est moins beau et ça sonne moins bien à l’oreille en français, je vous l’accorde. Exemple d’URL : http://www.leserveurWeb.fr/lapage.html Que sait faire un navigateur ? Tous les navigateurs savent afficher des pages dont les descriptions sont écrites en langage HTML (Hyper Text Markup Language), DHTML (Dynamic HTML) ou XML (Extended Markup Language). Ces trois langages sont des « Markup Language », en français des « langages à balises ». Les navigateurs savent en fait demander différentes ressources comme, par exemple, le code source de la page Web dont l’internaute a indiqué l’URL, et éventuellement les dossiers accompagnant le code source de cette page, ces dossiers contenant, par exemple, les images qui s’afficheront dans la page. Les navigateurs savent également exécuter des programmes, envoyés avec le code source de la page. Ces programmes servent à enrichir la description des pages ou à régler certains comportements de la page (on abordera cet aspect de la POW ci-dessous dans la partie intitulée « Outils et techniques »). 8 3950 TG PA 00 10 Séquence 1 Présentation générale de la POW Le chargement du code source de la page et de ses programmes une fois effectué, ces programmes s’exécuteront sur la machine de l’internaute. On appelle ces programmes des scripts clients (car il s’exécutent sur la machine cliente, celle de l’internaute). Comment ça se passe ? – Ben, ça se passe bien. – Non, mais la question est juste un peu vague, je trouve, pas vous ? – Comment ça se passe, QUOI ? – Alors je précise ma question : comment que ça se passe pour que le navigateur eh ben, il affiche les pages ouèbes ? – Là, ça va, j’ai compris, alors j’explique. L’internaute tape une URL dans la barre d’adresse du navigateur, ou bien il clique sur une URL écrite dans un document. L’URL que l’internaute a tapée contient : l’adresse du serveur + l’emplacement de la page souhaitée sur ce serveur. Le navigateur demande donc cette page au serveur. Si la page est accessible à cet internaute, le serveur renvoie sa description à la machine de l’internaute. Le navigateur interprète cette description et exécute les éventuels programmes qui accompagnaient la description de la fenêtre, et la page s’affiche. Un point c’est tout ! Quel protocole transporte les pages ? Un protocole, c’est une collection de règles qui régissent un échange. Le protocole utilisé pour transporter les pages Web le long des voies de l’Internet (au sein d’un Intranet) est le protocole HTTP (Hyper Text Transfer Protocol). Ce protocole a ici pour rôle de régir la communication entre le client HTTP (le navigateur de l’internaute) et un logiciel s’exécutant sur le serveur hébergeant la page, ce logiciel étant appelé le serveur http, car son rôle est de distribuer les pages Web demandées par les internautes. Le protocole HTTP a pour rôle d’établir la connexion avec le serveur qui héberge la page que l’internaute veut voir s’afficher, et de rapatrier le code source de cette page sur le poste de l’internaute. Quand l’internaute clique sur un lien hypertexte ou qu’il le saisit dans la barre d’adresse de son navigateur, le navigateur envoie une requête http au serveur Internet. Cette requête demande au serveur d’envoyer la page spécifiée. Exemple : si on saisit l’URL http://www.leserveurWeb.fr/lapage.html ou que l’on clique dessus, le navigateur s’adresse au serveur http http://www.leserveurWeb.fr et lui demande la page lapage. html. 8 3950 TG PA 00 11 Séquence 1 Présentation générale de la POW Vocabulaire Que le site soit très simple ou élaboré, le poste de l’internaute est appelé le poste client et la machine hébergeant le site Web est appelé le serveur. Les sites Web ont-ils tous les mêmes fonctionnalités ? Non. Ils ont des fonctionnalités plus ou moins élaborées. Bien entendu, plus c’est élaboré, plus c’est compliqué à développer. Il existe différentes catégories de sites Web, chaque catégorie correspondant à un certain degré d’élaboration. Nous allons ci-dessous faire une petite visite guidée dans la galerie des différentes catégories de sites Web. 1. Les différents types de sites Web Grosso modo, il existe trois grandes familles de sites Web : les sites statiques, les sites dynamiques et les applications Web. 1A. Les sites statiques Ce sont des sites de présentation. Ils présentent des informations. Ces sites sont dits statiques car leurs pages sont des pages statiques. Une page est dite statique quand le contenu qu’elle affiche est fixé une fois pour toute, au moment de la création de son code source (c’est-à-dire au moment de sa description à l’aide d’un langage à balises comme HTML, par exemple). Dans ce cas, pour modifier le contenu affiché par la page et/ou son comportement, il faut modifier le code source de description de la page. Les pages des sites statiques sont hébergées telles quelles sur les serveurs : dans le cas d’une page statique, ce que le serveur héberge, c’est le code source de la page (ceci n’est pas le cas pour les autres types de sites vus plus bas). Ces pages statiques sont chargées, traduites et visualisées par le navigateur. Le serveur http qui s’exécute sur le serveur hébergeant le site a pour seul travail d’envoyer la description des pages Web dont les internautes demandent la visualisation en indiquant leurs URL. Les pages de ce type de site peuvent être : • sans animation (aucun mouvement sur la page). Ces pages sont essentiellement composées de texte, photos, tableaux... mais rien n’y bouge ; • animées (des petits gugus qui rigolent, des extraits de dessins animés, de la musique, un calendrier qui s’affiche, etc.). Ces animations sont provoquées notamment à l’aide du langage DHTML (le D signifie Dynamic), mais également par l’exécution des programmes envoyés en même temps que le code source de la page, programmes que le navigateur est capable d’exécuter sur la machine de l’internaute. Pour développer un site statique, différentes techniques sont utilisables, ne nécessitant pas toutes forcément des compétences en programmation. 8 3950 TG PA 00 12 Séquence 1 Présentation générale de la POW 1B. Les sites dynamiques Un site dynamique est un site comportant des pages dynamiques. Une page est dite dynamique quand sa description (c’est-à-dire son code source) est produite au moment où l’internaute demande à la visualiser (en ayant indiqué son URL). Exemple de site dynamique : un site de consultation de la météo. Ben oui, la météo, ça change tout le temps, donc, un site statique (c’est-à-dire un site contenant des pages dont le contenu est fixe), ne convient pas. En effet, vous n’imaginez quand-même pas que tout au long de toutes les journées de l’année, il y a un pauvre informaticien, titulaire du BTS IG, qui modifie (avec ses pauvres petits doigts pleins de crampes à force de taper au clavier) la description des pages, et ce, à chaque changement de température ou à chaque fois qu’il se met à pleuvoir quelque part. Non, là, il s’agit d’un site dynamique : le code source des pages est construit au moment où l’internaute demande à les visualiser. C’est-à-dire que le code source d’une page (celui qui est envoyé à la machine de l’internaute) est généré par un logiciel installé sur le serveur hébergeant le site, au moment où l’internaute demande à visualiser cette page en ayant tapé son URL dans la barre de son navigateur. Ce logiciel, appelé intepréteur de scripts, a pour rôle de construire le code source d’une page en exécutant le fichier de script correspondant à cette page. Les instructions contenues dans ce fichier de script permettent de générer le code source de la page. Exemples d’interpréteurs de fichiers de script : un serveur Apache (interprète les fichiers de scripts écrits à l’aide du langage PhP), un serveur IIS (interprète les fichiers de scripts écrits à l’aide du langage ASP). Attention, ici, le terme serveur est à prendre au sens logiciel, comme pour le serveur HTTP. Il ne s’agit pas d’une machine. Dans ce contexte là, les logiciels serveurs sont des logiciels exécutant des services à la demande d’autres logiciels. Un fichier de script est une suite d’instructions dans un certain langage de programmation : c’est un programme, mais qui n’est pas compilé (c’est-à-dire que ce n’est pas un fichier exécutable). Interpréter un fichier de script, c’est comme exécuter un programme sauf que dans le cas des fichiers de script, les lignes d’instructions sont interprétées puis exécutées les unes après les autres, ce qui n’est pas le cas des programmes compilés (les programmes écrits par exemple avec Windev sont compilés, ce sont donc des exécutables). Le fichier de script correspondant à une page contient à la fois des informations sur la description HTML (ou DHTML, ou XML) de la page, et des instructions écrites dans un langage de script pour serveur, ces instructions concernant généralement l’acquisition des informations variables que la page affiche. Bon, le HTML (ou DHTML, ou XML) et les instructions écrites en langage de script pour serveur ne sont quand même pas rangées n’importe comment dans le fichier de script, mais, pour une page, elles sont généralement mélangées à l’intérieur du même fichier de script. 8 3950 TG PA 00 13 Séquence 1 Présentation générale de la POW Pour construire le code source d’une page dynamique, l’interpréteur de script « exécute » le fichier de script permettant de générer le code source de la page. Lors de cette interprétation, l’interpréteur de fichier de script combine la description HTML (ou DHTML, ou XML) de la page avec des données. L’interpréteur de fichier de script extrait généralement les données, qui représentent la partie variable de la page, dans une base de données, à l’aide des instructions écrites en langage de script et de requêtes SQL. Dans ce cas, ce qui est hébergé sur le serveur, ce n’est pas le code source de la page, c’est le code source du programme destiné à créer la page, c’est-à-dire le fichier de script correspondant à la page. Un exemple simple : si maPage est une page dynamique, le fichier de script permettant de générer maPage s’appellera maPage.PhP si le langage de script utilisé est le langage PhP, ou bien maPage.asp, si le langage de script utilisé est le langage ASP. Au cours de l’interprétation du fichier de script, le code source de la page (c’est-à-dire sa description dans un langage à balises) est généré. Une fois que la description de la page a été générée, cette description est transmise au serveur http, qui, comme pour les pages statiques, envoie ce code source au navigateur, qui lui-même traduit et affiche la page. Pour mettre en œuvre cette architecture, il faut des compétences en programmation. En effet, les programmes qui permettent de produire dynamiquement les pages Web demandées par l’internaute, accèdent à la base de données et construisent le code source de la page le font à l’aide d’instructions écrites dans divers langages de programmation (comme le très connu PhP). En bref, les interpréteurs de scripts pour serveurs sont des programmes sachant produire dynamiquement du code HTML à partir de fichiers de script. Ils savent exécuter (ou plutôt, interpréter) les instructions contenues dans le fichier de script d’une page pour produire le contenu de cette page en rajoutant certaines informations variables à afficher dans la page produite (ces informations sont généralement extraites d’une base de données, mais pas toujours), ils savent aussi interpréter les balises (écrites dans un langage à balise comme HTML) contenues dans le fichier de script pour mettre en forme ces informations dans la page. Donc, dans ce cas, pour modifier le contenu affiché par une page, on ne modifie pas sa description, ni le programme destiné à générer son code source, mais on modifie le contenu de la base de données utilisée. Pour développer des sites dynamiques, il existe plusieurs solutions techniques (on peut, pour un site, utiliser en même temps ces différentes solutions), nécessitant toutes des compétences en programmation. C’est là que vous comprenez pourquoi il vaut mieux avoir bien avancé dans le cours de teck... euh, de base de données, et dans le cours d’algo/programmation, pour pouvoir développer des sites dynamiques (on le fera dans le fascicule 2 de POW, que vous recevrez dans votre « petit paquet » de cours de deuxième année). 8 3950 TG PA 00 14 Séquence 1 Présentation générale de la POW Les sites dynamiques, bien que plus élaborés que les sites statiques, restent malgré tout des sites de présentation, même si ce qu’ils présentent est variable dans le temps. Cela signifie qu’un site dynamique ne sait pas, pour construire une page, prendre en compte les interventions de l’internaute, comme la saisie d’une information, un choix spécifique, etc. Les sites sachant prendre en compte les interventions de l’internaute sont appelés des applications Web. Nous allons voir ci-dessous quelles sont leurs caractéristiques. 1C. Les applications Web 1C1. Présentation Les applications Web sont des sites dynamiques qui savent, en plus des sites dynamiques de présentation, prendre en compte certaines informations saisies dans des formulaires par l’internaute (recherche, commande de produits...). Une application Web offre donc à l’internaute des services autres que ceux d’un site de présentation, qu’il soit statique ou dynamique : recherches, formulaires de saisie, achat en ligne... Le contenu des pages d’une application Web dépend en partie des interventions de l’internaute. Exemple : lorsqu’un internaute fait une recherche dans un moteur de recherche, il (ou elle) commence par se connecter sur la page d’accueil du moteur de recherche. Ensuite, l’internaute tape les mots relatifs à sa recherche, dans une zone de saisie réservée à cet effet, puis valide sa recherche. À ce moment, les informations que l’internaute a tapées sont envoyées, le couple « serveur HTTP + interpréteur de scripts » récupère ces informations, effectue la recherche demandée, récupère les résultats de la recherche. Ensuite, en interprétant un script, il « mélange », comme pour un site dynamique, les résultats de la recherche et la description de la page qui doit contenir les résultats. Cela donne la description d’une page Web contenant ces résultats. Le serveur http renvoie cette description au poste de l’internaute. Le navigateur de l’internaute n’a plus qu’à traduire cette description pour visualiser la page. Vous voyez bien que la description de la page reçue dépend bien des informations que l’utilisateur a tapées au préalable. C’est pourquoi la description de ce type de pages doit être construite dynamiquement. Comme les sites dynamiques, les applications Web puisent les informations dans des bases de données, mais la différence, c’est que, pour un site dynamique, il n’y a pas prise en compte de saisies de l’internaute, alors que pour une application Web, si. La saisie éventuelle d’informations par l’internaute ne modifie pas le code de description des pages dynamiques, mais seulement éventuellement la base de données utilisée pour construire les pages dynamiques. 8 3950 TG PA 00 15 Séquence 1 Présentation générale de la POW Donc, une application Web, c’est comme un site dynamique, sauf qu’en plus, ça sait prendre en compte les interventions de l’internaute. Pour développer une application Web, il faut aussi des compétences en programmation, et différentes techniques sont à notre disposition. 1C2. Les différents modèles d’architecture d’applications Web Quelle que soit la technologie utilisée, selon l’architecture logicielle déployée, c’est-à-dire selon la façon dont les traitements ont été répartis entre le client Web (le navigateur du poste de l’internaute) et le serveur (la machine qui héberge le site), on utilise un certain vocabulaire pour qualifier la partie cliente (c’est-à-dire la partie se situant sur le poste de l’internaute) et le modèle d’architecture logicielle utilisé. • Premier modèle d’architecture : on dit du client qu’il est un client léger si c’est le serveur qui exécute tous les traitements significatifs (on dit « toute la logique métier ») relativement à l’application Web. Des petits traitements (de contrôle de cohérence, de saisie, d’affichage d’un calendrier ou d’un gadget amusant...) peuvent être exécutés par le poste de l’internaute, mais ces traitements ne concernent pas le thème de l’application. Exemple : si l’application Web est une application permettant de commander des articles sur un site de commerce en ligne, les petits traitements exécutés par le client léger ne concernent en rien la constitution de la commande passée par l’internaute. Ce modèle est à utiliser lorsqu’on ne sait rien de la configuration du poste de l’internaute. • Second modèle d’architecture : le client est dit client lourd lorsque le poste de l’internaute exécute des traitements assez significatifs (dans ce cas, une partie de « la logique métier » est exécutée par le poste client). Exemple : le calendrier qui s’affiche dans la page ne propose que les jours où le magasin est ouvert, le calcul du total de la commande saisie par l’internaute est effectué par le poste client… Ce modèle d’architecture est à utiliser lorsque la configuration des postes client est connue (par exemple, on sait que le navigateur de l’internaute est configuré pour permettre aux applets java, des petits programmes spécifiques, de s’exécuter). • Troisième modèle d’architecture : on parle de livraison Web lorsqu’il y a une réelle répartition des traitements entre le poste client et le serveur. les objets utilisés pour développer la partie cliente communiquent avec les objets utilisés pour développer la partie serveur, en utilisant éventuellement d’autres protocoles que HTTP (Hyper Text Transfert Protocole), le protocole de transport des pages Web (exemple d’autres protocoles : le protocole SOAP, un protocole standard destiné aux services Web, lancé par IBM et Microsoft, et qui permet d’utiliser des applications invoquées à distance via Internet). Cette solution d’architecture est adaptée aux intranets ou à la mise en œuvre de services Web (en anglais, on dit « Web services », prononcer « ouèbe seuvissise »). C’est quoi un service Web ? En gros, c’est un logiciel (ou plutôt une partie de logiciel) qu’un autre logiciel peut appeler à distance via Internet (un peu comme une procédure ou une fonction qui serait hébergée sur un site au Canada et qu’un programme appelle depuis une machine située dans la Vosge profonde). Nous n’aborderons pas, dans ce support, ce troisième modèle d’architecture qui nécessite une infrastructure matérielle et logicielle, ainsi que des compétences, à mon goût trop complexes. 8 3950 TG PA 00 16 Séquence 1 Présentation générale de la POW En outre, ce 3e modèle d’architecture peut être utilisé pour concevoir des applications qui ne sont pas des sites Web : on peut très bien concevoir une application de gestion des payes tournant sur un poste dans une entreprise de Trifouillis-les-Oies, application qui appelle en invoquant le protocole SOAP (le protocole utilisé pour appeler les Web services) des fonctions de calcul hébergées sur un serveur au Nebraska, sans que cette application de gestion soit un site Web. Ceci sort donc du cadre de ce support. Ce qui différencie ici les différents modèles d’architecture, ce ne sont pas les technologies utilisées, mais la répartition des traitements significatifs (« la logique métier ») entre les postes clients et le serveur. Nous allons aborder maintenant l’aspect technique de la POW. C’est-à-dire que nous allons recenser les différents outils et techniques existants sur le marché et permettant de concevoir les différentes catégories de sites Web vus ci-dessus. 2. Les outils techniques Il existe tout un tas d’outils techniques (langages, environnements de développement, etc.) permettant de créer des sites ou des applications Web. Chacun de ces outils et techniques permet plus ou moins de créer soit des sites (statiques ou dynamiques), soit des applications Web. Je vous présente quelques-uns de ces outils et techniques. Je m’efforcerai de vous préciser ce que chaque outil technique permet ou ne permet pas de faire. 2A. Les langages de description de pages Web et leurs acolytes Ce sont les langages à balises dont j’ai déjà parlé plus haut. Je citerai à nouveau les 4 principaux langages à balises : HTML, DHTML, XML et XHTML. Utilisés seuls (c’est-à-dire sans autre langage), ils permettent de développer des sites statiques. Les pages Web, pour pouvoir être visualisées par un navigateur, doivent être décrites dans un de ces langages, même si elles sont générées automatiquement par un interpréteur de scripts pour serveur. Les pages décrites dans tous ces langages sont transportées à l’aide du protocole HTTP. 2A1. HTML, le langage de base de description de pages Web HTML signifie Hyper Text Markup Language. Il s’agit d’un langage qui décrit sous forme de balises la manière dont les informations doivent être visualisées dans le navigateur. La description d’une page Web qui utilise le langage HTML est stockée dans un fichier d’extension .htm ou .html. Pour décrire des pages Web à l’aide du langage HTML, on peut : • Soit utiliser un logiciel comme Frontpage, Webexpert, dreamWeaver ou autre, permettant de construire les pages Web sans même connaître le langage HTML. Ces logiciels sont des éditeurs de pages Web capables de produire du code HTML à partir de la conception graphique des pages. On n’a pas besoin de connaître la programmation pour faire ça. Ça, on ne va pas le faire, car vous n’avez pas besoin de moi. Rien ne vous empêche de vous y mettre seul en utilisant les sujets de TP proposés pour ce support. 8 3950 TG PA 00 17 Séquence 1 Présentation générale de la POW Dans ce support, je ne veux pas consacrer ni trop de pages, ni trop de temps, à vous apprendre à utiliser différents environnements de développement orientés Web. Nous nous contenterons donc d’utiliser un simple éditeur de texte (comme notepad par exemple), dans lequel nous taperons le code source. Mais rien ne vous empêche de faire l’acquisition d’un logiciel de conception de sites Web (gratuit ou payant). Dans ce cas je vous conseille l’éditeur hapedit, il est simple et gratuit). • Soit taper la description en HTML depuis un éditeur de texte, enregistrer le texte tapé dans un fichier d’extension .html. Ce fichier sera visualisé par notre navigateur sous forme d’une page Web. C’est ce que l’on va faire, lon la, lon lère. 2A2. Le DHTML, pour mettre un peu de vie dans nos pages DHTML signifie Dynamic HTML. Ce langage est du HTML enrichi. Les éléments supplémentaires présents dans ce langage permettent d’enrichir la description des pages d’un site statique, histoire de l’animer un peu, le site. En fait, et pour vous dire la vérité, DHTML n’est pas un langage en soi, mais la conjugaison de 3 langages complémentaires : • le HTML, dont je viens de vous parler et auquel vous vous initierez à la séquence 2 ; • le javascript, un langage de script client, qui fait l’objet d’une bonne grosse initiation dans la séquence 3 de ce fascicule ; • CSS, un langage permettant de définir des styles applicables aux pages, que l’on verra dans le support servi en 2e année. 2A3. XML, le père de tous les langages de description de pages Web Même si je vous en présente un nombre restreint, il existe tout un tas de langages du même type qu’HTML, c’est-à-dire utilisant des balises pour décrire la structure et le contenu des pages Web (exemple : MathML, SGML, etc.). Parmi eux, XML, un des plus récents, est un langage permettant de créer des langages comme HTML. C’est pour ça que je dis que c’est le père de tous les langages à balises, mais c’est idiot ce que je dis, puisque XML est un des plus récents parmi ces langages, mais quand même, on peut dire que conceptuellement, c’est leur père, à tous les langages à balises. Contrairement à HTML, XML permet de créer de nouvelles balises. Alors qu’HTML précise comment les éléments d’une page sont présentés, XML définit ce que contiendront les pages. Mais XML, c’est bien plus qu’un simple langage de description de pages Web. Depuis 1997, XML est devenu la norme en matière de format de documents échangés via le net. Résultat : XML est au centre d’un fourmillement de nouvelles techniques, de nouveaux outils et de nouveaux langages. Il existe des bases de données qui savent stocker des documents au format XML, il existe des langages de programmation permettant d’accéder au contenu de documents XML (exemple : Xquery, un peu l’équivalent du SQL, mais pour les documents XML), il existe des outils de création de style pour les documents XML, etc. On fera un peu de XML dans le support servi en 2e année. 8 3950 TG PA 00 18 Séquence 1 Présentation générale de la POW 2A4. Donner du style à nos pages avec CSS Je viens de vous le dire en vous présentant sommairement DHTML, le langage CSS permet de créer un style de page Web, et d’utiliser ce style dans toutes les pages que l’on veut. L’avantage de ce type de langage ? On crée un style, et on l’applique à toutes nos pages, ce qui nous évite de refaire le travail pour chaque page. 2B. Utilisation de programmes s’exécutant sur le poste client Lorsqu’on développe un site statique, on peut vouloir enrichir, animer son comportement. Il se peut que HTML ne suffise pas toujours, auquel cas, le développeur du site utilise des langages de programmation pour écrire des petits morceaux de programmes qui seront exécutés par le navigateur. D’autre part, lorsque l’on développe un site dynamique ou une application Web, on peut vouloir donner une partie du travail à faire au poste de l’internaute. Par exemple, si on propose à l’internaute une page contenant des zones où il doit saisir des informations, et que parmi ces zones, certaines doivent être obligatoirement renseignées, on a deux solutions, une futée, l’autre moins. • La soluce pas très futée futée : contrôler si l’internaute a bien renseigné les zones obligatoires au moment où le formulaire rempli arrive sur le serveur. Pourquoi c’est pas futé ? Parce que tout d’abord, on donne au serveur un travail supplémentaire à faire, travail qui pourrait tout à fait être effectué par le navigateur du poste client. Ensuite, parce que si jamais l’internaute n’a pas renseigné certaines zones obligatoires, il faut que le formulaire lui soit renvoyé pour être complété, puis à nouveau renvoyé, puis recontrôlé... ce qui rallonge considérablement le temps de traitement. • La soluce futée : contrôler directement depuis le navigateur de l’internaute si toutes les données obligatoires ont bien été saisies, à l’aide de programmes s’exécutant sur le poste client. Dans ces deux cas (enrichissement de site statique et délégation d’une partie du travail d’un site dynamique ou d’une application Web), on doit écrire des programmes qui s’exécuteront sur le poste de l’internaute. D’où viennent ces traitements ? Il existe plusieurs solutions dont certaines sont décrites ci-dessous. Encore une fois, la liste ci-dessous n’est pas complète. Je me suis efforcée de présenter les solutions les plus connues. 8 3950 TG PA 00 19 Séquence 1 Présentation générale de la POW 2B1. Utilisation de scripts clients Dans le cas de l’utilisation de scripts clients, les traitements sont intégrés à la description de la page envoyée. Il s’agit, dans ce cas, de scripts (écrits dans un langage de script), intégrés au code source de la page, et qui sont exécutés par le navigateur de l’internaute. Le développeur (c’est-à-dire vous !) écrit, par exemple en javascript ou VBscript, des morceaux de programmes appelés scripts, intégrés dans le code HTML décrivant la page, et traduits par le navigateur avant visualisation. Donc, pour créer ce type de site, on utilise du langage HTML et un langage de script client. Nous, on va faire du javascript, car tous les navigateurs savent décoder ce langage de script. Par contre, nous ne verrons pas VBScript, car seul Internet Explorer sait le traduire. 2B2. Utilisation d’applets Le code exécutable de ces traitements n’est pas intégré au code source de la page envoyée. Il est envoyé au poste de l’internaute par le serveur HTTP, en même temps que la description HTML de la page. Ces programmes sont écrits généralement en langage java, mais aussi maintenant en langage C#, le langage de programmation de la plateforme .Net (pour faire « classe », prononcer « DotNet »). On les appelle des applets, pour APPlication Light WEighT (en français, il faut dire Appliquette... Non !! C’est pas une blague, c’est bien comme ça qu’il faut dire en français !!). Ce sont des petits programmes compilés. Ils servent à améliorer les fonctionnalités de la page chargée. Ils sont chargés en même temps que la page, sont stockés temporairement sur la machine de l’internaute et ont une durée d’existence limitée. Ils sont automatiquement supprimés à la fin de l’échange entre le poste client et le serveur (on dit « à la fin de la session »), et sont supprimés de la mémoire de la machine à la fermeture de la page. L’exécution de ces traitements par le navigateur de l’internaute nécessite que le navigateur soit configuré de manière à savoir exécuter les applets. Nous n’écrirons pas d’applets dans ce support. 2B3. La troisième solution : les plug-in Ces programmes ont été automatiquement téléchargés sur le poste de l’internaute lorsque celui-ci en a eu besoin pour la première fois, et se sont installés définitivement sur la machine de l’internaute. Il permettent généralement de manipuler (visualiser, écouter…) certains éléments de la page téléchargée. La prochaine fois que l’internaute aura besoin du plug-in, il ne sera pas téléchargé à nouveau, sauf si la version dont dispose le serveur est plus récente que celle dont dispose l’internaute. Exemple : shockWave de Macromédia. Ce support de cours ne vous apprendra pas à écrire des plug-in. 8 3950 TG PA 00 20 Séquence 1 Présentation générale de la POW 2B4. Utilisation de cookies Ce terme de cookie, outre le fait de désigner de délicieux gâteaux, très faciles à faire (voir recette de ma copine Véro ci-dessous), désigne, en info(rmatique), un petit fichier qui contient des informations particulières. Ce petit fichier est un « témoin de connexion ». La taille d’un cookie ne peut pas dépasser 4 Ko. Il est envoyé sur la machine de l’internaute, souvent à son insu (on peut aussi dire « à l’insu de son plein gré » je crois), par le site qu’il consulte. Tout internaute peut paramétrer son navigateur pour accepter ou non les cookies. Si le navigateur de l’internaute est paramétré pour les accepter, les cookies sont stockés sur le disque dur de l’internaute et non sur le serveur hébergeant le site consulté. Ce petit fichier contient des informations sur la nature de la « relation » que l’internaute entretient avec le site consulté. Le rôle des cookies est de faciliter la navigation sur la TAM (Toile d’Araignée Mondiale). Exemples d’utilisation de cookies • Pour identifier l’internaute plus rapidement, ce qui lui fait gagner du temps, à l’internaute. Le cookie contient des informations qui doivent normalement être saisies par l’internaute lors de sa connexion au site. La présence du cookie sur le poste de l’internaute lui évite de ressaisir ces informations. Il les a saisies la première fois qu’il a consulté le site, un cookie a été créé, et maintenant, quand il consulte à nouveau ce site, les informations contenues dans le cookie sont utilisées, il n’a donc plus à les saisir. • Pour personnaliser la relation entre l’internaute et le site, c’est-à-dire mieux connaître l’internaute et lui proposer des produits personnalisés. Exemple : une librairie en ligne qui va cibler ce qu’elle propose à l’internaute en fonction des informations contenues dans le cookie (ce qui suppose que l’internaute s’est déjà connecté au moins une fois à cette librairie en ligne, et que lors de cette première visite, le site a « observé » ce que faisait l’internaute, constitué un cookie et envoyé ce cookie sur le poste de l’internaute). • Pour gérer son « caddy » sur un site marchand. • Pour éviter à l’internaute de saisir identifiant et mot de passe lors de chaque accès à un site. • Pour transmettre des informations saisies par l’internaute d’une page à une autre d’un même site, ce qui évite à l’internaute de ressaisir ces informations et permet de personnaliser les pages . Les cookies ne peuvent contenir que des informations saisies par l’internaute, ou des informations comme la configuration de sa machine par exemple. Ils ne permettent pas d’espionner le contenu de l’ordinateur de l’internaute. Certains sites ne peuvent fonctionner qu’en les utilisant. Les cookies ne sont pas tous détruits en fin de session, c’est pourquoi il faut songer à faire le ménage de temps en temps. 8 3950 TG PA 00 21 Séquence 1 Présentation générale de la POW Techniquement, comment ça marche ? Vous savez déjà que quand on « surfe » sur l’Internet, c’est le protocole http qui est utilisé. Quand on clique sur un lien hypertexte, notre navigateur (Internet Explorer, Netscape Navigator, etc.) envoie une requête http à un serveur Internet, lui demandant la page spécifiée. Le serveur HTTP retourne une réponse http contenant la page demandée. Les cookies transitent par le biais de ces échanges, en s’introduisant dans les entêtes des requêtes et des réponses http. Quand on consulte un site, le navigateur lance une requête http pour chaque page que l’on souhaite afficher. Chaque requête http est indépendante des autres. Le serveur Internet n’a donc pas la possibilité de savoir que c’est une seule et même personne qui demande l’affichage de ces différentes pages. Un exemple tout bête : imaginez un site commercial qui propose un catalogue et qui permet de passer des commandes en ligne. L’internaute (et dans ce cas, souvent, l’internautesse...) se balade sur les différentes pages du catalogue en ligne et sélectionne, souvent par un clic, les produits qu’il (elle) souhaite commander. Les produits sont rajoutés au panier. Puis l’internaute(sse) valide sa commande sur une page spéciale également destinée au règlement de sa commande. Si ce site n’utilisait pas, par exemple, les cookies, l’internaute(sse) devrait ressaisir sur cette page, les références des articles qu’il ou elle a sélectionnées dans les pages du catalogue. En effet, les pages étant, pour le serveur Internet, indépendantes les unes des autres, à chaque changement de page, les informations de la page précédente seraient perdues (exemple : les articles retenus par cet(te) internaute(sse) sur la page précédente). Dans le cas d’un site commercial, le cookie déposé sur le disque dur de l’internaute contient, entre autre, un identifiant, c’est-à-dire un code unique attribué à l’internaute. Quand l’internaute sélectionne, dans une page, un article qu’il souhaite commander, le serveur enregistre la référence de l’article ainsi que la quantité souhaitée et y associe l’identifiant qu’il va récupérer dans le cookie déposé sur le disque dur de l’internaute. Le serveur est donc en mesure de savoir à tout instant quels articles ont été commandés par l’internaute, même après que celui-ci ait quitté les pages des produits qu’il a commandés. Les cookies ne sont pas le seul moyen technique de conserver ces informations, mais ils sont un moyen simple de le faire. Pour améliorer l’ergonomie de la navigation, les sites utilisent donc les cookies. Où les cookies se cachent-ils ? Sur la machine de l’internaute, l’emplacement du dossier ou du fichier contenant ces témoins de connexion varie selon les versions de système d’exploitation et de navigateur présentes sur la machine de l’internaute. Exemple : si le navigateur de l’internaute est Internet Explorer, les cookies sont stockés dans un dossier cookies, situé à des endroits différents selon le système d’exploitation. Avec Netscape Navigator, les cookies sont dans un fichier cookies.txt. 8 3950 TG PA 00 22 Séquence 1 Présentation générale de la POW Quelles sont les informations contenues dans un cookie ? Un cookie est un fichier qui contient des informations de type texte (que l’on peut donc afficher dans tout éditeur de texte). Le cookie contient : • un nom. C’est le nom de la valeur qui est associée au cookie ; • une valeur. C’est la valeur de l’information associée au cookie. Remarque : seuls le nom et la valeur sont obligatoirement renseignés lors de la création d’un cookie. Les informations ci-dessous sont optionnelles, mais parfois bien utiles : • une date d’expiration. Cette information indique jusqu’à quelle date le cookie peut être utilisé. Au-delà de cette date, le cookie sera effacé. Si la date d’expiration n’est pas renseignée, il sera supprimé de la machine de l’internaute dès la fin de la session Internet, c’est-à-dire dès la fermeture du navigateur ; • un domaine. Cette information indique le domaine pour lequel le cookie est valable (exemple : http://www.mondomaine.fr). Si le domaine n’est pas renseigné, c’est celui du serveur hébergeant le document qui a créé le cookie qui sera retenu ; • un chemin. Cette information indique la partie de l’URL pour laquelle le cookie est valable (exemple : http://www.mondomaine.fr/monsite/). Si le chemin n’est pas renseigné, c’est celui du document qui a créé le cookie qui sera retenu ; • un attribut de sécurité. Cette information indique si le cookie peut ou non être transmis lors d’une connexion non sécurisée. Pour en savoir plus • Vous pouvez télécharger l’utilitaire FireFox, pour observer le contenu des cookies se trouvant sur votre machine. • Sur le site de la CNIL (Commission nationale de l’informatique et des libertés), vous pouvez consulter cette page spéciale « cookies » : http://www.cnil.fr/traces/comment/cooki.htm. • Sur le site de l’ATICA (l’Agence pour les technologies de l’information et de la communication dans l’administration), vous trouverez la description technique du fonctionnement des cookies : http://www.atica.pm.gouv.fr/dossiers/documents/cookies.shtml. • D’autres explications sur le site CommentÇaMarche : http://www.commentcamarche.net/securite/cookies.php3. • Et aussi sur : http://www.linternaute.com/surfer/cookie/cookiesomm.shtml. http://www.linternaute.com/surfer/cookie/cookiestrat.shtml. • Jean-Claude Bellamy propose sur son site un petit utilitaire (seulement pour Internet Explorer) qui rajoute dans le menu contextuel une commande « voir les cookies » qui affiche dans une page Internet le contenu de l’éventuel cookie : http://www.bellamyjc.net/doWnload/cookieinst.exe. • Un dernier lien : http://www.tactika.com/cookie/. 8 3950 TG PA 00 23 Séquence 1 Présentation générale de la POW Est-ce qu’on va faire des cookies ? Oui. On va en créer dès la séquence 3 de ce fascicule. Vous verrez, c’est très simple. On utilise des instructions javascript prévues pour créer et consulter des cookies, et hop, le tour est joué. Et puis on va en faire aussi, des qui sentent bon. On peut y mettre des raisins, des pépites de chocolat, des petits morceaux de fruits secs… bon, les raisins, notre navigateur n’aime pas trop, mais nous, si… 2B5. Recette des cookies C’est la recette de ma copine Véro. Vous verrez, ils sont délicieux, et très facile à faire. Mélanger : 350 grammes de farine, 250 grammes de sucre, 1 pincée de sel, 1⁄2 sachet de levure chimique. Ajouter : 1 œuf, 200 grammes de beurre fondu, 1 sachet de sucre vanillé, du lait si la pâte est trop épaisse Éventuellement : rajouter des pépites de chocolat, des noisettes, des amandes, du nougat coupé en petits morceaux etc. Remarque importante : ne pas mettre dans la pâte de morceaux de denrées non comestibles comme des vis, des composants électroniques, ou du fil électrique. Bien mélanger le tout. Prélever avec une cuillère à soupe la quantité de pâte pour un cookie, déposer cette pâte sur la plaque du four, lui donner une forme ronde et l’aplatir un peu (en clair : ne pas taper dessus comme un forcené, mais l’aplatir délicatement avec le dos de la cuiller). Recommencer jusqu’à ce que la plaque soit pleine (moi, je mets 12 cookies par plaque). Cuire à four chaud pendant 10 minutes (thermostat 7 ou 8 = 210 °). Recommencer jusqu’à ce que vous ayez utilisé toute la pâte, sauf si vous préférez jeter la pâte qui reste, mais ça, c’est vous qui voyez. 8 3950 TG PA 00 24 Séquence 1 Présentation générale de la POW 2C. Utilisation de programmes s’exécutant sur le serveur Cette technique permet de développer des applications Web, des sites dynamiques, mais également, si on est maso et qu’on adore faire compliqué quand on peut faire simple, des sites statiques. Encore une fois, il existe plusieurs solutions et je ne présente ci-dessous qu’une partie d’entre elles. 2C1. Utilisation de langages de script pour serveur Actuellement, les langages les plus utilisés sont les deux langages de script suivants : • PhP (Personal Home Page), langage créé en 1994 par Rasmus Lerdoft, c’est une solution faisant partie du monde des logiciels libres ; • ASP (Active Server Pages), langage de script développé par Microsoft, c’est une solution faisant partie du monde des logiciels commerciaux, mais il y a moyen de l’utiliser gratuitement. Comment ça fonctionne avec des langages de script pour serveurs ? On en a déjà parlé dans le paragraphe 1B. sur les sites dynamiques, mais ce n’est pas du luxe d’expliquer une seconde fois. L’internaute saisit l’URL de la page dynamique, hébergée sur un serveur. La description de la page, sur le serveur, contient des instructions écrites dans un langage de script pour serveur. Ces instructions se trouvent dans le code HTML de la page. Ces instructions ont pour rôle de construire dynamiquement la description de la page entièrement en langage HTML, c’est cette description en code HTML qui sera envoyée au navigateur de l’internaute. Le serveur Web (c’est-à-dire le serveur http) hébergeant la page détecte la demande de visualisation d’une page dynamique avec script. Il envoie la page à l’interpréteur de script correspondant à l’extension de la page. Exemple : le serveur enverra la page au logiciel apache (c’est l’interpréteur de scripts PhP) si la description de la page dynamique possède l’extension php. L’extension PhP signifie que la partie dynamique de cette page est décrite à l’aide d’instructions écrites en PhP. L’interpréteur interprète les instructions PhP, qui concernent généralement l’accès à une base de données qui contient les informations variables de la page dynamique, ou bien la prise en compte des saisies effectuées par l’internaute. Il traduit tout ça en HTML : il convertit en langage HTML le résultat d’exécution des instructions écrites en langage de script, en prenant en compte les informations éventuellement saisies par l’utilisateur et/ou puisées dans une base de données. L’interpréteur retransmet le code HTML de la page au serveur http, qui la transmet au navigateur de l’internaute. Le navigateur de l’internaute visualise la page HTML reçue. Et voilà, super fastoche ! 8 3950 TG PA 00 25 Séquence 1 Présentation générale de la POW 2C2. Utilisation de l’interface CGI L’interface CGI (Common GateWay Interface) est un logiciel spécialisé qui permet au navigateur (se trouvant sur le poste de l’utilisateur) de demander à un serveur distant de lancer un programme exécutable se trouvant sur le serveur lui-même. Le serveur exécute le programme demandé, traduit le résultat d’exécution du programme en une page HTML qu’il envoie au navigateur du poste client (le poste de l’utilisateur). On dit que le résultat d’exécution du programme est traduit « à la volée », et c’est pour cela que la page HTML qui en résulte est dite « dynamique ». L’URL saisie par l’utilisateur pointe en fait sur un programme exécutable (d’extension .exe) écrit dans un langage compilé (en général C, mais aussi Delphi, Windev ... ou tout autre langage permettant de créer des programmes exécutables). La différence avec les langages de scripts pour serveur est que les programmes hébergés par le serveur sont des exécutables, pas des scripts. L’autre différence est que cette interface est un standard. À part ces deux différences, on peut, avec l’interface CGI, faire tout ce qu’on fait avec les langages de script pour serveurs. Cette solution est la plus ancienne, elle souffre de lenteur. Ces lenteurs ne sont pas dues à l’âge, mais surviennent dans les cas de sollicitations très nombreuses car le programme exécuté mobilise à chaque fois des ressources importantes sur le serveur. 2D. Utiliser des plates-formes de développement Actuellement, les deux principales plates-formes permettant de développer pour le Web sont la plate-forme J2EE de l’éditeur Sun (utilisant le langage de programmation java), et la plus récente plate-forme .net (rappel : pour faire bien, ne pas dire « point net » mais « dot net »), de Microsoft dont le langage de programmation est le C# (second rappel : prononcer « C Sharp », avec l’accent, ça fait « si shôôp »). Il existe également une troisième plate-forme, très en vogue outre Atlantique : il s’agit de la plateforme zope, dont le langage de programmation est Python. Avec ces outils, on peut développer tout ce qu’on veut, du site statique à l’application Web, en passant par le site dynamique et l’application non Web (du genre : application de gestion qui tourne en local sur un poste). Par contre, je pense, encore une fois, qu’il faut être maso pour s’embêter à utiliser ces outils complexes pour développer un simple site de présentation, surtout s’il y a moyen d’utiliser un outil plus simple. Les langages de ces plates-formes (le langage java, le langage c#, le langage Python) permettent également de développer des applications non destinées au Web, comme si on utilisait un environnement de développement non spécialisé dans le développement des applications Web. 8 3950 TG PA 00 26 Séquence 1 Présentation générale de la POW Bref, on peut tout faire avec ces outils (enfin, quand je dis tout... ça ne fait pas la lessive ni le ménage hein !). C’est notamment parce qu’ils sont généralistes que ces outils s’appellent des FrameWorks (c’està-dire des plates-formes de développement), et également parce qu’ils font appel à la programmation objet et utilisent des bibliothèques d’objets (également appelées des bibliothèques de composants). Les applications sont en fait un assemblage de ces composants et le travail du développeur consiste à intégrer les composants dans une même application, en faisant en sorte, au moyen des instructions du langage, que les composants collaborent entre eux. Avec ces outils, on peut implémenter (c’est-à-dire appliquer ) le modèle MVC (Model View Controller), recommandé par le W3C pour la conception de sites dynamiques et d’applications Web. Le W3C, c’est le World Wide Web Consortium : un groupe de personnes très compétentes, chargé de pondre les normes pour le développement Web. Allez voir sur leur site (http ://www.w3c.com), si vous voulez : il y a toutes les normes concernant les langages qu’on va utiliser... et oh joie! C’est tout en anglais!). Appliquer le modèle MVC consiste à développer toute application Web en plusieurs « couches logicielles » classées par fonctionnalités : • la couche de présentation : c’est en fait ce que l’internaute voit du site Web. Cette « couche » est prise en charge par des scripts qui s’exécutent sur le poste de l’internaute (donc, des scripts clients) ; • la couche application : ce sont les traitements du site Web qui s’exécutent sur le serveur ; • la couche de contrôle : cette couche a pour rôle de contrôler l’articulation de fonctionnement entre la couche de présentation et la couche application. Ces architectures logicielles sont complexes. Mais quel est donc l’avantage de ce modèle de développement de sites Web ? Ah ça oui, on se le demande ! Et bien le graphiste (également appelé « Web designer », prononcer « ouèbe dizailleneu »), qui a été chargé de créer la couche présentation du site, peut très bien modifier sa couche présentation sans toucher au code source des traitements, puisqu’on a une séparation entre présentation et traitements. Mais on peut très bien développer un site Web avec les plateformes J2EE ou .net sans séparer la couche présentation, la couche application et la couche contrôle. Simplement, dans ce cas, on n’utilisera pas toute la puissance que permettent ces plateformes. Remarque : on peut aussi implémenter le modèle MVC avec par exemple du PHP. 2E. Et la sécurité dans tout ça ? Vous en êtes bien conscient, dès que l’internaute saisit des informations et les envoie sur la TAM (rappel : ça veut dire la Toile d’Araignée Mondiale, le Web quoi !), n’importe quel pirate (ou hacker) un peu futé peut récupérer ces informations pour en faire bon (et hélas plus souvent mauvais) usage. Toute application Web suppose donc des contrôles de sécurité. 8 3950 TG PA 00 27 Séquence 1 Présentation générale de la POW Les contrôles de sécurité concernent : • le poste client (celui de l’internaute) : il y a en effet risque de téléchargement de programmes non authentifiés (des virus par exemple, ou des espions qui scrutent le disque dur de l’internaute…) ; • l e réseau : il faut crypter certaines informations comme par exemple les numéros de cartes bancaires, afin que les méchants hackers ne puissent pas s’acheter de bonbons avec les sous qu’on a sur notre compte ; • le serveur : il y a en effet nécessité de sécuriser l’accès à certaines pages, par exemple par des mots de passe et des systèmes d’authentification. Il existe pour cela diverses solutions, comme par exemple le protocole HTTPs, un protocole sécurisé d’envoi des pages sur le Web, qui s’appuie sur SSL (Secure Socket Layer), un protocole gérant l’authentification et la confidentialité, utilisé pour les transactions financières (les paiements, virements) effectuées via Internet. Bon, j’ai à peu près fait le tour de ce dont je voulais vous parler dans cette séquence d’intro. Maintenant, il s’agit de faire. Dans ce premier fascicule, on va commencer par faire un peu de HTML, puis on fera du javascript, et pis c’est tout et c’est déjà pas si mal. Dans le fascicule 2, on abordera le reste : scripts serveurs, feuilles de style, XML, et peut-être quelques autres trucs sympas si le volume du fascicule n’est pas trop important (pas plus de 2 000 pages pour le fascicule 2, promis juré). Alors on se retrouve à la séquence 2, pour démarrer notre apprentissage de html… À tout de suite ! 8 3950 TG PA 00 28
