TABLE DES MATIERES *

INTRODUCTION *

PRESENTATION DU PROJET INRIA *

COMPARAISON DES TECHNIQUES DE SCRIPTING *

LE PROBLEME RENCONTRE *

QUELQUES REMARQUES SUR LES OUTILS *

LES NOUVELLES TECHNOLOGIES *

CONCLUSION *

Le besoin de mêler des données, de plus en plus nombreuses, aux classiques présentations du Web se fait de jour en jour d'avantage sentir. Les serveurs Internet sont de plus en plus fréquemment couplés avec une base de données.

Nous allons dans ce projet suivre cette tendance, en essayant de mettre en place le moteur de traitement et de publication permettant la gestion complète des prêts inter-bibliothèques pour la bibliothèque de l'INRIA de Sophia-Antipolis.

Le but de ce projet est de se familiariser avec quelques technologie Web présentées en cours. Nous avons choisi, d’une part, la technologie PHP3 : le langage de script encapsulé au sein du code HTML classique, afin de réaliser toute la partie fonctionnelle mise en place par le projet d'IHM (Interface Homme – Machine), permettant ainsi de couvrir tous les aspects de la réalisation d'un projet complet d'interface et de traitement d'informations à travers une interface Web. Ce sera l'occasion de dresser une comparaison des diverses technologies de publication que l'on a rencontré jusqu’à présent.

Et d’autre part, afin de mettre en œuvre les dernières technologies frémissantes du Web, nous avons également utilisé les feuilles de styles (CSS) et l’HTML dynamique (DHTML).

Ce rapport présente le projet de l’INRIA vu du côté technique, la partie caché de l’iceberg de l’IHM. Nous présentons, ensuite, une description détaillée de tous les moyens actuels permettant de publier de l’information en provenance de bases de données sur le Web. A partir de nos réalisations précédentes et de ce projet, nous réalisons une comparaisons des techniques de scripting. Et nous finissons par des remarques et les problèmes rencontrés lors du développement de ce projet.

Notre première démarche (et certainement la primordiale), avant d’amorcer le côté technique, a été de rencontrer l’utilisateur, en l’occurrence la bibliothécaire, afin d’étudier son comportement expérimental et de repérer ses habitudes, son mode de travail, l’enchaînement et la nature de ses micro-actions vis-à-vis de l’existant pour ne pas risquer, par la suite, de lui imposer un changement trop radical dans ses automatismes, ce qui s’avérerait très pénalisant pour elle.

De plus, nous l’avons interrogée pour connaître ses souhaits sur les nouveautés ou les perfectionnements à apporter à son outil de travail actuel ; nous lui avons également demandé de décrire oralement, avec ses propres termes, ce qu’elle effectuait au fur et à mesure qu’elle s’exécutait, afin que nous puissions, par la suite, réemployer les termes qui lui sont familiers au niveau de notre interface.

Pour notre bibliothécaire, le travail qui nous intéresse débute lorsqu’elle doit emprunter un ouvrage à une autre bibliothèque quand celui-ci n’est pas disponible au niveau local.

On dégage des étapes clefs qui vont constituer le squelette de l'application.

Afin, d'emprunter un livre à une bibliothèque distante, la bibliothécaire recherche le livre sur plusieurs sites Internet. Elle se sert donc des sites Internet déjà existant, dont elle possède parfois un accès privilégié à travers un compte. Une fois trouvé, une demande de prêt est réalisé pour l'ouvrage.

Seulement, deux sites sur la douzaine utilisée en général possède un formulaire de demande de prêt en ligne. Dans les autres cas, la bibliothécaire réalise un " copier-coller " de la page Web dans un mail classique, afin de donner les informations précises de l’ouvrage à la bibliothèque prêteuse auquel elle envoie le mail.

Elle se sert donc de plusieurs applications à la fois, le navigateur Internet et le mailer, elle est obligée de faire des " copier-coller ", et doit également rechercher ou mémoriser l’adresse e-mail des bibliothèques.

Elle mémorise la date de la demande, la bibliothèque, ainsi que les informations relatives à l'ouvrage, dans un mail qu’elle s’auto-envoie ou sur copie d’écran papier qu’elle classe dans un classeur, ce qui met bien en évidence le besoin d’un lien entre la recherche et la mémorisation de la demande.

L’emprunteur est alors associé, de façon manuelle, à l’ouvrage.

Une fois la demande effectuée auprès de la bibliothèque externe, la bibliothécaire doit suivre la vie de cet emprunt, en vérifiant l’arrivée effective de l’ouvrage, sa récupération par l’emprunteur, son rendu dans une plage de temps maximale, ainsi que sa réexpédition. Toutes ses opérations sont réalisées, par des consultations journalières des mails et des classeurs, ce qui est long est fastidieux, et doit être entièrement fait à la main. Chaque bibliothèque possédant son délai d’emprunt, en fonction de la date d’arrivée, de la possibilité de relance, il faut être sûr de ne pas rendre le livre en retard.

De plus, les confirmations de réception des ouvrages auprès des lecteurs, et les relances lors des rendu en retard s’effectue à travers le mail, en se souvenant de l’e-mail du lecteur, car elle est mémorisée nulle part et ne peut pas être rattachée à son nom, et en recopiant dans le mail, le titre de l’ouvrage.

Lorsque le livre a été réexpédié, la bibliothécaire archive cet emprunt, dans un classeur annexe, qui servira de base à la réalisations de statistiques, sur le nombre d’emprunts, les emprunts par bibliothèques, etc. Ces calculs sont réalisés à la main, en fin d’activité.

La mise en œuvre de notre projet va donc consister à réaliser une interface alliant facilité d’utilisation pour qu’il n’y ait pas de perte de temps en formation spécifique des utilisateurs à terme, efficacité de telle sorte qu’il n’y ait pas perte de productivité, tout en offrant un aspect agréable à l’utilisateur.

Le but du projet est donc de réaliser une application Framework, proposant à la bibliothécaire un outil fédérateur des différents outils qu'elle utilise, et simplificateur des nombreuses tâches fastidieuses nécessaires lors d'un prêt inter-bibliothèques.

On présente ici les grandes fonctionnalités mise en place par l’application, afin de reproduire le mécanisme existant, de l’améliorer et de répondre aux exigences et aux souhaits de la bibliothécaire.

Comme cela a déjà été remarqué plus haut, notre principal souci concernant notre interface va être de répondre aux besoins suivants :

• réussir à établir un lien entre les différentes étapes qui composent le processus de prêt inter-bibliothèques, c’est-à-dire entre la recherche d’un ouvrage, la demande de prêt le concernant, le suivi de cette demande puis son archivage à l’échéance, notamment en supprimant totalement le support papier pour passer de l’une à l’autre.

