Architecture de Mobile Forms

Architecture

Mobile Forms est déployé sous la forme d’un package au sein de l’instance CQ intégrée et expose la fonctionnalité Mobile Forms sous la forme d’un point final de type REST sur HTTP/S à l’aide de l’architecture Apache Sling RESTful.

 


Vue plein écran

Utilisation de la structure Sling

Apache Sling est centré sur la ressource. Elle commence par utiliser une URL de requête pour résoudre la ressource. Chaque ressource possède une propriété sling:resourceType (ou sling:resourceSuperType). Suivant cette propriété, la méthode de requête et les propriétés de l’URL de requête, un script sling est sélectionné pour gérer la requête. Ce script sling peut être un JSP ou un servlet. Pour Mobile Forms, les nœuds de profil agissent en tant que ressource sling et le rendu de profil a le rôle du script sling qui gère la demande pour générer un formulaire pour périphériques mobiles avec un profil particulier. Un rendu du profil est un JSP qui lit les paramètres depuis une requête et appelle le service Forms OSGi.

Pour plus d’informations sur les paramètres de requête pris en charge, reportez-vous à Rendu du modèle de formulaire.

Lorsqu’un utilisateur effectue une requête à partir d’un périphérique client, comme un iOS ou le navigateur Android, Sling résout d’abord le nœud de profil en fonction de l’URL de requête. Dans ce nœud de profil, il lit sling:resourceSuperType et sling:resourceType pour déterminer tous les scripts disponibles capables de gérer cette requête de rendu de formulaire. Il utilise ensuite les sélecteurs de requête Sling avec la méthode de requête pour identifier le script le mieux adapté pour traiter cette requête. Une fois que la requête atteint un JSP de rendu du profil, le JSP appelle le service Forms OSGi.

Pour plus d’informations sur la résolution du script sling, reportez-vous à Aide-mémoire sur AEM Sling ou à Décomposition de l’URL d’Apache Sling.

Flux d’appel de traitement de formulaire usuel

Mobile Forms masque tous les objets intermédiaires requis pour le traitement (génération ou envoi) d’un formulaire dans la première demande. Il ne met pas en cache les objets qui dépendent des données car ces objets sont susceptibles d’être modifiés.

Mobile Form conserve deux niveaux différents de caches, le cache de prérendu (preRender) et le cache de rendu (Render). Le cache de prérendu contient tous les fragments et images d’un modèle résolu et le cache de rendu est composé du contenu rendu tel que le code HTML. 

flux de travaux Mobile Forms
flux de travaux Mobile Forms

Mobile Forms ne met pas en cache les modèles avec des références d’images ou de fragments manquantes. Si Mobile Forms a besoin de plus de temps que d’habitude, alors vérifiez les journaux du serveur pour voir les références et avertissements manquants. Assurez-vous également que l’objet n’a pas encore atteint la taille maximale.      

Le service Forms OSGi traite une requête en deux étapes :

  • Génération de mises en page et d’état de formulaire initial : le service de rendu Forms OSGi appelle le composant Forms Cache pour déterminer si le formulaire a déjà été mis en cache et s’il n’a pas été invalidé. Si le formulaire est mis en cache et valide, il est utilisé pour la sortie HTML à partir du cache. Si le formulaire est invalidé, le service de rendu Forms OSGi appelle le conteneur de services de formulaires LiveCycle qui génère la mise en page et l’état initiaux du formulaire au format XML. Ce fichier XML est transformé en mise en page HTML et en état de formulaire JSON initial par le service Forms OSGi, puis mis en mémoire cache pour les requêtes suivantes.
  • Formulaires préremplis : pendant le rendu, si un utilisateur demande des formulaires avec des données préremplies, le service de rendu Forms OSGi appelle le conteneur de services de formulaires et génère un nouvel état de formulaire avec des données fusionnées. Toutefois, dans la mesure où une mise en page est déjà créée à l’étape précédente, cet appel est plus rapide que le premier. Cet appel exécute uniquement la fusion des données et les scripts sur les données.

