Brevet FR2796479A1 — publié le 20010119

Création d'un document hypertexte en dépendance d'un autre dans un terminal client La présente invention concerne de manière générale la création de documents hypertextes, par exemple la modification de ceux-ci. Elle est dirigée plus particulièrement vers la création d'une image contenue dans un deuxième documrent hypertexte et à visualiser dans un terminal client, appelé ci-après "client", en dépendance d'une image initiale contenue dans un premier document hypertexte transmis par un serveur au client à travers un réseau de transmission à débit élevé, tel que le réseau Internet. Le réseau Internet est basé sur une structure client-serveur qui utilise le protocole de communication HTTP (Hypertext Transfer Protocol). Si un client demande au serveur un document hypertexte, dit également document Web, le client se connecte au réseau Internet, le document est transféré du serveur au client et le client se déconnecte du réseau. Les documents hypertextes sont le plus souvent exprimés dans le langage HTML (Hypertext Markup Language). Des balises de ce langage définissent la structure logique d'un document hypertexte. Les documents hypertextes sont identifiés par un système d'adressage. Chaque document hypertexte, ainsi que les éléments intégrés au document, sont identifiés par une adresse respective URL (Uniform Ressource Locator). Le document hypertexte peut exister statiquement sur le serveur ou peut être créé dynamiquement dans le serveur au moment de la demande du document par le client. Cette technique est transparente pour le client. Les types de document qu'un client charge et la façon dont le client interagit avec un document dépendent de la fonctionnalité des programmes utilisés dans ?e navigateur installé dans le client. Les applications Web sont partagées en deux catégories selon leur lieu d'exécution les applications du côté serveur et les applications du côté client. Les applications dans le serveur sont responsables de la création et la mise â disposition des données. Les applications dans le client ont pour tâches la visualisation des données et la gestion des interactions avec l'utilisateur. Le serveur SER a la possibilité de modifier un document existant avant de l'envoyer au client qui l'a demandé. Le serveur consulte le document, cherche les instructions intégrées au document et les remplace par des objets demandés dans des instructions par le client. Les objets sont par exemple des lignes de texte, des images ou d'autres objets dynamiques interactifs qui sont créés au moment de la consultation du document. Cette technique est transparente pour l'utilisateur du terminal client qui ne visualise que le résultat d'une telle modification. Selon une première technique SSI (Server Side Includes), des morceaux d'un premier document sont ajoutés dans un deuxième document. Ces morceaux peuvent être créés par un programme externe. Cette technique facilite la maintenance d'un grand nombre de documents qui sont disponibles sur un serveur HTTP. Le nombre d'instructions est bridé, mais ces instructions supportent les appels de ligne de commandes du système d'exploitation du serveur. Une deuxième technique est basée sur une plate- forme de logiciel, côté serveur, l'ASP (Active Server Pages), qui utilise des instructions intégrées dans un premier document HTML et également des petits programmes, des scripts exprimés par exemple dans le langage de programmation VisualBasicScript (marque déposée). Les scripts sont interprétés par, un interpréteur qui est intégré dans le serveur. Ce type d'application Web dépend du système d'exploitation du serveur et est développé pour des accès à au moins une base de données. Le client réceptionne alors un deuxième document HTML standard issu de modification du premier document, voire d'une substitution du premier document. Ces techniques ont pour inconvénient d'accroître les tâches du serveur, si bien que l'analyse d'un document dans le serveur baisse la puissance du serveur. Du côté du client CL, le navigateur - une interface graphique dans le terminal pour visualiser un document hypertexte - interprète les balises HTML et effectue la présentation graphique. Les documents hypertextes peuvent contenir des images et d'autres éléments non-textuels. Si le navigateur trouve un tel élément dans un document hypertexte, il charge automatiquement les données correspondantes en faisant appel au protocole de communication HTTP. La présentation des différents types de médias tels que textes, images, vidéo, sons, etc., demande des logiciels spécifiques. Le type de média est identifié par le format standard MIME (Multipurpose Internet Mail Extensions) contenant le type de média et l'extension du fichier : type/extension. Le serveur SER ajoute, dans l'en-tête d'une réponse à une demande HTTP, la spécification du type du document envoyé. Le navigateur reconnaît le type de document et sélectionne dans un tableau la bonne présentation du document. Les types de médias de base sont par exemple des commandes text/html, ou bien des images graphiques image/gif affichables directement par le navigateur. Pour d'autres types, le navigateur utilise des programmes auxiliaires en correspondance avec le type de document. Le navigateur utilise un modèle d'objet pour visualiser des éléments d'un document hypertexte. Tous les éléments affichés sur l'écran du terminal client sont traités comme des objets. Un tel objet a des attributs, soit avec des valeurs définies dans le code HTML, soit avec des valeurs par défaut s'il n'y a rien de préciser. Les valeurs correspondent à des attributs au moment de la visualisation des documents HTML. Ces valeurs pourraient être modifiées à l'aide d'un script, en appliquant une autre valeur à l'attribut. Mais certains attributs sont en lecture seule et le script est incapable de modifier les valeurs de ces attributs. Par exemple, la balise HTML d'inclusion d'image contient toujours l'attribut SRC dont la valeur est constituée par l'adresse URL du fichier contenant une image mémorisée dans le serveur. La balise peut contenir les attributs facultatifs suivants - NAME dont la valeur est un nom identifiant l'image dans le modèle d'objet du document hypertexte - ALT dont la valeur est un nom alternatif affiché à la place de l'image si notamment la source n'est pas disponible ; - HEIGHT dont la valeur en pixels indique la hauteur de l'image sur l'écran ; - WIDTH dont la valeur en pixels indique la largeur de l'image sur l'écran. Si la hauteur et la largeur de l'image sur l'écran ne sont pas précisées dans les attributs de la balise , le navigateur visualise l'image dans sa taille d'origine. En prenant d'autres valeurs pour la hauteur et la largeur imposées par le serveur, la taille de l'image à visualiser dans le client peut être augmentée ou diminuée. La zone de visualisation réservée à une image sur l'écran du terminal client est fixée en proportion par le serveur avant la visualisation du document hypertexte par le navigateur. Pour cette raison, les attributs de hauteur et largeur de l'image sont en lecture seule. Une modification des valeurs de ces deux attributs implique une mise à jour de la présentation graphique du reste du document par le serveur. Ainsi, selon la technique antérieure, une image en ligne qui apparaît automatiquement dans une fenêtre déterminée par le serveur sous la commande du navigateur dans le terminal client en réponse à un document hypertexte transmis depuis le serveur vers le client ne peut être directement modifiée en taille dans le terminal client, par exemple pour réaliser un zoom sur image. L'invention a pour objectif qu'un document hypertexte transmis par le serveur puisse être modifié dans le terminal client ce qui soulagera le serveur s'il devait procéder à une telle modification et ce qui augmente la rapidité d'exécution de la modification. En d'autres termes, l'invention vise à créer dans le terminal client une deuxième présentation graphique qui dépend d'une première présentation graphique qui est définie dans un premier document hypertexte initialement transmis par le serveur. Pour atteindre cet objectif, l'invention propose un procédé pour créer un deuxième document hypertexte en dépendance d'un premier document hypertexte fourni par un serveur relié à un terminal client à travers un réseau de transmission, caractérisé en ce qu'il comprend les étapes suivantes effectuées dans le terminal client après réception du premier document hypertexte et affichage de la présentation graphique correspondant à celui-ci - récupérer des données au moins de la présentation graphique du premier document hypertexte - déterminer la présentation graphique du deuxième document hypertexte en dépendance des données récupérées et de paramètres locaux ; - effacer le premier document hypertexte afin que la présentation graphique de celui-ci ne soit plus visible ; et - écrire le deuxième document hypertexte afin d'afficher la présentation graphique de celui-ci. Malgré l'impossibilité de lire et donc de modifier des attributs de taille de la présentation graphique, telle qu'image, du premier document hypertexte, comme on le verra dans la description détaillée, l'invention parvient à remplacer dans le terminal client le premier document hypertexte par un deuxième document hypertexte dont la présentation graphique dépend de celle du premier document. En pratique, l'étape d'effacer consiste à écraser le premier document hypertexte à l'aide d'un script écrit dans un troisième document hypertexte transmis par le serveur au terminal client. Comme il n'est pas possible d'écraser un document hypertexte contenant un script, l'invention fait appel à la notion de zones (FRAMES). Plus précisément, l'invention prévoit deux documents hypertextes dont les présentations graphiques sont des zones juxtaposées sur l'écran du terminal et réunis dans un document commun, afin que l'un des deux documents hypertextes contenant le script ne soit pas effacé, tandis que l'autre document est le premier document destiné à être remplacé par le deuxième document. Ainsi, selon des caractéristiques de l'invention, le premier document hypertexte peut avoir une présentation graphique qui est une zone incluse dans la présentation graphique d'une page hypertexte affichée dans le terminal client. En particulier, les paramètres locaux peuvent comprendre au moins une variable ayant une valeur sélectionnée localement dans le terminal client par un utilisateur, et ladite variable peut avoir sa valeur sélectionnée par au moins un bouton compris dans la présentation graphique d'un troisième document hypertexte qui est lié aux premier et deuxième documents hypertextes par au moins une fonction pour l'étape de déterminer, ladite fonction étant intégrée dans le troisième document. En général, plusieurs fonctions sont écrites dans le script contenu dans le troisième document. L'étape de déterminer peut comprendre par exemple une modification du contenu du premier document hypertexte. Avant l'étape de déterminer, le procédé comprend de préférence une étape d'appeler au moins une fonction avec lesdits paramètres locaux intégrée dans un troisième document hypertexte transmis avec le premier document hypertexte par le serveur, ladite fonction servant à l'étape de déterminer. Selon une réalisation préférée, la fonction d'appeler est un agrandissement ou une réduction d'image avec un rapport d'agrandissement ou de réduction comme paramètre local. D'autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description suivante de plusieurs réalisations préférées de l'invention en référence à la figure unique annexée correspondante 1 qui est un algorithme d'un procédé de création d'un document hypertexte selon l'invention dans un terminal client. Comme montré schématiquement dans la partie supérieure de la figure 1, un terminal client CL et un serveur SER sont reliés notamment à travers un réseau de transmission de données à débit élevé, le réseau Internet WWW auquel on se référera, ou bien un réseau Intranet. Les messages échangés entre le client et le serveur sont des requêtes selon le protocole HTTP (Hypertext Transfer Protocol). Une requête est une adresse URL (Universal Ressource Locator) spécifiant notamment, à la suite du nom de protocole HTTP, le nom du serveur et le nom d'un document (répertoire et page) à afficher dans le terminal client CL ou le nom d'une librairie de fonctions à traiter dans le serveur SER. Le terminal client est appelé dans la suite "client" CL pour désigner les ressources logicielles et matérielles dans le terminal. Le serveur et le client présentent les caractéristiques logicielles et matérielles déjà présentées dans le préambule de la description. En particulier, un navigateur (browser) dans le client sait interpréter le langage de description de document hypertexte (page) d'écran HTML afin d'afficher du texte ou de l'image dans des fenêtres du navigateur qui sont éventuellement enrichies d'éléments multimédias et qui sont généralement interactives au moyen de liens hypertextes insérés. Outre des logiciels spécifiques contribuant à présenter différents types de médias, le client CL supporte un langage de scripts, tel que le langage JavaScript (marque déposée), qui complète le langage HTML afin notamment d'animer des pages HTML et d'ouvrir des fenêtres. Les scripts d'une application Web exécutables dans le client sont soit intégrés directement dans le document hypertexte HTML dont une présentation graphique, telle qu'image, est par exemple à afficher, soit transmis séparément dans un autre document hypertexte lié à plusieurs documents hypertextes. Le navigateur lance un script soit lors du chargement du document hypertexte, soit après un événement ou une interaction définie dans le document hypertexte. Les événements, tels que des interactions de souris, sont directement appliqués à des balises HTML. Les scripts servent souvent à valider des données saisies dans un formulaire en tant que document hypertexte. Chaque élément d'un document hypertexte, ainsi que le navigateur lui-même, est traité comme un objet avec un certain nombre de propriétés. Avec des méthodes qui sont appliquées par le script et des fonctions supplémentaires fournies par le script, certaines propriétés, dites également attributs, des objets sont modifiables de manière à modifier la structure et la présentation d'un document Web de façon dynamique. Cette technique est basée sur le modèle d'objet de document DOM (Document Object Mode 1) . La fusion entre les langages de script et le modèle DOM, appelée le langage dynamique DHTML (Dynamic HTML), permet, grâce au traitement dynamique d'objets, la réalisation d'animations simples directement dans une page HTML. Le langage JavaScript utilise un modèle d'objet hiérarchique. Pour accéder à un objet, il faut parcourir la hiérarchie à partir du niveau où une fonction a été effectuée. En dessous de l'objet navigateur, on a l'objet fenêtre "WINDOW". L'objet fenêtre regroupe des objets "DOCUMENT", zones "FRAME", historique "HISTORY" et position "LOCATION". L'objet document englobe des objets tels qu'ancres "ANCHORS", "DOCUMENTS", zones "FRAMES", historique "HISTORY" et position "LOCATION". Un objet formulaire "FORM" peut contenir des objets du type bouton "BUTTON", groupe d'options "CHECKBOX", zone de texte modifiable "TEXTAREA", etc. Comme déjà dit dans le préambule de la description, un objet image "IMG" a des attributs "SRC", "NAME", "ALT", "HEIGHT" et "WIDTH". Les attributs de hauteur et largeur d'une présentation graphique, telle qu'image, sont en lecture seule et ne sont pas modifiables par un script dans le client. Dans ce contexte, l'invention vise à surmonter cet obstacle au changement de taille d'une première présentation graphique pour créer à partir de celle-ci une deuxième présentation graphique. En référence à la figure 1, il est supposé au début d'une session d'échange entre le client CL et le serveur SER, qu'à une étape EO le client CL a demandé un document hypertexte composite DC, par exemple en ayant rempli un champ ou sélectionné une option dans une liste dans une page d'accueil du serveur, puis en ayant déclenché l'envoi d'une demande HTTP vers le serveur SER en sollicitant un bouton de soumission SUBMIT. Le serveur établit alors une réponse HTTP contenant le document hypertexte DC en langage HTML et l'envoi au client CL. A réception de la réponse HTTP, la présentation graphique PG du document hypertexte DC, en tant que page HTML, est affichée immédiatement par le navigateur dans le client CL, à une étape El. Comme montré à la figure 1 à titre d'exemple, la présentation graphique PG du document composite DC est une image divisée en plusieurs zones (frames), ici aux nombres de trois une zone de fond ZB présentant par exemple des instructions, une zone ZI1 contenant une image, en l'occurrence une carte de France, et une zone de fonction ZF. Cette dernière comporte deux boutons de commande BP et BM pour "zoomer" sur l'image dans la zone ZI1, c'est-à-dire respectivement pour agrandir par zoom avant l'image et pour réduire par zoom arrière l'image, après avoir placé le curseur d'une souris du terminal client CL sur l'un respectif des boutons BP et BM. Les étapes du procédé suivantes E2 à E6 exécutées seulement dans le client CL ont trait seulement à une modification de la zone d'image ZI1. En effet, chacune des zones ZB, ZI1 et ZF est une présentation graphique d'un document hypertexte HTML respectif DB, D1, DF à part entière et donc ces zones ont des évolutions relativement indépendantes les unes des autres si aucun lien n'est prévu entre elles. En l'occurrence, la zone d'image ZI1 est modifiable bien que pendant cette modification d'image les deux autres zones ZB et ZF peuvent être conservées sans modification. Le document composite DC est ainsi un "parent" vis-à-vis de "fils" constitués par des document hypertextes dont les présentations graphiques ZB, ZI1 et ZF sont parfaitement délimitées entre elles. La fenêtre constituée par l'ensemble des zones est signalée par une balise en langage HTML dont les attributs "ROWS" et "COLS" indiquent les divisions horizontales et verticales en zones. Chaque zone est signalée par une balise respective constituant un "objet HTML" comprenant notamment l'adresse SRC du document hypertexte correspondant, le nom du document et des marges entre les limites de la zone et le document réellement à afficher. Dans l'exemple illustré, un lien "parent.affichage" existe entre la zone de fonction ZF et la zone d'image ZI1 afin d'agrandir ou de réduire l'image dans la zone ZI1, en local dans le client CL. Comme déjà dit, il n'est pas possible de modifier directement au niveau du client la taille, hauteur ou largeur, de l'image ZI1, puisque les attributs hauteur "HEIGHT" et largeur "WIDTH" du document hypertexte correspondant ne sont accessibles qu'en lecture seule dans le client CL. A l'étape E2, un script exprimé en langage JavaScript et intégré dans le document hypertexte DF est lancé en cliquant sur l'un des boutons de commande BP et BM contenus dans la zone de fonction ZF. Selon l'invention, les zones ZF et ZI1 constituent un ensemble de deux présentations graphiques de deux documents hypertextes DF et D1 signalés par une balise en langage HTML. Le script offre deux fonctionnalités qui sont sensibles respectivement aux boutons de commande BP et BM. Chaque fonctionnalité, lorsqu'elle est appelée, comprend des étapes analogues E3 à E6 présentées ci-après. A l'aide du script, toutes les valeurs des attributs du modèle d'objet du document hypertexte D1 relatif à la zone ZI1 peuvent être consultées, bien que ce modèle d'objet se rapporte à un autre document ne contenant pas le script mais simplement lié au document hypertexte DF contenant le script puisque les deux documents Dl et DF sont des parties d'un ensemble commun indiqué par une balise . La fonctionnalité du script liée au bouton BP ou BM ayant été appelée, le script récupère à l'étape E3 les données du document hypertexte D1, c'est-à-dire au moins les données relatives à la zone d'image ZI1, nécessaires pour créer ultérieurement un deuxième document hypertexte D2 dont la présentation graphique Z12 est réduite ou agrandie par rapport à l'image ZI1. Ces données sont combinées à des variables locales des fonctions appelées pour déterminer à l'étape E4 la nouvelle taille de la présentation graphique Z12, en l'occurrence celle de la carte de France, qui est une taille agrandie ou réduite selon que le bouton BP ou BM a été sollicité. En l'espèce, les données sont la taille, hauteur et largeur de la "première" image ZI1 définie dans le premier document Dl transmis par le serveur et chargé dans le client, ainsi que les caractéristiques graphiques selon le format d'encodage de l'image, par exemple le format GIF (Graphics Interchange Format). Ces données sont incluses notamment dans les valeurs des attributs SRC, HEIGHT et WIDTH de la balise correspondant au document hypertexte D1 de la première image ZI1. Par exemple, le premier document D1 correspond à la plus petite image à afficher inscrite dans une fenêtre d'écran de largeur W et hauteur H, si bien que des agrandissements d'image, ou zoom avant, peuvent être déduits en copiant chaque pixel de la plus petite image en fonction du pourcentage sélectionné par le bouton BP, puis dans des cycles suivants indifféremment par le bouton BP ou BM. Toutes les images issues de sollicitation des boutons BP et BM contiennent ainsi les pixels de l'image initiale ZII et peuvent être déduites chacune de la précédente. Au bas de la figure 1, une partie d'une deuxième image Z12 de taille (2W.2H) déduite de l'image ZI1 par un agrandissement de rapport 2 est inscrite dans la fenêtre W.H. A la fin de l'étape E4, le client contient en mémoire les caractéristiques graphiques de la deuxième image Z12 dont la taille peut être plus grande ou plus petite que la taille fixe W.H de la fenêtre d'affichage. Une deuxième balise d'inclusion d'image est construite sur la base de la deuxième image déterminée Z12, et le deuxième document hypertexte D2 est créé avec pour présentation graphique la deuxième image Z12 qui diffère en taille avec la présentation graphique ZI1 du premier document hypertexte D1. Le deuxième document hypertexte D2 étant établi, le premier document hypertexte D1 est alors effacé dans le client CL, par une commande d'écrasement "CLEAR" du script, à l'étape E5. Le deuxième document D2 est ensuite écrit à l'étape E6 dans l'ensemble de zone de fonction et de zone d'image, en substitution du premier document Dl, en utilisant la méthode "WRITELN" du script. Dans le deuxième document D2, les valeurs des attributs HEIGHT et WIDTH ont changé. L'utilisateur du terminal client fait apparaître la deuxième image, généralement agrandie par rapport à la première image, en faisant défiler celle-ci dans la fenêtre de zone d'image W.H au moyen de barres de défilement horizontale BH et vertical BV longeant la zone d'image. Après l'étape E6, l'utilisateur peut décider à l'étape E7 de choisir une autre modification, agrandissement ou réduction, en demandant l'exécution d'un autre cycle des étapes E1 à E6 débutant par une autre sollicitation de l'un des boutons BP et BM. Au cours de cet autre cycle, une troisième image déterminée à l'étape E4 est créée en fonction de l'image précédente, ladite deuxième image Z12, et ainsi de suite. Toutefois, après l'étape E6, l'utilisateur peut souhaiter retourner à la session d'échange en cours entre le client CL et le serveur SER, comme indiqué en E8. Le deuxième document hypertexte D2 créé aux étapes précédentes est un document HTML qui est susceptible d'être transmis dans une demande HTTP par le client vers le serveur. REVENDICATIONS 1 - Procédé pour créer un deuxième document hypertexte en dépendance d'un premier document hypertexte fourni par un serveur (SER) relié à un terminal client (CL) à travers un réseau de transmission (WWW), caractérisé en ce qu'il comprend les étapes suivantes effectuées dans le terminal client après réception (E1) du premier document hypertexte(D1) et affichage de la présentation graphique (ZI1) correspondant à celui-ci - récupérer (E3) des données au moins de la présentation graphique (ZI1) du premier document hypertexte (D1) ; - déterminer (E4) la présentation graphique (Z12) du deuxième document hypertexte (D2) en dépendance des données récupérées et de paramètres locaux (BP,BM) ; - effacer (E5) le premier document hypertexte (D1) afin que la présentation graphique (ZI1) de celui-ci ne soit plus visible ; et - écrire (E6) le deuxième document hypertexte (D2) afin d'afficher la présentation graphique (Z12) de celui-ci. 2 - Procédé conforme à la revendication 1, selon lequel le premier document hypertexte (Dl) a une présentation graphique (ZI1) qui est une zone incluse dans la présentation graphique d'une page hypertexte (DC) affichée dans le terminal client. 3 - Procédé conforme à la revendication 1 ou 2, selon lequel les paramètres locaux comprennent au moins une variable (BP, BM) ayant une valeur sélectionnée localement dans le terminal client (CL) par un utilisateur. 4 - Procédé conforme aux revendications 2 et 3, selon lequel ladite variable a sa valeur sélectionnée par au moins un bouton (BP, BM) compris dans la présentation graphique (ZF) d'un troisième document hypertexte (DF) qui est lié aux premier et deuxième documents hypertextes (D1, D2) par au moins une fonction pour l'étape de déterminer (E4), ladite fonction étant intégrée dans le troisième document. 5 - Procédé conforme à l'une quelconque des revendications 1 à 4, selon lequel l'étape de déterminer (E4) comprend une modification de la présentation graphique (ZI1) du premier document hypertexte (D1). 6 - Procédé conforme à l'une quelconque des revendications 1 à 4, comprenant avant l'étape de déterminer (E4), une étape d'appeler (E2) au moins une fonction avec lesdits paramètres locaux intégrée dans un troisième document hypertexte (DF) transmis avec le premier document hypertexte (Dl) par le serveur (SER), ladite fonction servant à l'étape de déterminer (E4). 7 - Procédé conforme à la revendication 6, selon lequel la fonction d'appeler est un agrandissement ou une réduction d'image avec un rapport d'agrandissement ou de réduction comme paramètre local.