• créer un véritable moyen de gestion du suivi des prêts en cours et de l’archivage quand le prêt est fini, de façon à avoir facilement et à volonté sous les yeux le niveau d’avancement du prêt, autrement dit qu’il soit possible pour chacune des bibliothécaires, sans savoir ce que les autres ont fait avant, de connaître les livres qui doivent être reçus, ceux qui doivent être rendus et les relances qui doivent être effectuées.

En partant du principe que toutes les demandes (pour les bibliothèques en ligne, évidemment ) vont être réalisées, via le mail, par formulaires types prédéfinis et qui vont donc contenir l’ensemble des informations utiles, ces derniers vont nous servir d’outil de transfert entre le Web et la base de données qui va assurer la sauvegarde des informations.

De ce fait, notre application va devoir être capable de :

• mémoriser automatiquement les renseignements relatifs aux demandes tels qu’ils apparaissent sur le formulaire et de les intégrer à la base de données.

Conséquence : plus de tirage papier !

• prévenir automatiquement l’emprunteur local quand son livre est arrivé : dès que la bibliothécaire rentre dans la base la date de réception du livre, l’application doit retrouver l’e-mail de la personne associée à ce livre dans la base et lui envoyer un mail pour l’avertir.

• présenter sous une forme synthétique le suivi de tous les emprunts en cours, afin de faciliter le traitement des emprunts.

• repérer quand un emprunteur est en retard pour rendre son livre et lui envoyer automatiquement un mail pour le prier de rapporter l’ouvrage dans les plus brefs délais ; cette détection s’effectuerait par la comparaison entre la date du jour interne et la date attendue de retour, calculée automatiquement en fonction de la date de réception rentrée.

• avertir la bibliothécaire si, malgré la relance, le livre n’a toujours pas été rapporté.

Conséquence : pas d’oubli possible.

• faire passer de la base de données " active " à la base de données " archive " les informations relatives à un livre quand celui-ci a été retourné à la bibliothèque prêteuse : ce transfert devrait avoir lieu dès que la bibliothécaire a entré le jour de retour du livre par l’emprunteur dans la base  " active ".

• calculer de façon automatique, les statistiques nécessaires au rapport d’activité annuel, ainsi que quelques chiffres significatifs permettant une amélioration des relations entre les bibliothèques.

L’application ne serait pas complète sans des possibilités de configurations, et d’administrations précises. L’application offre, un ensemble de formulaire permettant de saisir de nouveaux lecteurs, de nouvelles bibliothèques, de les modifier à loisir, mais aussi de configurer les délais de relances ainsi que le corps des messages e-mail, à l’aide de mots clefs qui seront remplacés par les informations en provenance de la base.

L'outil informatique, par sa capacité de mémorisation et de traitement va permettre de rendre plus simple un grand nombre de manipulation. On voit très bien, que la mémorisation des étapes du prêts dans une base de données, va permettre un suivi précis. La mémorisation des adresses HTTP et des lecteurs, de leurs e-mail, va diminuer les recherches. De plus, les calculs sur les dates pourront être automatisés, afin de proposer des alertes lors des dépassement.

Pour réaliser une application encapsulant l’existant, et pour tirer parti des sites Internet existant, nous avons décider de réaliser l’application en HTML, au sein d’un browser Web, en combinaison avec du JAVASCRIPT. Afin, d’appréhender les technologie émergeante du Web, nous allons également réalisé quelques parties en DHTML. La connexion à la base de données sera réalisée à l’aide du module PHP3 permettant le scripting et la connexion à la base de données, afin de créer des pages dynamiques reposant sur des requêtes SQL standard.

Dans son " idéal de conception ", l’étude d’I.H.M. (Interface Homme-Machine) a pour objectif essentiel de concevoir et de développer des systèmes utilisables et fiables, tout en assurant le lien entre le noyau fonctionnel et l’utilisateur, au sein du système informatique : c’est un outil de base prépondérant dans la réussite d’un système interactif.

Cette interaction, dans sa quasi-totalité, rentre en jeu au moment des entrées ou des sorties d’information entre l’utilisateur et sa machine. A ce niveau, des notions aussi banales (voire laissées en arrière plan par rapport aux performances d’un logiciel !) que la couleur de fond d’un écran, l’utilisation de la souris plutôt que du clavier, la compréhension simultanée de la signification d’un icône, sa place sur l’écran ou encore l’agencement des éléments, sont autant de détails qui vont améliorer le confort de l’utilisateur et donc rendre le logiciel concerné plus attirant et donc plus compétitif sur un marché très concurrentiel.

Bien que le langage HTML et le protocole HTTP soit rudimentaire, couplés avec du JAVASCRIPT côté client, ils permettent tout de même de mettre en place un grand nombre de fonctionnalité et de concepts avancés de l’IHM.

• Réutilisabilité des données d’entrée et de sortie

Le cas qui illustre le mieux cette remarque est la sélection d'un nouveau lecteur lors de la saisie d'une fiche de mémorisation d'une demande à une bibliothèque Hors-Ligne. Lorsque l'utilisateur remplit la fiche, si il ne trouve pas le nom du lecteur dans la liste, c'est donc un nouveau lecteur. S’il demande la création d'un nouveau lecteur, il bascule sur un formulaire différent qui lui permet de saisir un nouveau lecteur. Mais, une fois cette saisie effectuée, l'utilisateur veut revenir sur la page qu'il utilisait précédemment, exactement au même point, sans avoir à reprendre ce qui a déjà été rentré : c'est ce que notre application fait. De plus, il ne faut pas qu'il perde les informations qu'il a déjà saisi sur le formulaire initial, il faut donc mémoriser toutes les données, et les réafficher lorsque l'utilisateur revient sur la page principale. De plus, l'utilisateur ayant saisie un nouveau lecteur, lorsqu'il revient sur la page principale, la sélection du lecteur est automatiquement placé sur le nouveau lecteur.

Cette technique est permise par la mémorisation entre les pages de l’informations à l’aide de champ de formulaire caché (HIDDEN) qui sont dispatchés et sont retournés à la page appelante, ainsi les informations sont immédiatement exploitables.

• Multiplicité du rendu

De la même manière, on permet à l’utilisateur de saisir une date de plusieurs manières différentes. On lui offre la possibilité de saisir une date à la main, ou d’accéder à un menu spécial afin de choisir une date à l’aide de la souris. Cette possibilité offerte à l’utilisateur recouvre parfaitement l’hypothèse de multiplicité du rendu puisque l’utilisateur peut utiliser plusieurs représentations différentes pour le même concept. Le JAVASCRIPT et le DHTML, permettent de créer des parcelles de code HTML n’importe où sur une page HTML, le dynamisme est très efficace.

• Adaptabilité