Un formulaire à générer peut résider dans le référentiel LiveCycle. S’il existe des mises à jour dans un formulaire ou tout autre actif utilisé à l’intérieur d’un formulaire, le composant de mise en cache du formulaire les détecte et le cache de ce formulaire en particulier est invalidé. Une fois que le service Forms OSGi a terminé le traitement, le JSP du rendu du profil ajoute les références à la bibliothèque JavaScript et le style à ce formulaire et renvoie la réponse au client. Un serveur Web standard tel qu’Apache peut être utilisé ici avec la compression HTML activée. Un serveur Web réduirait considérablement le temps de réponse, le trafic réseau et la durée nécessaire au trafic des données entre le serveur et le client.

Lorsqu’un utilisateur envoie le formulaire, le navigateur envoie l’état du formulaire au format JSON au proxy de service d’envoi ; le proxy de service d’envoi génère ensuite un fichier XML avec les données provenant des fichiers JSON et envoie le fichier XML au point de fin d’envoi. 

Composants

Unités déployables

Mobile Forms est fourni sous la forme d’un package CQ gérable depuis CQ Package Manager disponible à l’adresse http://:/lc/crx/packmgr/index.jsp.

adobe-lc-forms-pkg.zip : Ceci constitue le package d’installation unique principal. Il contient les sous-packages et paquets suivants :

  • adobe-lc-forms-core-<version>.jar : il s’agit d’un paquet OSGi contenant les composants et services OSGi pour Mobile Forms.
  • scala-lang-2.9.1.jar : le paquet adobe-lc-forms-core utilise certaines bibliothèques scala présentes dans scala-lang-2.9.1.jar. 
  • adobe-lc-forms-runtime-pkg-<version>.zip : ce package contient les bibliothèques JavaScript d’exécution, telles que les moteurs de script, de mise en page et le CSS.
  • adobe-lc-forms-content-pkg-<version>.zip : ce package contient les scripts de profil et de rendu de profil, ainsi que d’autres ressources.
  • adobe-lc-forms-lcconnector-<version>.jar : ce paquet OSGi contient toutes les implémentations spécifiques du service LiveCycle.

Composants OSGi (adobe-lc-forms-core.jar)

