A de nombreuses reprises nous avons parlé de configuration de document. Nous l’avons définie comme une description des actions applicables ou à appliquer à un document. Historiquement, dans XeMeLios, une configuration de document était représentée par un fichier XML et un ensemble de ressources réparties sur le système de fichier (code Java, images…).
Ce principe est repris dans eXoMiLe mais une configuration de document se présente sous la forme d’une archive ZIP. Cette dernière regroupe les ressources et le code Java permettant d’adapter ou d’ajouter des fonctionnalités à l’outil (Figure 39).
Configuration
Paramétrage
Ressources Code
Figure 39 - Configuration de document
Le paramétrage d’une configuration de document est défini dans un document XML constitué d’un ensemble de « sections » définissant les règles s’appliquant à une fonctionnalité. En règle générale, nous retrouverons les sections suivantes :
· règles d’import et de suppression · définition de l’indexation
· définition des états et des règles de rematérialisation · définition des recherches applicables
Les ressources évoquées précédemment sont référencées par ce fichier de paramétrage. Dans le cas du code Java, un couple classe / paramètres est renseigné, les paramètres étant sérialisés au format JSON. Ce couple est couramment appelé
« point d’extension » dans l’univers d’eXoMiLe. L’exploitation de l’instanciation dynamique nous permettra ensuite d’injecter ce code et de le paramétrer.
3.2.1 Paramétrage de l’import et de la suppression
Le paramétrage des fonctionnalités d’import et de suppression est identique. Il se contente de la définition d’un ensemble d’actions à appliquer séquentiellement avant ou après le traitement (Figure 40).
Figure 40 - Actions pré/post traitement
Une action peut être native ou embarquée, c’est-à-dire qu’elle peut être définie en tant que code Java dans la configuration de document, ou bien disponible dans les modules d’eXoMiLe.
Sur une phase d’import, une action de prétraitement pourra modifier le document d’origine avant son écriture et son indexation dans eXoMiLe. Cela permet notamment d’enrichir le document afin d’offrir une indexation plus adaptée à l’utilisateur. Nous pouvons citer par exemple l’enrichissement d’un document en s’appuyant sur un référentiel accessible via web service afin d’ajouter des libellés à une codification.
Cette notion d’action permet à eXoMiLe d’interagir avec son environnement. Par exemple, il est courant de maintenir des structures de données (fichier, table…) référençant des documents présents dans eXoMiLe. Ce mécanisme de pré/post actions offre ainsi une approche évènementielle pour répondre à cette problématique.
3.2.2 La définition de l’indexation
L’indexation d’un document se présente sous la définition d’éléments, une structure réflexive dans laquelle est spécifiée un ensemble de champs matérialisant des valeurs. L’information ciblée est exprimée par un chemin XPath. Afin de les
Action 1 Action 2 ... Traitement Action 1 Action 2 ...
référencer, champs et éléments possèdent un identifiant unique au sein de la configuration de document.
La réflexivité des éléments permet de construire une indexation arborescente de l’information. Projetés dans un système de gestion de bases de données relationnelles, les éléments seront traduits en tables et les champs en colonnes. L’intégrité des liens parent/enfant est garantie par le SGBDr. Nous découvrirons par la suite l’importance des liens parent/enfants entre les éléments.
Un champ d’indexation est typé. Cependant, la représentation des données sous une forme textuelle est laissée à la charge de l’application productrice du document. Par conséquent, eXoMiLe doit offrir la possibilité de convertir la donnée brute issue du document vers le type cible défini. Pour cela, un point d’extension est proposé permettant de spécifier un convertisseur.
Il peut être souhaitable d’introduire volontairement de la redondance dans une indexation en référençant un champ appartenant à un autre élément (flèche verte sur la Figure 41). C’est la notion de champ référencé. L’objectif sous-jacent étant d’introduire une dénormalisation volontaire au niveau de la base de données afin d’obtenir de meilleures performances en diminuant les jointures. Généralement, il est utile de propager des champs dont la signification fonctionnelle de la valeur est commune à l’ensemble des éléments.
Elément racine Champ Elément Champ Champ Elément Champ Champ Champ
...
...
Figure 41 - Indexation élément / champ
Toujours dans un souci de performance, il est possible de définir des index sur champ. Dans ce cas eXoMiLe positionnera les index les plus adaptés en fonction du type du champ.
La définition de l’indexation peut être mise à jour. En effet, un oubli ou bien le changement d’un cas d’utilisation entraine la modification ou le rajout d’un champ ou d’un élément. Dans une telle situation, champs et éléments sont versionnés afin d’offrir la possibilité d’effectuer des mises à jour incrémentales n’occasionnant que les modifications de structures nécessaires.
La définition de l’indexation conditionne en outre les niveaux de recherche et de rematérialisation. Elle a un impact direct sur les performances et par conséquent sur le ressenti utilisateur.
L’annexe B met en évidence la rupture avec XeMeLios. En effet, nous remarquons l’absence totale de code SQL, eXoMiLe s’appuie uniquement sur une structure déclarative.
3.2.3 La définition du rendu
Dans eXoMiLe, la définition du rendu regroupe le choix et le paramétrage du moteur de rendu ainsi que la définition des états et des propriétés de navigation.
Un moteur de rendu est capable de transformer les données provenant du document en un format de sortie. Par défaut eXoMiLe embarque une implémentation capable de traiter des données XML et de les restituer en HTML et PDF en appliquant des transformations XSL. Bien que ce moteur couvre actuellement l’ensemble des cas d’utilisation, un point d’extension a été positionné afin de pouvoir le substituer. Le moteur par défaut sera présenté plus en détail à la section 3.9.
La consultation d’un document peut être réalisée en rematérialisant le document en totalité ou en accédant par parties, les états. La définition d’un état fait correspondre un élément d’indexation à une transformation XSL qui possède la logique de rendu.
Il est important de voir un état comme une représentation de l’information et il est nécessaire de pouvoir naviguer au sein d’un document en définissant des règles permettant d’organiser les données d’un même état, d’ordonner les états entre eux et de classer les états en catégories. C’est ce que l’on appelle la navigation dans l’univers eXoMiLe.
La navigation au sein d’un document se définit d’une part par le parcours d’un état et, d’autre part, par le changement d’état. Afin de simplifier les explications futures,
nous allons nous appuyer sur un exemple simple en considérant un document constitué d’un sommaire, de pages, d’annexes et d’une conclusion (Figure 42). Ce document est alors découpé en quatre états, les pages et les annexes étant multiples.
Figure 42 - Représentation navigation inter-états / intra états
Le changement d’un état (inter-état) implique une modification de l’apparence du rendu. C’est ce qui se produit quand nous passons du sommaire aux pages. Au sens eXoMiLe, nous changeons d’état donc nous associons une nouvelle feuille de transformation XSL. Ce changement est représenté par une définition sous la forme d’un graphe ordonné qui offre plus de possibilités qu’une simple séquence, notamment la possibilité de faire des boucles, de définir un état « puits », etc.
Le parcours d’un état (intra état) est réalisé par le tri de l’information selon différents critères. Dans notre exemple, les pages sont triées selon leur numéro, idem pour les annexes. Au sens eXoMiLe, nous ne changeons pas d’état, nous conservons la même définition et la feuille de transformation appliquée reste la même.
3.2.4 Paramétrage de la recherche
Le paramétrage de la recherche définit l’ensemble des modèles de recherche applicables au type de document. Un modèle de recherche fait référence à un élément d’indexation et à des champs pouvant appartenir à n’importe quel ancêtre de l’élément
Sommaire
Pages
Page 1
Page 2
Page 3
...
Annexes
Annexe 1
Annexe 2
Annexe 3
...
Conclusion
recherché. Un champ peut constituer un critère ou une colonne de résultat, les deux n’étant pas exclusifs (Figure 43).
Modèle 2 Elément racine Champ Elément Champ Champ Elément Champ Champ Champ Modèle 1 Champ Champ Champ
Définition de l’indexation Modèles de recherche
Critère Colonne de résultat
Champ Champ
Elément concerné par le modèle
Figure 43 - Modèles de recherche
Le fait qu’un modèle de recherche puisse référencer un champ n’appartenant pas à l’élément sur lequel il est défini se traduira par des jointures au niveau de la base de données. Nous aborderons ce point plus en détails à la section 3.5.
La définition d’un modèle est riche, elle permet notamment la mise en forme des données de résultats et offre quatre aides à la saisie de critère :
· autocomplétion : une liste de valeurs est proposée au cours de la saisie du critère
· listing : l’utilisateur a la possibilité d’afficher une liste de l’ensemble des valeurs possibles pour ce critère
· valeur initiale : lors de l’ajout d’un critère, une valeur lui est automatiquement assignée
· sélection : une liste déroulante de valeurs possibles
eXoMiLe offre une implémentation par défaut de chacune de ces aides à la saisie mais des points d’extension permettent de spécifier un fournisseur de données personnalisé.
Ces aides à la saisie ne peuvent pas être toutes appliquées simultanément. En effet, la sélection par liste de choix réduit les combinaisons possibles. La matrice de compatibilité est présentée dans le Tableau XI.
Tableau XI - Matrice de compatibilité des aides à la saisie
Autocomplétion Listing Valeur initiale Sélection
Autocomplétion Listing Valeur initiale
Sélection
Une recherche peut être exportée, c’est-à-dire qu’elle sera produite dans un format de sortie permettant sa diffusion. En règle générale, une recherche est exportée dans une feuille de classeur Microsoft Excel mais un point d’extension permet de modifier ce comportement.
Une recherche peut être la source d’un « export avancé ». Un export avancé permet d’extraire un ensemble de résultats relatifs à la recherche d’origine. Nous avons vu précédemment que la définition de l’indexation répondait à une représentation hiérarchique de l’information contenue dans un document. L’export avancé permet d’extraire des sous arbres en lien avec les résultats de la recherche initiale en s’appuyant sur les relations parent / enfant maintenues par la base de données (Figure 44).
Figure 44 - Représentation de l'export avancé
Résultats de la recherche Résultats de l’export avancé
La définition des recherches offre de nombreuses possibilités de configuration. C’est à l’application tierce d’interpréter cette définition et ce travail peut être laborieux et répétitif. Nous verrons à la section 3.10 un composant clé en main proposé par eXoMiLe permettant d’exploiter pleinement le paramétrage de la recherche afin de délester les applications clientes de ce travail.