La meilleure illustration de cette possibilité est certainement le choix du tri de la présentation du suivi des emprunts. En effet, lorsqu'un nouveau type de tri est choisi, il n'est pas nécessaire de cliquer sur un bouton pour entériner le choix, le simple fait de choisir va lancer le réaffichage avec le nouveau type de tri choisi. Un seul composant doit être manipulé par l'utilisateur, ce qui rend sa manipulation très efficace. C’est le JAVASCRIPT à l’aide de sa gestion précise des événement sur les composants qui permet d’intercepter les utilisations souris, et de provoquer la soumission instantanée du formulaire, permettant ainsi un réaffichage de la page avec un nouvelle présentation.

• Honnêteté

Lors de la saisie d'informations à l'aide d'un formulaire, il est très pratique de ne pas être obligé de prendre la souris pour placer le curseur sur le premier composant du formulaire. Il est possible de placer systématiquement le curseur sur le premier composant lors de l'affichage de la page, afin de saisir directement les données. Ceci contribue à améliorer l’honnêteté du système en améliorant la capacité du système à rendre observable son état sous une forme conforme à cet état et qui engendre une interprétation correcte de la part de l’utilisateur. Le JAVASCRIPT donnant accès à tous les composants sur une page HTML, on peut atteindre le premier composant de la page, et lui donner le " focus ".

• Curabilité

Lorsque l'utilisateur à fini de saisir les champs d'un formulaire, et qu'il soumet le résultat, il est avertie à l'aide de boîtes de dialogues de son erreur. En essayant de réaliser des boîtes les plus précises possibles, c'est à dire en indiquant le champ invalide, le format qu'il faut fournir, la longueur maximale, on permet à l'utilisateur de bien comprendre son erreur et de la rectifier immédiatement. De plus, cette vérification ayant lieux, immédiatement après la soumission, sur le poste client, cela permet de maintenir visible les informations rentrées par l'utilisateur, il ne perd pas ainsi de vue ce qu'il à taper. Les messages d'alerte ne sont pas affichés une fois que le contenu à basculer sur le serveur, on ne laisse pas faire n'importe quoi à l'utilisateur, il est guidé et se sent plus en confiance. La vérification à l’aide de JAVASCRIPT du contenu de chaque champ du formulaire, à la fois dans son type, dans sa longueur permet d’avoir un contrôle précis des saisies utilisateurs. Les informations sont vérifier sur le client, ce qui allège d’autant les requêtes HTTP, et qui permet à la base de ne pas se soucier de ce qui lui est transmis.

Une autre petite facilité est donnée lorsque le curseur vient automatiquement se placer sur le champ invalide après l'affichage d'un message d'alerte indiquant que ce champ est invalide. L'efficacité que cela procure est immédiate, on n'a plus à utiliser la souris, ni à chercher le champ incriminé.

Ces deux aspects techniques du logiciel, ont tendance à réduire les erreurs de l’utilisateur. Ces deux aspects améliorent en effet la capacité pour l'utilisateur de corriger une situation non désirée. Ainsi, notre système vérifie également l’hypothèse de curabilité à l’aide de JAVASCRIPT et de son contrôle fin des champs d’un formulaire.

• Prévisibilité

On peut rajouter pour chaque image un libellé. Cela permet lorsque la souris reste un certain temps positionnée sur l'image, d'afficher une information sur l'image, soit un titre plus précis soit, la destination du lien hypertexte attaché à l'image. Ainsi, on respecte la net-tiquette en fournisssant tout de même de la sémantique aux images.

Essayons de voir quels sont les moyens existant pour mettre à la disposition des internautes des données provenant en particulier de bases de données.

Quel que soit la méthode employée, la publication de donnée sur le WWW (World Wide Web) passe par le langage de description de page HTML (HyperText Markup Language) bientôt remplacé par le XHTML (eXtended HTML).

Pour accéder à ces pages HTML, elles doivent être référencées par un serveur Web. Lorsqu'un utilisateur se connecte à un site Internet à l'aide de son navigateur, il communique de façon transparente par le biais du protocole HTTP (HyperText Transfer Protocol) avec le serveur Web. Le serveur Web, qui stocke toutes les données du site, est alors capable d'analyser les requêtes qu'il reçoit, retrouve le fichier demandé et l'envoie au navigateur qui l'affiche à l'écran. Le serveur Web peut bien entendu stocker d’autres informations, en particulier des bases de données. Nous essayerons ici de présenter les grandes méthodes de publication de données sur Internet.

La première, qui est le plus simple à mettre en œuvre, consiste à construire des pages HTML fixes, codées en dur. Ces Web statiques sont composées de pages HTML réalisées à la main ou à l’aide de logiciels d’édition plus ou moins évolués. Aujourd’hui les éditeurs de pages HTML avec interface de type WYSIWIG (What You See Is What I Get) facilitent le développement d’applications de publication ou de partage de documents. La webisation des suites bureautiques permet même, depuis un environnement bien connu (tableur ou traitement de texte), de convertir tout document au format HTML. Même si cela fournit un accès direct à des pages d'informations à la mise en forme attrayante, il n'en demeure pas moins que l'interaction offerte entre l'utilisateur et le serveur Web reste limitée, et que les pages statiques doivent être éditées manuellement pour mettre à jour leur contenu. Le dynamisme du site repose sur la fréquence des mises à jour, et cela reste un travail fastidieux pour le WebMaster (ou WebMestre : personne responsable du site Internet).

Dans la même catégorie, il existe la solution de pré-générer des pages HTML à partir de résultats de requêtes à l'aide d'un langage de script.

Ces applications Web statique avec données générées permettent de publier des informations issues de bases de données en rafraîchissant périodiquement les pages HTML sur le serveur HTTP. La mise à jour s’effectue par exécution d’un script qui appelle un convertisseur chargé de générer les pages Web à partir de la base de données. Dans ce cas, le navigateur n’interagit pas avec la base de données. Plusieurs SGBD sont d’ores et déjà livrés avec les convertisseurs adéquats. Par exemple avec SQL Server 6.5 et son Web Assistant, l’utilisateur définit une requête dont la réponse sera publiée au format HTML; l’opération peut être programmée de manière à actualiser régulièrement un ensemble de pages Web. De la même manière, l’assistant de publication Web d’Access propose, comme première option, de générer des éléments sous forme de pages HTML statiques. Avec Corel Web Data, l’utilisateur déclare le SGBD source et la base de données puis sélectionne les champs à publier. Il est ensuite possible d’enrichir la page HTML au sein de laquelle seront publiés les résultats; l’ensemble de ces informations est stocké dans un fichier traité à chaque fois que l’on souhaite publier les données de la base.

C'est moins contraignant, mais il faut tout reconstruire à chaque mise à jour, il n'y a donc aucune notion d'actualisation en temps réel.

Le Web statique permet donc de réaliser des applications de publication de documents supportant une mise à jour des données périodiques. Mais, si la taille de la base de données et son actualisation nécessitent d’y accéder réellement depuis le navigateur, il faut s’orienter vers le Web dynamique.

