Brevet FR2892836A1 — publié le 20070504

PROCEDE ET DISPOSITIF DE TRAITEMENT D'UN EVENEMENT DETECTE AU NIVEAU DE L'INTERFACE D'UN NAVIGATEUR 10 La présente invention concerne un procédé et un dispositif de traitement d'information. Elle s'applique, en particulier, au traitement d'événements entre un client Web, par exemple un navigateur, et un serveur en utilisant des technologies standard du web, le protocole http (acronyme de Hyper Text Transfer Protocol pour protocole de transfer hyper texte), le client supportant le DOM, niveau 2 (DOM étant l'acronyme de Document Object 15 Model pour modèle d'objet de document). Le DOM est, pour les navigateurs, une représentation objet interne permettant à un script, comme Javascript (marque déposée), d'interagir avec la représentation mémoire du code HTML (acronyme de HyperText Markup Language pour langage avec liens hypertextes), et ainsi de modifier dynamiquement la page, le serveur Web permettant l'exécution de script, ainsi que la modélisation par objets 20 d'un site Internet. On désigne par événement , l'intervention d'un utilisateur sur l'interface graphique d'un logiciel de navigation ou navigateur ou toute autre action asynchrone au programme comme l'arrivée de données ou la fin d'un chronomètre ou timer . Par exemple, cette action est crée par le mouvement de la souris, l'appui sur l'un des boutons de la souris ou 25 l'action sur une touche du clavier. L'application du réseau Internet appelée web fonctionne sur la base d'un client ou navigateur, d'un serveur hébergeant le contenu à fournir au client et d'un réseau permettant la communication entre le client et le serveur. Les protocoles mis en jeu dans le cadre de l'échange d'informations entre le client et 30 le serveur sont notamment le protocole http. Ce dernier ne permet pas de traiter un système événementiel complexe. La capacité de ce protocole au traitement des événements se résume en une requête GET ou POST qui appelle une nouvelle page à être charger sur le client en passant un ensemble de couple champ / valeur. Ce support très simple de traitement des événements clients ne satisfait pas la réalisation d'applications complexes et 35 hautement Interactives. Deux obstacles majeurs nuisent au bon fonctionnement de telles applications, premièrement le rechargement complet d'une page à chaque événement provoque un désagrément graphique pour l'utilisateur et un comportement de l'application non-conforme aux standards des applications usuelles, d'autre part, il est impossible de traiter par ce système des évènements très rapide comme le déplacement de la souris. En effet il n'est pas concevable d'émettre une requête vers le serveur pour chaque mouvement de la souris. La présente invention vise à remédier à ces inconvénients. A cet effet, la présente invention s'appui sur une représentation du contenu des pages de site par des objets, comme exposé dans le document FR 2797336, du même inventeur que la présente invention, quant à sa possibilité de modéliser un site Internet comme un ensemble d'objet. Ce document propose une extension sémantique de la structure DOM des navigateurs. La présente invention vise à obvier à ces inconvénients ou impossibilités en proposant un nouveau système de gestion événementiel entre un client et un serveur en utilisant les technologies standard du web (Protocole http, Client supportant le DOM niveau 2 et le javascript, serveur Web permettant l'exécution de script), ainsi que la modélisation de site Internet exposée dans le document FR 2797336. Cette technologie met en oeuvre des éléments représentatifs des contenus des pages et de la structure des sites Web dans des bases de données situées sur un serveur central, lesdits éléments représentatifs étant constitués : d'objets contenus dans une base de données, un objet étant une entité autonome encapsulant des fonctions pour générer un code informatique interprétable par une application de navigation cliente, - d'attributs "desdits objets, lesdits attributs étant des paramètres modifiables pour constituer l'interface de l'objet vis à vis de l'utilisateur des applications clientes, - de données de structure définissant la manière dont les objets sont positionnés dans une page ainsi que la structure des différentes pages de sites entre elles. Chaque propriétaire de site peut modifier, via le réseau Internet, le comportement de ces objets en agissant sur leurs attributs au travers d'un gestionnaire d'objets. Il peut aussi agencer, via le réseau Internet, ces objets librement dans au moins une page et agencer les pages entre elles en agissant sur la structure au travers d'un éditeur. La consultation par un internaute du site déclenche l'activation, sur le serveur central, d'une procédure d'élaboration de pages dynamiques par un moteur d'application, à partir des informations contenues dans les bases de données de structure et d'objets, les pages dynamiques étant ensuite interprétées par un serveur HTTP et transmises sous forme de code HTML à l'application cliente. A cet effet, la présente invention vise, selon un premier aspect, un procédé de traitement d'information, caractérisé en ce qu'il comporte : -une étape de détection d'un événement au niveau de l'interface d'un navigateur mis en oeuvre sur un terminal client, - pour au moins une partie des événements détectés, une étape de gestion de cet événement, symétriquement, d'une part, par un processus client et, d'autre part, par un processus serveur asynchrone au processus client. La mise en oeuvre de la présente invention autorise des temps de réponses de l'application instantané dans la mesure où le traitement du serveur n'entraîne pas de modifications dans le contenu de l'interface graphique. II résulte de la mise en oeuvre de la présente invention, que la capture des événements se fait relativement aux objets, par exemple les objets définis dans le document FR 2797336, et que l'action qui peut résulter du traitement par le serveur de cet événement agit sur le rendu de ce même type d'objet ou autre actions de traitement. Selon des caractéristiques particulières, le traitement de chaque événement par le serveur n'entraîne pas le rechargement d'une page en cours d'affichage par le navigateur, sauf si le rechargement est explicitement requis par le terminal client. Grâce à ces dispositions, la gestion de l'événement par le serveur ne nuit pas à l'interactivité de l'application cliente. Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte une étape de traitement, dans le terminal client, de tout événement détecté pour déclencher soit une action directe, action ne nécessitant pas traitement de la part du serveur, sur un objet de l'interface client, soit la mémorisation de données représentatives de l'événement, dans une pile d'événements simples, soit la mémorisation de données représentatives de l'événement, dans une pile d'événements complexes. Les événements complexes sont des événements qui comportent des informations complémentaires à l'événement lui-même. Par exemple, l'événement `onmoumouve' lorsque la souris bouge, est un événement simple, mais `onmousmouve(x,y)' avec x et y les coordonnées de la souris au moment de l'événement, est un événement complexe. Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte, pour les événements mémorisés dans la pile d'événements simples, une étape de transmission au serveur. Selon des caractéristiques particulières, l'étape de transmission est effectuée par l'intermédiaire d'une requête http simple de type GET. Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte, pour les événements mémorisés dans la pile d'événements complexes, une étape de sérialisation des données représentatives de l'événement complexe et une étape de transmission au serveur des données sérialisées. Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte, pour les événements transmis au serveur, une étape de stockage, par le serveur, dans au moins une base de données associée aux piles. Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci- dessus comporte, une étape de génération de requête de traitement des événements stockés dans chaque base de données, au travers d'un gestionnaire d'événements. Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte, au niveau du gestionnaire d'événements, une étape de génération dynamique d'un script client et une étape de transmission, par le serveur, dudit script client au terminal client. Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte une étape d'action, dans le terminal client, du script client sur des objets clients pour en modifier le rendu. Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-15 dessus comporte une étape de gestion des quatre types d'événements suivants : i. client û client, action directe d'un événement sur un objet client sur autre objet client ou lui-même, ii. client - serveur synchrone simple, événement standard du DOM n'impliquant pas d'autres informations que l'identifiant objet récepteur et le nom de 20 l'événement, nécessitant un traitement serveur dont le résultat modifie le rendu graphique de l'interface cliente, iii. client û serveur synchrone complexe, événement non standard du DOM ou nécessitent plus d'informations que pour le point ii et iv. client û client synchrone I client û serveur asynchrone complexe, événement 25 standard ou non du DOM ayant à la fois une action directe sur l'interface cliente et un traitement serveur dont le résultat n'interfère pas avec l'action cliente û cliente. D'autres avantages, buts et caractéristiques de la présente invention ressortiront de la description qui va suivre, faite, dans un but explicatif et nullement limitatif en regard du 30 dessin annexé, dans lequel la figure 1 représente le schéma fonctionnel de l'invention. On rappelle que l'on désigne par événement , l'intervention d'un utilisateur sur l'interface graphique d'un logiciel de navigation ou navigateur. Par exemple, cette action est crée par le mouvement de la souris, l'appui sur l'un des boutons de la souris ou l'action sur une touche du clavier ou toute autre action asynchrone au programme comme l'arrivée de 35 données ou la fin d'un limer'. Le procédé de traitement d'information objet de la présente invention comporte : - une étape de détection d'un événement au niveau de l'interface d'un navigateur mis en oeuvre sur un terminal client, - pour au moins une partie des événements détectés, une étape de gestion de cet événement, symétriquement, d'une part, par un processus client et, d'autre part, par un processus serveur asynchrone au processus client. Ainsi, l'application peut répondre instantanément dans la mesure où le traitement du serveur n'entraîne pas de modifications dans le contenu de l'interface graphique. Il résulte de la mise en oeuvre de la présente invention, que la capture des événements se fait relativement aux objets, par exemple définis dans le document FR 2797336, et que l'action qui peut résulter du traitement par le serveur de cet événement agit sur le rendu de ce même type d'objet ou autre actions de traitement. Préférentiellement, le traitement de chaque événement par le serveur n'entraîne pas le rechargement d'une page en cours d'affichage par le navigateur, sauf si le rechargement est explicitement requis par le terminal client. La gestion de l'événement par le serveur ne nuit donc pas à l'interactivité de l'application cliente. On observe, en figure 1, que trois couches sont mises en oeuvre. Ces couches sont le client Cl, le réseau Internet C2 et le serveur C3. L'événement 11 est capté sur une interface graphique du client et est géré par la logique interne de cette interface graphique pour être ensuite intercepté par un dispatcher 12 de modélisation objet client qui décide quelles sont les actions à mener pour cet événement. Le dispatcher 12 effectue une étape de traitement, dans le terminal client, de tout événement détecté pour déclencher soit une action directe, action ne nécessitant pas de traitement de la part du serveur, sur un objet de l'interface client, soit la mémorisation de données représentatives de l'événement, dans une pile d'événements simples, soit la mémorisation de données représentatives de l'événement, dans une pile d'événements complexes. Les événements complexes sont des événements qui comportent des informations complémentaires à l'événement lui-même. Par exemple, l'événement 'onmoumouve' lorsque la souris bouge, est un événement simple, mais 'onmousmouve(x,y)' avec x et y les coordonnées de la souris au moment de l'événement, est un événement complexe. Plusieurs cas de figure sont possibles et sont déterminés en amont par un compilateur qui analyse le code programme et génère les éléments de programmes nécessaires et, en particulier indique le cas dans lequel on se trouve. Dans un premier cas de figure, l'action, ou l'événement, n'a pas à être traitée par le serveur et n'a d'action que sur le client, une action 15 client - client est alors émise et agit sur un autre objet de la page affichée comportant les objets 25. Dans un deuxième cas de figure, l'action est purement synchrone au résultat du serveur et ne nécessite pas d'argument supplémentaire que l'événement lui-même et que l'objet sur lequel il a été intercepté. Cet événement est alors mis dans une pile FIFO (acronyme de First ln First Out pour premier entré premier sorti) des événements simples 13. A intervalle de temps régulier, le navigateur scrute cette pile interne afin de transmettre les événements au serveur s'il y en a dans la pile. La transmission des événements au serveur ainsi que de l'identifiant objet référent se fait grâce à la capacité des navigateurs à exécuter plusieurs requêtes http dans la même instance d'un navigateur. Le procédé utilisé pour générer cette requête alors que la page est complètement chargé peut être multiple. II peut être, par exemple, initié dans une Frame (ou trame) (nouvelle instance de chargement d'une page dans le navigateur) ou par des techniques autre comme par exemple celle connue sous le nom de remote scripting . On effectue donc une requête de type GET HTTP dans laquelle on transmet le contenu de la pile 13 qui contient les événements à transmettre. On rappelle qu'une requête HTTP est une requête selon le protocole HTTP, le protocole de base des échanges de données entre un client web et un serveur web, par exemple la version de ce protocole HTTP vl.0 (RFC 1945) v.1.1 (RFC 2068). On l'observe, par exemple, dans les adresses électroniques, communément appelées URL , acronyme de Uniform Resource Locator pour localiseur de ressources uniforme, par l'en-tête http:// . On précise qu'une requête simple est une requête de type GET suivie de l'uri (l'uri est une sous partie de l'url, celle qui fait référence au document) c'est-à-dire '/ ? ' ce qui signifie que l'on passe les données directement dans les informations de requête du document ce qui limite la quantité de données transmissible (256 caractères selon les spécifications des uri ), contrairement à une requête de type POST qui permet de passe des données en quantité arbitraire. Un script serveur transfert les données de la requête dans une base de données 17 du serveur associée à une pile d'événement simples 19, consécutivement, un générateur de requête 24 commande le traitement de l'événement par le gestionnaire du serveur 21. Le gestionnaire d'événements 21 du serveur dépile les événements. Le processeur de traitement exécute le script associé à l'événement. Le résultat est la génération dynamique d'un script client effectuant des actions sur les objets instanciés sur le client. Ainsi, le procédé objet de la présente invention comporte, dans des modes de réalisation exemplaires, une étape de génération de requête de traitement des événements stockés dans chaque dite base de données, au travers d'un gestionnaire d'événements. Le gestionnaire d'événements effectue une étape de génération dynamique d'un script client, une étape de transmission de ce script client au terminal client, étant effectuée par le serveur. II s'en suit une étape d'action, dans le terminal client, du script client sur des objets clients pour en modifier le rendu. Dans un troisième cas de figure, l'action est synchrone avec le traitement sur le serveur et nécessite des paramètres additionnels à l'identifiant objet et au nom de l'événement, ou n'est pas un événement standard supporté par le DOM, il s'agit alors d'un événement dit complexe . On rappelle que les événements complexes sont des événements qui comportent des informations complémentaires à l'événement lui-même. Par exemple, l'événement 'onmoumouve' lorsque la souris bouge, est un événement simple, mais 'onmousmouve(x,y)' avec x et y les coordonnées de la souris au moment de l'événement, est un événement complexe. Cet événement est matérialisé, coté client, par un objet Java Script contenant un nombre de bases d'informations qui sont l'Identifiant Objet, le type d'événement, les coordonnées (X,Y) de l'objet et un champ data supplémentaire contenant une quantité arbitraire de couple (étiquette, valeur) représentant les paramètres spécifiques à cet événement. Dans ce cas, le dispatcher d'événement 12 stocke l'objet événement dans la pile FIFO des événements complexes 14. A intervalle de temps régulier, le navigateur scrute cette pile interne 14 afin de transmettre les événements au serveur, s'il y en a dans la pile. La transmission des événements au serveur ne peut pas, dans ce cas, être une simple requête http. En effet le protocole http ne peut transmettre des objets java script directement au serveur. Un serialisateur 16 transforme alors les objets de la pile 14 en un ensemble de données transmissibles par http. La sérialisation effectuée et le stockage de l'événement dans une base de données 18 du serveur associée à une pile 20 d'événements complexes conservée dans le serveur, le générateur de requête 24 commande le traitement de l'événement par un gestionnaire d'événement 21 du serveur. Le gestionnaire d'événements 21 du serveur dépile les événements. Le processeur de traitement 22 exécute le script associé à l'événement. Le résultat est la génération dynamique d'un script 23 client effectuant des actions sur les objets instanciés sur le terminal client. Dans un quatrième cas de figure, l'action est synchrone au client et asynchrone au traitement serveur. Dans ce cas, le dispatcher génère parallèlement un événement de type direct destiné à être traité par le serveur. La condition pour un bon fonctionnement du système est que le résultat du traitement du serveur n'agisse pas en contradiction avec l'événement Client-Client. Ainsi, la mise en oeuvre de la présente invention permet de gérer les quatre types d'événements suivants : i. client û client, action directe d'un événement sur un objet client sur autre objet client ou lui-même, ii. client -serveur synchrone simple, événement standard du DOM n'impliquant pas d'autres informations que l'identifiant objet récepteur et le nom de l'événement, nécessitant un traitement serveur dont le résultat modifie le rendu graphique de l'interface cliente, iii. client û serveur synchrone complexe, événement non standard du DOM ou nécessitant plus d'informations que pour le point ii et iv. client û client synchrone / client û serveur asynchrone complexe, événement standard ou non du DOM ayant à la fois une action directe sur l'interface cliente et un traitement serveur dont le résultat n'interfère pas avec l'action cliente û cliente. REVENDICATIONS 1 - Procédé de traitement d'information, caractérisé en ce qu'il comporte : - une étape de détection d'un événement (11) au niveau de l'interface d'un navigateur mis en 5 oeuvre sur un terminal client (Cl), - pour au moins une partie des événements détectés, une étape de gestion de cet événement, symétriquement, d'une part, par un processus client et, d'autre part, par un processus serveur (C3) asynchrone au processus client. 2 û Procédé selon la revendication 1, caractérisé en ce que le traitement de chaque 10 événement (11) par le serveur (C3) n'entraîne pas le rechargement d'une page en cours d'affichage par le navigateur, sauf si le rechargement est explicitement requis par le terminal client. 3 û Procédé selon l'une quelconque des revendications 1 ou 2, caractérisé en ce qu'il comporte une étape de traitement, dans le terminal client, de tout événement (11) détecté 15 pour déclencher soit une action directe, action ne nécessitant pas traitement de la part du serveur (C3), sur un objet de l'interface client, soit la mémorisation de données représentatives de l'événement, dans une pile d'événements simples (13), soit la mémorisation de données représentatives de l'événement, dans une pile d'événements 1 complexes (14). 20 4 û Procédé selon la revendication 3, caractérisé en ce qu'il comporte, pour les événements (11) mémorisés dans la pile d'événements simples (13), une étape de transmission au serveur (C3). û Procédé selon la revendication 4, caractérisé en ce que l'étape de transmission est effectuée par l'intermédiaire d'une requête http simple de type GET. 25 6 û Procédé selon l'une quelconque des revendications 3 à 5, caractérisé en ce qu'il comporte, pour les événements (11) mémorisés dans la pile d'événements complexes (14), une étape de sérialisation (16) des données représentatives de l'événement complexe et une étape de transmission au serveur (C3) des données sérialisées. 7 û Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce qu'il 30 comporte, pour les événements (11) transmis au serveur (C3), une étape de stockage, par le serveur, dans au moins une base de données (17, 18) associée aux piles (19, 20). 8 û Procédé selon la revendication 7, caractérisé en ce qu'il comporte, une étape de génération de requête (24) de traitement des événements (11) stockés dans chaque dite base de données (17, 18), au travers d'un gestionnaire d'événements (21). 35 9 û Procédé selon la revendication 8, caractérisé en ce qu'il comporte, au niveau du gestionnaire d'événements (21), une étape de génération dynamique d'un script client (23) et une étape de transmission, par le serveur (C3), dudit script client au terminal client (Cl).10 û Procédé selon la revendication 9, caractérisé en ce qu'il comporte une étape d'action, dans le terminal client (Cl), du script client (23) sur des objets clients (25) pour en modifier le rendu. 11 û Procédé selon l'une quelconque des revendications 1 à 10, caractérisé en ce qu'il 5 comporte une étape de gestion des quatre types d'événements (11) suivants : i. client (Cl) û client, action directe d'un événement sur un objet client sur autre objet client ou lui-même, ii. client û serveur (C3) synchrone simple, événement standard du DOM n'impliquant pas d'autres informations que l'identifiant objet récepteur et le nom 10 de l'événement, nécessitant un traitement serveur dont le résultat modifie le rendu graphique de l'interface cliente, iii. client û serveur synchrone complexe, événement non standard du DOM ou nécessitant plus d'informations que pour le point ii et iv. client û client synchrone / client û serveur asynchrone complexe, événement 15 standard ou non du DOM ayant à la fois une action directe sur l'interface cliente et un traitement serveur dont le résultat n'interfère pas avec l'action cliente û cliente.