Le module de rendu est constitué de deux composants : le service, exposant les fonctionnalités au client, et le moteur de rendu, partie cachée en charge des traitements. Ce dernier embarque la logique de traitements permettant de rendre humainement lisible un document dématérialisé.
Le moteur de rendu est un élément personnalisable d’eXoMiLe. En effet un point d’extension dans le paramétrage de la configuration d’un document permet de spécifier un moteur de rendu particulier. eXoMiLe propose une version embarquée permettant de traiter les documents XML.
Le moteur de rendu doit être capable de traiter un document dans sa totalité ou en partie. En effet, nous avons précédemment évoqué qu’un document est découpé logiquement en état. C’est le service de rendu qui a la charge de fournir les données techniques permettant d’extraire une portion du document. Un cas particulier se produit lorsque l’application cliente souhaite dématérialiser un élément qui ne constitue pas un état. Dans une telle situation, le service retrouve le plus proche état conteneur et fournira les données correspondantes au moteur de rendu.
3.9.1 Le traitement des documents XML
Le traitement d’un document XML est un processus constitué de nombreuses tâches. En effet, le besoin client exprimé est plus complexe que la simple impression du document dématérialisé. L’utilisateur doit, par exemple, pouvoir naviguer entre états ou encore exporter un état dans différents formats. Par conséquent un ensemble de transformations sont nécessaires afin d’enrichir le document avec des métadonnées. Ce résultat est obtenu par des transformations XSL successives.
La première consiste à convertir le document dans un encodage unifié (UTF-8) afin de prémunir de problèmes liés aux caractères spéciaux (accents par exemple).
Il s’en suit un ajout de métadonnées identifiants (ancres) s’appuyant sur les clés fonctionnelles exprimées dans le paramétrage de l’indexation. Jusque-là nous avons
limité l’utilité de ces clés à la détection des collisions fonctionnelles. Cependant, lorsqu’elles sont positionnées sur un élément d’indexation, elles constituent un ensemble identifiant. Ce dernier sera sérialisé et positionné en tant que métadonnée. Nous aborderons l’utilité de cette opération par la suite.
Le document est ensuite enrichi avec des informations de sélection. Cela permet de mettre en valeur certaines parties du document. Nous répondons ainsi au problème de rendu d’un élément qui n’est pas un état en le mettant en valeur, permettant à l’utilisateur de l’identifier rapidement dans le rendu.
La dernière transformation consiste à convertir le document en HTML pour l’afficher dans un navigateur ou de le transformer en FO1 (Formatting Object) [12], un
format pivot permettant de produire différents formats de sortie comme du PDF ou du JPEG.
Figure 64 - Moteur de rendu XML par défaut
1 Le choix d’utiliser le format FO comme pivot entre les données XML et la sortie souhaitée est sujet à débat. En effet, bien que ce format soit défini par le W3C, il ne semble pas avoir séduit la communauté des développeurs. D’autres outils tel que Jasper permettent de traiter des données XML et de produire des résultats identiques. Ce choix a donc été retenu dans un premier temps du fait de ma connaissance de cette technologie et dans le but de m’inscrire dans la continuité de XeMeLios sur les traitements XSL.
3.9.2 La navigation dans un document : exploiter les clés fonctionnelles
La navigation dans un document est une notion complexe. Elle répond d’une part au besoin de navigation inter-états et intra état, et, d’autre part, au besoin d’accéder à un autre document. Par conséquent, nous déduisons deux modes de navigation :
Navigation détachée : les informations de navigation ne sont pas portées par le document et c’est l’utilisateur qui a le contrôle. Nous sommes dans le cas d’un composant de pagination permettant de changer de page.
Navigation attachée : le document porte les informations de navigation. Nous sommes, par exemple, dans le cas d’un lien d’un état vers un autre état ce qui se traduira par un lien hypertexte.
Ces deux modes de navigation peuvent concerner le document en cour de consultation ou porter sur un document différent. Nous différencions donc deux types de navigation :
Navigation interne : lorsque les informations de navigation concernent le même document. Dans ce cas, l’utilisateur reste dans le même contexte de navigation constitué par le couple configuration de document / document.
Navigation externe : lorsque les informations de navigation concernent un document différent. Dans ce cas, le contexte de navigation change.
Au final, la navigation offerte par eXoMiLe est un couple mode de navigation / type de navigation.
La création d’identifiants à partir des clés fonctionnelles nous permet de référencer un document ou un élément, elle est essentiellement utilisée dans le cas de la navigation attachée. Nous pouvons ainsi exprimer une demande de navigation interne ou externe en s’appuyant sur un format défini. Le choix entre l’une ou l’autre est donc réduit à la simple vérification de la présence de l’identifiant dans le document courant.
La navigation détachée est exprimée dans le paramétrage de la configuration de document. Nous avons abordé ce point en détail au paragraphe 3.2.2. Elle est traitée en s’appuyant sur le service de rendu qui nous fournit un objet de navigation. Cet objet décrit les états suivants et précédents, et leur quantité. Ces informations nous permettent d’alimenter un composant de pagination. Telle qu’elle est définie, la
navigation détachée ne permet pas de faire de navigation externe. En effet elle exploite le document courant et offre les fonctionnalités de navigation inter-états et intra état.
3.9.3 Le composant de navigation, une solution clé en main
L’intégration du rendu et des modes de navigation est une opération complexe mais commune aux applications tierces. Par conséquent, eXoMiLe offre un composant clé en main permettant d’exploiter l’ensemble des fonctionnalités présentées précédemment.
Ce composant se présente sous la forme d’un plugin JQuery reposant sur une communication JSON-RPC. La partie cliente est entièrement fournie par eXoMiLe. La partie serveur est partiellement implémentée. Seule la couche de communication JSON-RPC est laissée à la charge de l’application cliente car les frameworks couramment utilisés dans l’univers Java la fournissent (Spring, Struts…). Les applications ont la possibilité de spécialiser la couche RPC d’eXoMiLe afin d’y ajouter des fonctionnalités. Un exemple couramment rencontré est l’ajout de contrôle de périmètre d’accès. La Figure 65 illustre les points précédemment évoqués.
Serveur API JSON-RPC Implémentation eXoMiLe Spécialisation de l’application
Client - Plugin jQuery
IHM
API JSON-RPC
Figure 65 - Communication JSON-RPC
Les modes et types de navigation détaillés précédemment sont entièrement implémentés et la détection du changement de contexte (document) est assurée afin de limiter les appels RPC. L’intégration de ce composant est très simple et ne nécessite que quelques lignes de code JavaScript.
La Figure 66 illustre un exemple d’utilisation de ce composant dans une application exploitée par la DGFiP. Pour des raisons de confidentialité les informations sensibles ont été volontairement floutées.
Figure 66 - Présentation du composant de navigation
Navigation inter-états (interne)
Téléchargement et impression
Navigation intra états détachée (interne) Navigation attachée inter / intra états (interne / externe)