Les applications Web dynamique fournissent une information actualisée sans qu’il soit nécessaire de composer au préalable une page HTML contenant les nouvelles données. Il existe alors une interaction entre le navigateur et la base de données. En cliquant sur un lien ou en remplissant un formulaire, l’utilisateur envoie une requête au serveur Web. À cette fin, une entité joue les intermédiaires entre le serveur Web et la base de données. La page HTML que consulte l'utilisateur est fabriquée, à la volée, en fonction de la requête qui questionne la base de donnée.

Plusieurs solutions sont possibles :

• CGI (Common Gateway Interface)

Dans les pages HTML classiques, il existe des liens hypertextes qui ne renvoient pas sur un document HTML, mais sur un programme appelé Gateway (passerelle), qui est en fait une application exécutable. Ce programme, aidé des paramètres issus des champs de saisie de la page d'origine, peut alors se connecter à une base de données, envoyer une requête et formater le résultat en HTML. C'est se résultat qui apparaîtra dans le navigateur de l'utilisateur.

Les programmes passerelles présentent l'inconvénient d'être difficiles à créer et à modifier, ils sont généralement écrit en C ou en Perl (Practical Extraction and Report Language : langage interprété à mi-chemin entre le C et le shell UNIX), et sont dépendant des entrées-sorties de leur plate-forme d'exécution et donc ne sont pas 100% portables. Ils ne sont pas intégrés dans des fichiers HTML. En réalité, ils nécessitent un processus de conception totalement différent de celui des fichiers HTML.

• ISAPI (Internet Server Application Programming Interface), NSAPI (Netscape Server Application Programming Interface) sont respectivement les passerelles propriétaires de Microsoft et Netscape.

• La technologie ASP

La technologie ASP (Active Server Pages) de Microsoft permet d'inclure des scripts, dans un langage de script tel le Visual-Basic, directement exécutables dans les fichiers HTML. La communication avec les bases de données se fait grâce à une liaison vers ODBC que ASP met à disposition. Ces pages sont interprétées sur le serveur et non pas sur le client. Le serveur renvoie vers l'utilisateur du code HTML classique déjà formaté et construit autour de requêtes SQL standard.

• La technologie JAVASCRIPT-SERVEUR

Outre l’utilisation du JAVASCRIPT côté client, Netscape propose un serveur Web (Enterprise – SuiteSpot) qui permet de mélanger au sein des pages HTML, du code JAVASCRIPT qui sera interprété uniquement du coté serveur. Les pages HTML incluant le code JAVASCRIPT Serveur, sont en fait précompilées avant toute utilisation. Ce code sera alors interprété par le serveur Web et donnera, grâce aux extensions spécifiques à la version serveur du JAVASCRIPT, des possibilités de connexions aux bases de données les plus courantes.

• La technologie PHP

Cette solution identique dans son fonctionnement aux deux précédentes, permet encore de mélanger du code HTML et un langagede Script, ici proche du C. Elle permet une connexion à de très nombreuses bases de données, de façon efficace et native dans la plupart des cas, ce qui lui confère une grande rapidité. Cette technologie couplé au serveur Web Apache offre certainement la seule solution totalement Free de publication et de scripting actuel.

• La technologie Cold-Fusion

Il existe une autre technologie : Cold-Fusion, également basé sur le principe de serveur-side scripting, mais que nous n’avons jamais mise en œuvre.

• Les Servlets : aplications serveur et communicantes

La firme SUN propose un système similaire basé sur le langage JAVA, langage orienté objet de SUN. Les Servlets sont un ensemble de classes JAVA, donc utilisables et compilables par la machine virtuelle JAVA de SUN, qui remplace les CGI.

Actuellement disponible dans sa version alpha 2.0, le serveur Web Jeeves de SUN supporte les protocoles HTTP et HTTPS (accès sécurisé) et intègre les fonctionnalités les plus courantes : CGI 1.1, mapfile NCSA, administration à distance. Outre sa portabilité sur la plupart des systèmes qui supportent le JDK 1.0.2 (le kit de développement JAVA), car il est entièrement écrit en JAVA, Jeeves est intéressant par son architecture de services extensible et modulaire que lui confère les Servlets. Les Servlets sont des objets JAVA qui étendent les fonctionnalités des serveur HTTP tels Apache (le plus populaire et le plus performant) ou IIS. Elles peuvent être chargées localement ou dynamiquement à travers le réseau. Comme les scripts CGI, les Servlets sont capables de générer des pages HTML dynamiques, mais elles offrent d'autres possibilités. Par exemple, une Servlet peut établir une connexion avec un client suivant un protocole donné (ex : RMI (Remote Methode Invocation)), elle peut même être téléchargée sur un serveur pour y être exécutée afin de collecter des informations. Un peu à la manière de ces agents mobiles (pas forcément intelligent !) dont on parle de plus en plus, mais sans en avoir totalement les fonctionnalités : les agents mobiles déplacent leur comportement et leur état alors que les Servlets déplacent uniquement leur comportement. Il est fort à parier que cette limitation soit levée grâce à l'API object serialization qui permet déjà de stocker l'état d'un objet JAVA sous une forme adaptée pour y être envoyée sur réseau ou sauvegardée sur disque.

SUN s'est peut être rendu compte, en lançant cette solution, de la difficulté de la mise en œuvre des Applets sur les postes clients. Ne fournit-il pas en contre-partie ce paliatif?

Les Applets JAVA qui sont capables d'interagir avec des bases de données et de les présenter sur Internet, apportent une nouvelle solution de publication de l'information à travers le Web. Le langage de développement JAVA semble bien adapté au Web pour deux raisons : d’abord l’exécution d’une Applet s’effectue sur une machine virtuelle Java, donc indépendamment de la plate-forme; ensuite, les applets sont compactes, donc transitent facilement sur le réseau. Qui plus est, SUN a ajouté dans le JDK 1.1 (Java Development Kit) JDBC (Java DataBase Connectivity), interface d’accès aux bases de données. Mais alors le poste client tend à assumer une partie des traitements tandis que le propre du Web est de concentrer le traitement sur le serveur.

Une quatrième consiste en la réalisation d'un pont client-serveur, la partie serveur exécutant les requêtes et faisant passer les résultats au client qui les affiche, à l'aide du protocole IP ou d'un protocole propriétaire qui peut être sécurisé. Cette méthode est certainement la plus propriétaire, mais c'est aussi la plus sécurisée, car seul les programmes autorisés sur le serveur peuvent accéder à la base et suivant l'identification de l'utilisateur ses permissions sont plus ou moins étendues et lui donnent plus ou moins de possibilités dans la manipulation de la base.

