FR2885242A1 - Creation d'applications personnalisables - Google Patents

Abstract

La présente invention concerne un procédé de création d'une application correspondant à un ensemble de composants, dont l'exécution fournit un résultat adapté en fonction des conditions d'utilisation de ladite application.Le procédé comprend la génération d'un ensemble de documents XML de type DOM comprenant la logique non générique de l'application, la logique générique étant associée à des classes java liées à certains éléments des DOM.Le procédé selon l'invention permet de façon tout à fait originale, aux utilisateurs, de modifier simplement l'application sans avoir besoin de recompiler l'ensemble des exécutables.

Description

CREATION D'APPLICATIONS PERSONNALISABLES

La présente invention se rapporte au domaine de la création d'applications informatiques, en particulier d'applications personnalisables.

La présente invention se rapporte plus particulièrement à un procédé pour créer des applications personnalisables dont l'affichage peut dépendre des conditions d'utilisation, de l'identité ou du profil de l'utilisateur.

Il est avantageux de personnaliser l'affichage des applications pour les différents utilisateurs. On peut par exemple désirer n'afficher qu'un premier contenu d'information pour un premier type de client, et afficher un second type d'information pour un second type de client. On peut également, pour un même contenu, vouloir faire varier l'affichage dudit contenu.

L'art antérieur avait déjà proposé une solution technique à ce problème de la personnalisation en proposant une architecture sous la forme d'une source d'informations structurées, telle qu'une base de données relationnelle ou XML, comprenant la définition et les données relatives aux informations de personnalisation, ainsi que les liens entre chaque type d'information (ex: profil, page, ...). Les différents composants applicatifs, par exemple de type java, permettent l'affichage des pages personnalisées par appel à une interface de programmation d'application (API), composée d'un ensemble de classes d'objets, qui encapsule l'accès à la source de données et la récupération des informations de personnalisation, lesquelles sont ensuite traitées et renvoyées aux composants applicatifs sous forme de résultat personnalisé. La figure 1 décrit une telle solution de l'art antérieur dans laquelle la personnalisation est réalisée par l'appel à des classes java contenant du code spécifique, à une source de données, par exemple de type base de données relationnelle. Cette base comprend des informations de personnalisation utilisées pour fournir un résultat personnalisé en fonction de l'utilisateur, A ou B. En fonctionnement, un composant applicatif par exemple un composant Web, appelle une classe Java à l'aide de paramètres associés à l'utilisateur A. Cette classe est éventuellement guidée par une classe Java ancêtre, qui encapsule la logique générique. La logique de la classe Java gère alors un ensemble de requêtes et de réponses de la part de la source de données contenant de l'information de personnalisation et traite cette information de façon à rendre un résultat personnalisé A. Il est important de comprendre que dans ce type de configuration, les programmes java spécifiques et génériques faisant référence à l'interface de programmation d'application sont compilés, et l'ajout ou la modification d'un nouvel attribut de personnalisation dans la base nécessite d'une part la mise à jour et la migration des informations existantes, mais également la modification et recompilation du code java de l'API. Dans ce cas, il convient également de modifier et de recompiler tous les programmes qui utilisent l'API.

Plus précisément, si l'on modifie la structure de la source de données, et qu l'on change les références entre les données, on doit également changer les classes Java contenant la logique non générique associée à ces informations pour prendre en compte les nouvelles information et donc de recompiler ces classes.

On comprend que cette contrainte constitue un inconvénient pour l'évolution de l'outil permettant de générer des applications personnalisables.

Cet inconvénient est résolu par le procédé et le programme d'ordinateur tel que revendiqué.