Adobe XFA Forms Renderer (com.adobe.livecycle.adobe-lc-forms-core) est le nom d’affichage du lot OSGi pour Mobile Forms depuis la vue du lot de la console d’administration Felix (http://<host>:<port>/lc/system/console/bundles).

Ce composant contient les composants OSGi pour le rendu, la gestion de la mémoire cache et les paramètres de configuration.

Service Forms OSGi

Ce service OSGi contient la logique de génération d’un XDP au format HTML et gère l’envoi d’un formulaire pour générer des données XML. Ce service utilise le conteneur de services de formulaires LiveCycle. Le conteneur de services de formulaires appelle en interne le composant natif XMLFormService.exe qui effectue le traitement.

Si une demande de rendu est reçue, ce composant appelle le conteneur de services de formulaires pour générer des informations de mise en page et d’état qui sont ensuite traitées afin de générer des états DOM de formulaires HTML et JSON.

Ce composant est également responsable de la génération de données XML à partir de l’état du formulaire au format JSON envoyé.

Composant en mémoire cache

Remarque :

Le mécanisme de mise en cache décrit dans cet article a été mis à jour pour LiveCycle ES4 Service Pack 1. Si vous utilisez la version de base de LiveCycle ES4, suivez la procédure décrite dans Principales différences entre LiveCycle ES4 et Service Pack 1.

Mobile Forms utilise la mise en mémoire cache pour optimiser le débit et le temps de réponse. Vous pouvez configurer le niveau du service de la mémoire cache pour régler avec précision le compromis entre les performances et l’utilisation de l’espace.

Stratégie de la mise en mémoire cache

Description

Aucune

Les artefacts ne sont pas mis en mémoire cache

Conservatrice

Seuls les artefacts intermédiaires générés avant le rendu du formulaire comme le modèle contenant les fragments et les images en ligne sont mis en mémoire cache

Agressive

Le contenu HTML généré est mis en mémoire cache
Tous les artefacts enregistrés en mémoire cache sont mis en mémoire cache dans le cadre d’une stratégie conservatrice.
Remarque : cette stratégie permet d’obtenir de meilleures performances, mais utilise davantage de mémoire pour la conservation des artefacts en mémoire cache.

Mobile Forms effectue la mise en mémoire cache à l’aide de la stratégie LRU. Si la stratégie de cache est définie sur Aucun, le cache n’est pas créé. La stratégie LRU d’expulsion est basée sur le nombre de formulaires. Vous pouvez également spécifier la taille seuil au-delà de laquelle les objets ne sont pas mis en cache.

Remarque :

le cache en mémoire n’est pas partagé entre les nœuds de la grappe.

Service de configuration

Le service de configuration permet l’optimisation des paramètres de configuration et des paramètres de la mémoire cache pour Mobile Forms.

Pour mettre à jour ces paramètres, accédez à la console d’administration CQ Felix (disponible à l’adresse http://<serveur>:<port>/lc/system/console/configMgr), puis recherchez et sélectionnez LC Forms Configuration.

Vous pouvez configurer la taille de la mémoire cache ou désactiver la mémoire cache à l’aide du service de configuration. Pour en savoir plus, consultez la section Composant de cache. Vous pouvez également activer le débogage à l’aide du paramètre Options de débogage. Pour plus d’informations sur le débogage des formulaires, reportez-vous à Débogage de Mobile Forms.


Vue plein écran

Composants d’exécution (adobe-lc-forms-runtime-pkg.zip)

Le package d’exécution contient les bibliothèques côté client utilisées pour générer les formulaires HTML.

Composants importants disponibles dans le package d’exécution :

Moteur de script

L’implémentation d’Adobe XFA prend en charge deux types de langage de script pour activer l’exécution de la logique définie par l’utilisateur dans les formulaires : JavaScript et FormCalc.

Le moteur de script des formulaires HTML est écrit en langage JavaScript pour prendre en charge l’API de script XFA dans ces deux langages.

Lors du rendu, le script FormCalc est traduit (et mis en mémoire cache) en JavaScript sur le serveur de manière transparente pour l’utilisateur ou le concepteur.

Ce moteur de script utilise certaines fonctionnalités d’ECMAScript5 comme Object.defineProperty. Le moteur et/ou la bibliothèque sont délivrés en tant que bibliothèques client CQ avec pour nom de catégorie xfaforms.profile.L’API FormBridge est également fournie pour permettre aux portails ou applications externes d’interagir avec le formulaire. A l’aide de FormBridge, une application externe peut masquer certains éléments, obtenir ou définir leurs valeurs, ou modifier leurs attributs de manière programmée.

Pour plus d’informations, voir l’article sur Form Bridge.

Moteur de mise en page

La mise en page et l’aspect visuel de Mobile Forms reposent sur les fonctionnalités SVG 1.1, jQuery, BackBone et CSS3. L’aspect initial d’un formulaire est généré et mis en mémoire cache sur le serveur. Les ajustements de cette mise en page initiale et toutes les modifications incrémentielles supplémentaires apportées à la mise en page du formulaire sont gérés sur le client. Afin d’accomplir cela , le package d’exécution contient un moteur de mise en page écrit dans Javascript et basé sur jQuery/Backbone. Ce moteur gère l’intégralité du comportement dynamique, comme l’ajout/la suppression des instances répétables, la mise en page évolutive d’un objet. Ce moteur de mise en page génère un formulaire page par page. L’utilisateur ne voit qu’une page au début, et la barre de défilement horizontale ne prend qu’une page en compte. Cependant, lorsqu’un utilisateur défile vers le bas, le rendu de la page suivante commence. Ce rendu page par page réduit la quantité de temps nécessaire pour effectuer le rendu de la première page dans un navigateur et améliore les performances perçues du formulaire. Ce moteur ou cette bibliothèque fait partie de la bibliothèque client CQ avec pour nom de catégoriexfaforms.profile.

Le moteur de mise en page contient également un ensemble de widgets utilisés pour capturer la valeur des champs de formulaire à partir d’un utilisateur. Ces widgets sont modélisés en tant que widgets UI jQuery qui implémentent certains contrats supplémentaires pour travailler en toute transparence avec le moteur de mise en page.

Pour plus d’informations sur les widgets et les contrats correspondants, reportez-vous à Widgets personnalisés pour Mobile Forms.

Définition de styles

Le style associé aux éléments HTML est ajouté soit en ligne, soit en fonction du bloc CSS intégré.Certains styles courants et indépendants sur les formulaires font partie de la bibliothèque client CQ avec pour nom de catégorie xfaforms.profile.

En plus des propriétés de style par défaut, chaque élément du formulaire contient également certaines classes CSS en fonction du type d’élément, du nom et d’autres propriétés. A l’aide de ces classes, vous pouvez redéfinir le style des éléments en spécifiant leur propre CSS.

Pour plus d’informations sur le style et les classes par défaut, voir Introduction aux styles.

Script côté serveur et services Web

Tous les scripts marqués pour exécution sur le serveur ou pour appeler un service Web (quel que soit l’endroit où il est marqué pour exécution) sont toujours exécutés sur le serveur.

Le moteur de script du client :

  1. Passe un appel synchrone au serveur transmettant l’état actuel du formulaire sous la forme de JSON ;
  2. Exécute le script ou le service Web sur le serveur ;
  3. Génère un nouvel état JSON ;
  4. Fusionne le nouvel état JSON sur le client lorsque la réponse est renvoyée.

Lots des ressources de localisation

Par défaut, Mobile Forms est pris en charge en anglais, en français, en allemand et en japonais. En fonction du jeu de paramètres régionaux reçus dans l’en-tête de requête, le lot de ressources correspondant est envoyé au client. Ce lot de ressources est ajouté au profil JSP sous la forme d’une bibliothèque cliente CQ sous le nom de catégorie xfaforms.I18N. Vous pouvez remplacer la logique du profil consistant à prendre les packages avec paramètres régionaux.

Composants Sling (adobe-lc-forms-content-pkg.zip)

Le package Sling contient le contenu associé aux profils et au rendu des profils.

Profils

Les profils sont les nœuds de ressources dans sling qui représentent un formulaire ou une famille de formulaires. Au niveau CQ, ces profils sont des nœuds JCR. Les nœuds se trouvent sous le dossier /content dans le référentiel JCR et peuvent figurer dans n’importe quel sous-dossier sous le dossier /content.

Rendus des profils

Le nœud de profil possède une propriété sling:resourceSuperType avec la valeur xfaforms/profile. Cette propriété envoie en interne des demandes de transfert au script sling pour les nœuds de profil qui figurent dans le dossier /libs/xfaforms/profile. Ces scripts sont des pages JSP, qui sont des conteneurs permettant de rassembler des formulaires HTML et des artefacts JS/CSS obligatoires. Les pages comportent des références à :

  • xfaforms. I18N.<locale> : cette bibliothèque contient des données localisées.
  • xfaforms.profile : cette bibliothèque contient l’implémentation pour les moteurs de script XFA et de mise en page.
Ces bibliothèques sont modélisées sous la forme de bibliothèques clientes CQ qui tirent profit des fonctions de concaténation, réduction et compression automatiques des bibliothèques JavaScript de la structure CQ. Pour plus d’informations sur les bibliothèques clientes CQ, voir Documentation sur les bibliothèques clientes CQ.   Comme décrit ci-dessus, le rendu de profil JSP appelle le service de formulaires grâce à une inclusion sling. Ce JSP définit également diverses options de débogage en fonction de la configuration de l’administrateur ou des paramètres de requête.   Mobile Forms permet aux développeurs de créer un profil et un rendu du profil pour personnaliser l’aspect des formulaires. Par exemple, Mobile Forms permet à un développeur d’intégrer un formulaire dans un panneau ou une section <div> d’un portail HTML existant. Pour plus d’informations sur la création de profils personnalisés, reportez-vous à Création d’un profil personnalisé.

 Adobe

Recevez de l’aide plus rapidement et plus facilement

Nouvel utilisateur ?

Adobe MAX 2024

Adobe MAX
La conférence sur la créativité

Du 14 au 16 octobre à Miami Beach et en ligne

Adobe MAX

La conférence sur la créativité

Du 14 au 16 octobre à Miami Beach et en ligne

Adobe MAX 2024

Adobe MAX
La conférence sur la créativité

Du 14 au 16 octobre à Miami Beach et en ligne

Adobe MAX

La conférence sur la créativité

Du 14 au 16 octobre à Miami Beach et en ligne