Oracle fournit Oracle Web Server, ce serveur d’application conçu pour Oracle 7, a recourt à des Web Request Broker pour orienter les traitements vers les cartouches qui leur correspondent, cependant la dernière version d’Oracle 8i offre plutôt une solution proche du scripting et d’un moteur de génération de page à la volée. D'autres grands noms comme Informix, Sybase qui proposent depuis longtemps des logiciels client-serveur entièrement propriétaires, basés sur des protocoles de communication propriétaires, mais s'intégrant aux protocoles réseaux standard (TCP/IP, IPX/SPX ...), se tournent de plus en plus vers Internet et sa facilité de déploiement. Le logiciel IntraBuilder de Inprise (ex Borland) propose un pack complet permettant de construire, d'administrer et de distribuer sur Intranet et Internet les données mises en place dans sa base.

Les techniques de scripting sont en pleines effervescence. Tout le monde fournit sa solution propre, ce qui permet d'affirmer que cette solution n'est pas une mauvaise solution et surtout qu'elle répond à un très grand nombre de problèmes et surtout aux attentes des clients.

Basé sur notre expérience personnelle, nous essayerons ici de réaliser une comparaison rapide, mais précise, de trois de ces technologies en essayant de dégager les points forts, les points faibles, les ressemblances de ces produits, sans oublier les possibilités de connexions aux bases de données, ainsi que les techniques le plus souvent employées.

1. Active Server Pages de Microsoft

 

La solution Microsoft est propriétaire. L’obligation d'utiliser le système d'exploitation Windows NT, et le serveur Web IIS (ou PWS de façon minimaliste) qui intègre le moteur ASP et les composants ADO pour la connexion aux bases de données est certainement le point le plus négatif de cette solution. La connexion aux bases de données s’effectue à travers le pont ODBC. Il suffit donc que la base possède un driver ODBC pour qu’elle soit accessible instantanément.

 

Un premier avantage saute aux yeux

L'avantage indéniable de l'utilisation d'ODBC : un seul code d'accès aux bases et nécessaire. En effet, si l'on commence le développement de l'application sur une petite base ACCESS et que l'on souhaite ensuite passer à SQL-SERVER ou ORACLE, le code ne change pas d'une ligne. Il suffit de remplacer la base référencée sous le nom symbolique utilisé dans le repository ODBC et c'est le nouveau driver qui sera utilisé et qui communiquera avec la nouvelle base. On pourrait se dire que l'utilisation d'ODBC restreint le nombre de base utilisable, c'est en fait le contraire, pratiquement toutes les bases actuelles (Microsoft, ORACLE, SYBASE, et quelques bases FREE) proposent un drivers ODBC. De plus, le repository ODBC devient une norme, et existe même pour plate-forme UNIX.

Cependant, il est clair que la communication à travers ODBC n'est pas optimale en terme de performance, mais aussi en terme de possibilité, car toutes les commandes propriétaires des bases et les optimisations possibles ne sont pas supportées. Cette solution est néanmoins une solution fiable, robuste et extensible ce qui est non négligeable au vue des développement actuel.

 

La technique de connexion

On instancie le composant ADO permettant de réaliser un connexion avec ODBC.

On ouvre la connexion sur la base particulière avec une identification et un password.

La requête réalisée sur la base est une " vraie " requête SQL (norme ANSI-92) que l'on écrit dans une chaîne, on possède donc la possibilité de la construire dynamiquement à partir de résultat de calcul des paramètres récupérés par des sélections client, etc.

Puis on exécute la requête, de deux manières différentes, en bloc où l'on parcours le résultat en lecture destructive, ou alors à l'aide d'un curseur permettant une action plus fine sur les résultats. Bien entendu, les deux groupes de requêtes SQL peuvent être réalisés : avec retour d’un résultat (SELECT), et sans retour (UPDATE, INSERT CREATE).

 

Le langage de script

Le langage de script utilisé par défaut par le moteur ASP et le VBScript, qui n'est plus ni moins qu'un Visual-Basic édulcoré, qui ne possède plus que son noyau Core et les fonctions de traitement de chaîne et de fichier, mais auquel on a rajouté un composant ADO d'accès aux bases ODBC particulièrement simple à mettre en œuvre.

Les tags délimitant le Script sont les tags <% %> où l'on inscrit le code VBScript. On possède deux techniques de production d'une page :

Soit on créer la page HTML et l'on place, quand le code est simples, le code Script au sein des tags HTML

Soit on produit le code HTML à partir du résultat du Script, en écrivant le code à l’aide d’une fonction d’écriture de chaîne dans la page HTML ainsi générée.

Le langage permet de réaliser des fonctions, de les inclure à la demandes. Mais, bien que ce langage soit de haut niveau (le typage est inexistant), il n'est pas possible de réaliser des applications très pointues. Les codes d’erreur peu explicites et le fait que le langage soit interprété ne facilite pas le debuggage. Cependant, sa simplicité d'utilisation et la rapidité d'apprentissage en font un produit tout à fait adapté à la mise sur le Web d'un catalogue quelque soit sa taille. De plus, si l’on se limite à des Script côté serveur, ne possédant pas Script côté client, le code reçu par le client sera du code HTML pur, interprétable sur toute plate-forme, et même par de très vieux browser tel que Mosaïc, voir Lynx en mode texte.

 

La persistance

Bien entendu, le moteur ASP permet de récupérer de façon transparent les valeurs des champs d'un formulaire soumis par le client, ce qui permet l'interaction et un comportement dynamique, mais il propose en plus la possibilité d'utiliser des variables particulières.

Les objets sessions permettent d'attacher à un client, et quel qu'en soit le nombre, un ensemble de variables persistantes qui lui sont propres et qui lui resteront attaché jusqu'à sa déconnexion. On peut ainsi mémoriser des variables pour une personne, et les utiliser sur chaque page qu'il accède. C'est très pratique, car cela conserve des variables d'environnement propre à chaque utilisateur, et une fois que l'on y a goûter on ne peut plus s'en passer. En effet, si l'on veut réaliser la même chose en code HTML pur, il faut à chaque fois faire transiter les variables dans des balises HIDDEN des formulaires, ce qui est très lourd à gérer à la main.

Les objets applications sont eux des objets persistants communs à toutes l'application, ils stockent le plus souvent les résultats de requêtes en provenance de données très peu mises à jour dans la base, afin de décharger les accès à la base, et sont visibles par tous les utilisateurs.

 

Le traitement des formulaires

Lorsque l’utilisateur soumet un formulaire, il faut créer une page ASP, afin de traiter les données pour produire un résultat en fonction des choix de l’utilisateur, ou pour réaliser une action sur la base de données. Le moteur et le VBScript offrent une transparence de la réception du contenu des formulaire, car les résultats obtenu dans des variables portant le nom des champs du formulaire, sont déjà décodés quel que soit la méthode de soumission GET ou POST.

 

Les sauts de pages conditionnels