Selon l'invention, on fournit un procédé de création d'une application correspondant à un ensemble de composants, dont l'exécution fournit un résultat adapté en fonction des conditions d'utilisation de ladite application comprenant: une première étape préalable de création d'une application consistant à : Définir un premier ensemble de documents XML dont les n uds représentent lesdites conditions d'utilisation; Définir un second ensemble de documents XML dont les n uds représentent les composants de ladite application; chacun desdits premiers et second ensemble comprenant des documents XML comprenant un premier type de n ud associé à un exécutable et un second type de n ud définissant une référence à un document XML dudit premier et second ensemble; les documents du second ensemble comprenant un troisième type de n ud définissant une référence à un document XML du même second ensemble et représentant un composant de même type; Une seconde étape d'exécution de ladite application consistant à : lire à l'aide d'un interpréteur, un document du second ensemble pour l'interprétation de 20 35 l'ensemble de ses n uds et des n uds des documents référencés desdits premiers et second ensemble, l'interprétation de chaque n ud du premier type permettant les exécutions desdits exécutables associés; - Stocker, dans un contexte applicatif, les résultats desdites exécutions desdits exécutables; Renvoyer le contenu dudit contexte applicatif.

L'invention concerne également un programme d'ordinateur, éventuellement stocké sur un support de données, pour la mise en uvre du procédé selon l'invention.

Selon l'invention, l'ensemble de la logique spécifique qui était présente dans des classes Java compilées selon l'art antérieur est maintenant obtenue sous forme de DOM (Document Object Model) réalisant donc un programme de type XML.

On comprendra mieux l'invention à l'aide de la description, faite ciaprès à titre purement explicatif, d'un mode de réalisation de l'invention, en référence aux figures annexées: la figure 1 illustre le procédé et l'architecture de personnalisation selon l'art antérieur; la figure 2 illustre le procédé et l'architecture de personnalisation selon l'invention.

La figure 3 représente un exemple spécifique de DOM de personnalisation selon l'invention.

Les figures 4a à 4c correspondent à un exemple de code XML pour la mise en uvre de la présente invention.

Illustré figure 2, selon l'invention, on définit un ensemble de DOM A ayant comme noeuds les éléments correspondant aux informations de présentation. Ce DOM A comprend donc des éléments qui représentent la logique non générique pour les informations de personnalisation INFO qu'il définit.

On note tout d'abord que dans toute la suite, la notion d'héritage est employée dans son sens connu par l'homme du métier dans le domaine de la programmation, tel que par exemple un héritage de classes d'objets (ex: java).

Ce premier DOM A donc hérite d'un second type de DOM B. Chaque élément du DOM A comprend donc soit l'ensemble de l'information de personnalisation nécessaire à la personnalisation, soit une partie seulement de celle-ci, le complément d'information étant contenu dans le DOM B dont il hérite.

Par ailleurs, les éléments du DOM A peuvent faire référence à d'autres DOM C au sens de la référence XML afin de compléter les éléments d'information nécessaires à la personnalisation.

Chaque type d'élément représentant les noeuds des DOM selon l'invention fait référence à une classe Java contenant une logique générique. Un interpréteur spécifique interprète alors les éléments pour appeler la bonne classe Java.

On comprend donc facilement que cette structure de données permet, lorsque l'on désire modifier des attributs de personnalisation, de ne pas recompiler de Classe Java comprend du code non générique, mais simplement de rajouter un DOM ou un élément référençant un DOM qui incorpore l'information à ajouter.

On décrit maintenant plus spécifiquement l'invention dans le cadre d'un profil comme illustré figure 3.

Le DOM référencé 1 comprend un élément Presentation Space la correspondant aux différentes informations de présentation d'une page. Ce DOM 1 comprend un élément Profile lb qui fait référence à un DOM référencé 2 comprenant un élément de type Profile 2a, de nom Customer 2b. Ce profil correspond par exemple au type de client par défaut.

Lors de la connexion d'un client de type Customer , et au moment de l'interprétation des DOM, la référence entre les DOM 1 et 2 permet l'appel pour ce type de client, des éléments de type displet ld, le, 1f et l'affichage des displets Displet 1 et Displet 2 tels que définis dans le DOM 1. Cet affichage est réalisé par exécution d'une classe java associée par exemple aux éléments de type presentation Object 6c de l'élément Displet 6a du DOM 6.

Si l'on définit cette fois un type de client particulier de type Gold , en créant un nouveau DOM 3 comprenant un élément 3b de type Profile de nom Gold , et que l'on désire associé à ce type de client un affichage spécifique d'un displet Displet 3 .

Dans ce cas, on crée un autre DOM 4 comprenant un élément de type Presentation space 4a qui d'une part hérite du DOM 1 afin d'afficher également pour le client Gold les displets 1 et 2, et qui d'autre part comprend un élément de type Profile 4b qui référence le DOM 3.