Bien que le protocole HTTP, ne permettent pas de rediriger une page vers une autre de façon transparente en cours de route. Le moteur ASP permet de bufferiser de façon transparente la page envoyée et donc de permettre une redirection à la volée, en cas d'erreur ou de choix multiple dans les script. Chose que l'on veut faire assez souvent, sans se préoccuper des limitations du protocole. En fait, le principe est simple, la page n’est envoyée qu’une fois que le parser l’a entièrement parcouru, on perd donc en rapidité de publication, mais on gagne en flexibilité, en particulier sur les pages testant des valeurs.

 

Les performances du moteur ASP

La rapidité d'exécution est plus que correcte, et la génération de page est très rapide. C'est au niveau du serveur Web que le goulot d'étranglement apparaît, car IIS semble ne pas être des plus rapide. Cependant, il est très bien intégré au système. Son système de droit d'accès est simple et repose sur celui des répertoires directement géré par Windows NT sur partition NTFS. Il est clair que sur ce point Apache est plus rapide, même sur plate-forme NT, et que sa technique des fichiers .htaccess et beaucoup plus pointue que celle proposée par IIS.

Il est a noté qu’un moteur comprenant la syntaxe ASP existe sur plate-forme UNIX : c’est le portage CHILI.

 

2. Netscape avec Suite-Spot

 

Netscape nous propose ici un véritable "Bundle", le serveur et le script côté serveur. Le langage utilisé est ici JAVASCRIPT (le portage Netscape du langage l'ECMA). Il est robuste, simple à appréhender et permet une approche objet d'un niveau convenable, cependant cette solution reste propriétaire à la fois dans le langage de Script et dans le serveur Web, bien que le serveur Enterprise existe sur de nombreuse plate-forme (Windows NT, UNIX, Solaris).

 

La technique de connexion

De la même manière que pour la solution précédente la connexion à la base est simple et se déroule sur le même schéma. En effet, quelque soit la base attaquée, quelle soit ODBC ou propriétaire l'API de communication reste la même, ce qui n'oblige pas de changer le code en cas de changement de base, seul les paramètre d’instanciation de la connexion différe. Les requêtes, ici aussi, conforme à la norme ANSI-92, s’écrivent sous la forme de chaînes constructibles à la demande et paramétrables à souhait.

 

Le langage de script

Le langage de Script est le JAVASCRIPT, mais interprété du côté serveur. C’est un langage normalisé, permettant une approche objet claire, mais atypique, qui offre toute une panoplie de fonctions précodés de qualité au comportement stable. Cependant, le debugage n’est pas facilité par des messages d’erreurs parfois incohérents.

Le code encapsulé dans des balises <SERVER> </SERVER> permet la production de code HTML, aussi bien que l'autre technique, d'encapsulation du code Serveur dans le HTML. Une astuce, consiste à produire du code JAVASCRIPT client à partir du code JAVASCRIPT serveur, c’est assez fumant, mais peut être généralisé à toutes les autres solutions de scripting, car en fait elle est indépendante du langage de Script .

 

La persistance

Netscape Enterprise permet d'avoir des variables clients et serveur. Les variables serveur (classe project) sont utilisées naturellement comme des variables globale à toute l’application et correspondent aux objets applications de ASP, mais les variables clients ne sont pas aussi simple à gérer, elles doivent être communiquer de façon explicite entre les pages.

 

Le traitement des formulaires

Netscape fournit également un support transparent des données des formulaires.

 

Les sauts de pages conditionnels

Bien que impossible à faire du côté serveur, la page est immédiatement envoyé au client, c’est le JAVASCRIPT du côté client qui permet un basculement à la volée vers une autre page.

 

Point faible

Par contre, un certain nombre de reproche peuvent être fait à la solution de Netscape, d'une part le code des pages HTML doit être " compilé " afin d'obtenir une sorte de byte-code Netscape. Cette solution est contraignante car il faut recompiler toutes les pages même si une seule a été modifiée. Elle a normalement l'avantage d'améliorer les performances, mais il n'y a pas de gain notable par rapport aux autres solutions. D'autre part, le serveur de Netscape associé au moteur de production de page est très instable, sur le serveur de l'ESSI, un redémarrage était nécessaire tous les jours, car en phase de développement il ne tenait pas le coup. Alors que les autres moteurs, ASP ou PHP3 n'ont pas de problème, il semble qu’une interprétation page à page soit plus facile qu’une interprétation de byte-code.

 

 

3. PHP3

Le monde Unix n'est pas en reste et propose comme solution phare PHP3 couplé entre autre au serveur le plus utilisé au monde Apache.

La première remarque, que l'on peut faire et que les tags d'encapsulation du code PHP3 dans le code HTML (<?php ?>) peuvent être remplacé par les tags des ASP (<% %>). On peut donc en conclure que d'une part le portage d'un vers l'autre ne sera pas trop dur, mais surtout que le monde UNIX regarde le monde NT et essaye d'attirer les développeurs à lui, en ne bouleversant pas trop les techniques déjà employée, mais je vois surtout dans cette possibilité une sorte de reconnaissance qui dirait "sur ce coup là la technologie Microsoft n'est pas mauvaise" (mais bon c'est très personnel comme remarque). Et, au regard du code ASP classique, il est vrai que l’on peut facilement porter le code ASP vers du code PHP3, l’inverse est moins sûr, car le nombre de fonction proposées par PHP3 étant plus nombreuses et en provenance du monde C/UNIX, elles seront beaucoup plus difficilement portables.

La technique d'encapsulation du code HTML peut, à l'aide de PHP3, utiliser les deux méthodes code HTML autour du code PHP3 ou code PHP3 produisant du code HTML dynamique.

PHP3 fournit également un support transparent des données des formulaires et va encore plus loin en instanciant les résultats des champs sous la forme de variables locales à la page de réception.

Cette possibilité n’est permise qu’à l’aide d’une méthode agissant sur l’entête HTTP de la page, ce n’est pas très efficace, car elle doit être placée au début de la page ne permettant pas de traitement (modification du HEADER). Il faut donc se servir du code JAVASCRIPT client pour simuler cette possibilité.

Le mécanisme est toujours aussi simple. On choisit la base sur laquelle on veut travailler. La requête SQL est ici aussi une requête SQL standard sous forme de chaîne, ce qui facilite la communication, standardise l'accès et permet l'utilisation d'un langage de commande connu. On exécute la requête, et l'on obtient un pointeur sur la réponse que l'on traite par un parcours, dans une boucle . L'accès aux champ du n-uplet peut se faire comme en ASP, soit par son indice correspond à son indice de position dans le SELECT SQL, ou tout simplement en nommant le champ. PHP3 offre un éventail plus important d’extraction des résultats, sous la forme d’un curseur, d’un objet, d’un tableau, d’une classe, ou tout simplement d’une variable par exemple lors d’un comptage.

PHP3 offre peut être le plus grand nombre de contrôle d'erreur. Il faut savoir que les requêtes mêmes générées dynamiquement doivent en principe toujours être correcte à la fois dans leur formulation, dans les champs consultés et dans les bases utilisées, donc vérifier systématiquement que l'exécution de la requête s'est bien déroulé est parfois inutile. Le problème majeur est simplement de savoir si la base est en vie ou pas. Il ne faut pas confondre un retour de requête ne contenant pas de résultat et une requête défectueuse, le premier cas doit être traité et permet justement un comportement particulier, le second cas ne doit pas se produire sauf problème mécanique.

PHP3 possèdent un ensemble assez impressionnants de modules permettant de communiquer de façon native avec les bases les plus utilisées du marche sans oublier ODBC. C'est certainement son point fort. L'utilisation conjointe d'un système UNIX (Linux dans notre cas) d'un serveur Apache, du module PHP3 très proche d'Apache et d'une base de donnée rapide (MySQL par exemple), permet d'obtenir des performances tout à fait impressionnante lors de la génération dynamique de page à partir de requête sur une base.

Mais, car il y a un mais, si l'on utilise les fonctions d'accès propriétaires aux bases, et que l'on souhaite changer de base, il faudra dans le meilleur des cas remplacer toutes les fonctions par leurs équivalents dans la nouvelle base. Ce qui au niveau de l'évolution peut apparaître comme un frein.

Cependant, il n'y a pas la possibilité d'utiliser des objets session ou application, les variables ont une porté limitée à la page. Le passage des paramètres et leur mémorisation doit être réalisé à la main.

Bien entendu, il est possible d'utiliser les cookies du côtés clients, afin de maintenir de l'information entre les pages, mais cette technique reste tout de même dépendante du bon vouloir de l'utilisateur. L'utilisateur peut ne pas accepter les cookies sur son disque, le site ne serait alors pas consultable, c'est tout de même une limitation de taille. C'est pourquoi nous n'avons pas utiliser les cookies.

La solution préconisée est donc de réaliser la persistance à la main à l’aide d’une table stockant des informations clients dans la base. Cette solution apparaît tout de même à la fois contraignante, car il faut sortir toute l’artillerie des connexions aux bases et il va falloir tout de même un identifiant unique attaché à chaque client, d’où la nécessité d’un champ caché systématiquement reporté sur chaque page et initialisé à l’arrivé du client. On voit très bien, qu’il va falloir une gestion fine de cet identifiant, pour permettre au client de visiter le site à partir de n’importe quel point d’entrée.

Un autre point fort de PHP3 et sa large bibliothèque de fonctions, allant de l'analyse simple de chaîne, en passant par les expressions régulières, la gestion fine du protocole HTTP et en allant jusqu'à la possibilité de parser, de façon non validante du code XML.

On peut noter que la base de données orientée objets O₂ possède un module de publication de données, permettant de produire des pages HTML à partir du langage O₂C. La connexion à la base fait parti des possibilités d’exécuter de l’OQL (le SQL d’O₂) au sein du code C, elle est donc optimale, cependant ce sont les possibilités de publication et de traitement qui sont réellement d’un niveau très inférieur à ce que permettent les solutions de scripting précédentes.

Et bien, comme dans tout développement informatique, il n'y a pas de meilleure solution. Il y a une solution : celle qui est la plus adapté au projet, à l'existent, au temps que l'on veut y passer et à toutes les contraintes matérielles. Cependant, la technologie ASP de Microsoft semble tout de même être la plus simple à mettre en œuvre, à écrire et à maintenir.

Dans l'optique de constituer une interface, un peu à la manière du design-pattern " wrapper ", autour des pages HTML utilisées normalement par la bibliothécaire pour réaliser les recherches sur les sites Internet, nous avons essayer de créer une interface " d'écoute ", de suivi des actions de l'utilisateur. Cette interface, en quelque sorte devait permettre de suivre l'évolution de l'utilisateur et de lui proposer suivant les pages atteintes, des sous menus permettant de réaliser des actions complémentaires.

Prenons un exemple simple pour illustrer l'idée:

On aurait voulu qu'en fin de recherche, et seulement à ce moment, lorsque l'on arrive sur le formulaire de soumission de la demande de prêt, un menu apparaissent proposant, en plus de la soumission classique, d'envoyer le formulaire au logiciel de traitement des demandes. Ainsi, l'étape de l'envoie de mail manuel aurait disparu. Mais, on s'est heurté à la limitation du HTML, même avec les extensions permises par le JavaScript dans le navigateur de Netscape.

On s’est alors orienté vers une autre solution : récupérer à la volée le contenu d’une page HTML, la parser, l’analyser et en retirer les informations nécessaires à l’établissement d’un prêt. On a donc construit deux frames, une proposant l’affichage du site de recherche et l’autre proposant un bouton sur lequel il suffisait de clicker lorsque la description de l’ouvrage se trouvait dans la première frame. Ce mécanisme se découpe en deux phases. La première consiste à épurer la page HTML en éliminants les tags HTML. A l’aide de PHP3 et de ses expressions régulières, nous avons réussi à ne récupérer que les données intéressantes de la page. La seconde phase, consiste simplement à récupérer les données. Les pages HTML affichant le résultat d’une recherche d’ouvrage est toujours la même pour un site donné, on a donc stocké dans la base les mots clefs et la position des informations que l’on voulait mémoriser.

Cette solution est elle aussi partie au panier, car ayant développé cette technique en local sur un ordinateur personnel, on ne sait pas rendu compte qu’elle ne fonctionnait pas au sein d’un navigateur connecté à Internet. En effet, les navigateurs modernes ne permettent pas de récupérer des informations d’une frame sur l’autre, si les frames ne proviennent pas du même domaine Internet. Cette sécurité a été mise en place à cause de la vulnérabilité due au Frame-Spoofing par la technique du Across Frame, où l’on fait ce que je souhaitais : échanger des données au travers de frames. L’information sur cette limitation ne fut pas simple à trouvé, mais nous avons trouve tout de même quelques explications claires de la part de Microsoft et de Netscape.

La dernière idée que l’on ait eu, et de faire passer toutes les pages de recherche par un proxy, qui permettrait ainsi d’obtenir le même nom de domaine pour toutes les pages. Mais, une fois encore cette solution n’était pas réalisable. On a réussi, a mettre en place un proxy en PHP3, permettant de rendre transparent le transfert des pages HTML classiques, des pages appelées par des liens HREF, ou constituant des frames, mais il était impossible de pouvoir faire passer des arguments aux modules CGI et de récupérer des pages provenant de ces modules.

On est donc revenu, à une solution beaucoup moins spectaculaire : proposer un formulaire à remplir en fin de recherche.

Nous avons testé PHP3 sous Linux avec Apache, mais aussi sous Windows NT avec IIS, oui oui ça marche, pas trop mal d'ailleurs.

Nous avons rencontrés quelques problèmes :

L'application d'une fonction de traitement de chaîne sur un champ Blob réalise une espèce de "segmentation fault" de débordement mémoire.

Le remplacement de chaîne à l’aide de la fonction str_replace ne marche pas très bien, bloquant le module php3, ou réalisant un débordement mémoire négatif.

Cependant, il est à noté que les performances ne sont pas mauvaises.

Et d’autres problèmes certainement dus à une version Bêta de la base MySQL plus qu'au module PHP3.

Les types de champs dans les tables ne sont pas très bien remis à jour, il semble que la structure décrivant les champs soit un peu défectueuse. En effet, si certain champ de certain type se trouve à côté, le système peut ne pas marché. La base fonctionne correctement son client réagit de façon valide, mais la connexion à la base à travers PHP3 ne donne pas les résultats escomptés. Une simple réorganisation des champs dans le descriptif de la création de la table permet de résoudre le problème.

Afin, d'utiliser le maximum de fonctionnalité de PHP3 ainsi que des possibilité d'HTML et du protocole HTTP, nous avons essayer ne pas nous restreindre à une seule technique, mais d'aborder plusieurs vision du même problème quand cela était possible.

La récupération des données à partir d'une base a été réalisée de trois manière différentes :

Une classe dans le cas d'une sélection ne renvoyant qu'un seul n-uplet, cela permet de placer le résultat dans un objet où l'on manipule les champs à l'aide d'une indirection (mysql_fetch_object).

Un tableau pour récupérer, puis parcourir tous les résultats de la requête (mysql_fetch_array).

Une ligne pour accéder facilement, par leur nom, à tous les champs d’une requête dont le résultat est unique (mysql_fetch_row).

On a utilisé les fonctions de manipulation de chaînes, ainsi que les fonctions d’extraction à partir d’expressions régulières.

Nous avons utilisé les deux modes de transmission d'information lors d'une requête HTTP, la méthode POST et la méthode GET. La méthode POST surtout utilisé dans la soumission de formulaire. Et la méthode GET, utilisé pour rajouter de la sémantique à une URL, en particulier lors de la construction de lien hypertexte.

Le langage HTML, maintenant bien établi semble être de plus en plus remplacé par le XML, aussi dans l’industrie que dans les applications shareware. L’apport de nouvelles fonctionnalités et balises de la norme 4.0 apporte, néanmoins, un réel complément et une réelle amélioration du code. Cependant, cette nouvelle norme est encore peu supportée, et ne permet pas d’être totalement employée.

On a pu constater au cours de ce projet, puisque l’on a fait valider l’application par des utilisateurs, que systématiquement ils voulaient changer l’état des boutons radio en cliquant sur le texte attaché au bouton. Ce n’est pas encore possible, car il n’y a pas de liaison sémantique entre le bouton et son libellé, mais la nome 4.0 propose une solution à l’aide des balies <LABEL> pour attacher le libellé au bouton et ainsi permettre son interaction.

Chaque navigateurs, enfin Netscape et Internet-explorer, possèdent chacun une méthode propre pour atteindre les Layers. La portabilité est alors réduite au néant, il faut absolument écrire deux codes et faire des tests pour savoir dans quel navigateur la page est exécutée.

La multiplication des layers sur une même page provoque dans certains cas des arrêt brutal du navigateur, c’est assez dommage.

Cette nouvelle façon de penser la page HTML, en se concentrant sur l’organisation du document et en déplaçant tout ce qui présentation dans une partie indépendante, nous a vite apparu comme une excellente solution. En effet dans le cadre du mélange du code HTML avec un code de scripting, cela permet de produire un code plus lisible, où les balises de présentation sont absentes. Le code est déjà suffisamment complexe à lire, pour que cet allégement soit réellement un plus. De plus, on peut voir ici, un autre avantage dans le cadre d’un développement important, il est vraisemblable qu’un graphiste sera dans l’équipe. Il pourra se concentrer sur sa charte graphique, et n’aura pas a manipuler, le code complexe produite par le développeur des scripts. On évitera ainsi les erreurs dues aux mauvaises manipulations.

Si les CSS permettent de changer l'aspect des pages sans modifier leur contenu et permettent de posséder plusieurs présentations d'un même site, et que les script serveur permettent de modifier le contenu des pages sans se soucier des présentations, on arrive alors à l'idée essentielle de la page HTML : être l'organisateur logique des données, sans se soucier de la présentation et en ayant un texte dynamique.

Néanmoins, il est clair que toutes les balises des CSS ne sont pas encore totalement supportées par tous les navigateurs, et que leurs affichages présentent parfois des dysfonctionnements notables.

Lorsque l'on consulte en local une page récupérée, où les éléments de mises en formes doivent être importé dans la page à l'aide d'un include , cela force le navigateur à tenter une connexion réseau. Outre un ralentissement de l'affichage de la page due à la tentative de connexion réseau, la page s'affiche de façon brute où n'ayant pas une présentation très agréable. Certaine page semblent avoir trouvée une parade, et en plus de l'importation de la page de style, continue à placer des Tags de configurations classiques.

On pourrait imaginer que le browser sauvegarderait la page de style correspondante avec la page HTML.

On a pu constater une mauvaise interprétation et une interférence des interprétation des CSS et des formulaires. Lorsqu'un formatage de texte CSS s'intercale dans un formulaire, le formulaire est comme coupé en deux. Le navigateur semble perdre le tag de fin de formulaire et les composants situés après l’appel du CSS sont erronés.

Le navigateur Netscape présente quelque difficulté à réafficher correctement une page formatée à l’aide de CSS, lorsque cette page vient d’être redimensionnée au sein du navigateur. L’affichage est complètement décalé. Mais, l’on a cependant trouvé une parade, en forçant un nouvel affichage lors d’un redimensionnement grâce à la gestion des événement de JAVASCRIPT.

La possibilité d’associer ce projet Internet au projet IHM, nous a permis de réaliser un projet complet. Ce fut très intéressant et très formateur de pouvoir se placer sur ce projets suivant plusieurs points de vues. Cela nous a permis de réaliser un projet complet, ayant une double approche d’une part coller à l’utilisateur et à ses besoins, aspect que l’on néglige parfois, et d’autre part mettre en œuvre toute la partie fonctionnelle de connexion de bases de données à l’aide d’outils nouveaux et pas toujours simples à manipuler. Cela nous a permis de mieux cerner les problèmes que peuvent rencontrer les équipes de développements qui travailleraient chacune sur une partie.

De plus, la mise en œuvre des technologies émergeantes du Web et des problèmes actuels de support de ces technologies nous a permis de bien comprendre la révolution qu’apporte ces technologies qui changent radicalement le visage du Web.