De la sorte, à l'interprétation, la displet Displet 3 sera affichée pour les clients de type Gold mais pas pour les clients seulement de type Customer .

On comprend donc de la sorte que pour ajouter un profil avec des attributs particuliers, il n'est pas nécessaire de modifier la structure d'information relatives aux profils et de recompiler les classes existantes, mais simplement de créer un nouveau DOM héritant de DOM existants pour le type de modification à effectuer, et référençant un nouveau profil correspondant au profil à ajouter.

Les figures 4a à 4c illustrent un exemple de code associé à la situation de la figure 3. La figure 4a correspond à un composant applicatif de type DOM, qui affecte le profil appelé Demo à l'utilisateur courant, et donc, selon l'invention, fait référence au DOM demo de la figure 4b, par l'instruction <node:push src="profiles:demo"/> . On recherche ensuite la valeur de l'élément de displet b pour le profil Demo . L'instruction <node:push src="profiles:demo"/>, met dans le contexte les informations relatives au profil Demo . Les instructions <node:path-select select="/profile/displet/b"/> et < core:echo/> sélectionnent l'élément displet/b et affichent cet élément, pour le profil Demo .

Figure 4b, par le noeud parent , il existe une référence au DOM guest contenant l'élément displet/b. L'interpréteur va donc construire le contexte en plaçant les informations du profil Demo (DOM de la figure 4b) et y ajouter les informations de son profil parent guest (DOM de la figure 4c).

Dans les DOM des figures 4a à 4c, chaque n ud de type displet appelle un exécutable java, qui traite l'information.

L'homme du métier comprendra dans cet exemple l'avantage de la présente invention. En effet, si l'on désire ajouter un profil Demo2 , il suffit de créer le DOM demo2 et de modifier les références dans le DOM initial de la figure 4a, sans modifier la classe java associée.

L'invention est décrite dans ce qui précède à titre d'exemple. Il est entendu que l'homme du métier est à même de réaliser différentes variantes de l'invention sans pour autant sortir du cadre du brevet.

Claims (1)

1. 9 REVENDICATIONS

   1. Procédé de création d'une application correspondant à un ensemble de composants, dont l'exécution fournit un résultat adapté en fonction des conditions d'utilisation de ladite application comprenant: une première étape préalable de création d'une application consistant à : Définir un premier ensemble (2,3) de documents XML dont les noeuds (2a, 3&) représentent lesdites conditions d'utilisation; Définir un second ensemble (1, 4, 6, 5) de documents XML dont les noeuds représentent les composants de ladite application; chacun desdits premiers et second ensemble comprenant des documents XML comprenant un premier type de noeud (6c, 5c) associé à un exécutable et un second type de noeud (lb, 4b) définissant une référence à un document XML dudit premier et second ensemble; les documents du second ensemble comprenant un troisième type de noeud (4a) définissant une référence à un document XML du même second ensemble et représentant un composant de même type; Une seconde étape d'exécution de ladite application consistant à : lire à l'aide d'un interpréteur, un document du second ensemble pour l'interprétation de l'ensemble de ses noeuds et des noeuds des documents référencés desdits premiers et second ensemble, l'interprétation de chaque noeud du premier type (5c, 6c) permettant les exécutions desdits exécutables associés; 15 30 - Stocker, dans un contexte applicatif, les résultats desdites exécutions desdits exécutables; - Renvoyer le contenu dudit contexte applicatif.

   2. Procédé selon la revendication 1, caractérisé en ce que ledit exécutable est une classe Java.

   3. Procédé selon la revendication 1 ou 2, caractérisé en ce que ladite exécution est réalisée sur un serveur.

   4. Procédé selon la revendication 1 ou 2, caractérisé en ce que ladite exécution est réalisée sur un poste client.

   5. Procédé selon la revendication 1, caractérisé en ce que lesdites conditions d'utilisation correspondent à un profil d'un utilisateur.

   6. Programme d'ordinateur caractérisé en ce qu'il comprend 20 un ensemble d'instructions pour la mise en uvre du procédé selon l'une quelconque des revendications 1 à 5.