Meilleures pratiques pour travailler avec les formulaires adaptatifs best-practices-for-working-with-adaptive-forms

Utilisez le aem-project-archetype d’Apache Maven pour créer et gérer la structure d’un projet AEM. Il permet de créer la structure et les modèles recommandés pour votre projet AEM. En outre, il fournit des systèmes d’automatisation de création et de contrôle des modifications pour aider à la gestion du projet.

• Utilisez la commande Mavenarchetype:generate pour générer la structure initiale.
• Utilisez la commande Maven eclipse:eclipse pour générer les fichiers de projet Eclipse et importer le projet dans Eclipse.

L’outil FileVault ou VLT vous permet de mapper le contenu d’une instance CRX ou AEM à votre système de fichiers. Il fournit des opérations de gestion de contrôle des modifications, telles que l’archivage et l’extraction du contenu du projet AEM. Voir Comment utiliser l’outil VLT.

Si vous utilisez un environnement de développement intégré à Eclipse, vous pouvez utiliser les outils de développement AEM pour une intégration transparente de l’IDE Eclipse aux instances AEM afin de créer des applications AEM. Pour plus d’informations, voir Outils de développement AEM pour Eclipse.

Ne stockez aucun contenu ou n’apportez aucune modification dans le dossier /libs. Créez des recouvrements dans les dossiers /app pour étendre ou remplacer les fonctionnalités par défaut.

Lorsque vous créez des packages pour déplacer du contenu, assurez-vous que les chemins de filtre de package sont corrects et que seuls les chemins obligatoires sont mentionnés.

Ne stockez aucun contenu ou n’apportez aucune modification dans le dossier /libs. Créez des recouvrements dans les dossiers /app pour étendre ou remplacer les fonctionnalités par défaut.

Définissez des dépendances correctes pour les packages afin de forcer un ordre / une séquence d’installation prédéterminé(e).

Ne créez aucun nœud référençable dans /libs ou /apps.

Un modèle de formulaire adaptatif est une page AEM spécialisée qui définit la structure et les informations d’en-tête et de pied de page d’un formulaire adaptatif. Un modèle comporte des dispositions, des styles et une structure de base préconfigurés pour un formulaire adaptatif. AEM Forms fournit des modèles et des composants prêts à l’emploi que vous pouvez utiliser pour créer des formulaires adaptatifs. Vous pouvez également créer des modèles et des composants personnalisés en fonction de vos besoins. Il est recommandé de rassembler les exigences relatives aux modèles et composants supplémentaires dont vous aurez besoin dans vos formulaires adaptatifs. Pour plus d’informations, voir Personnalisation des formulaires et composants adaptatifs.

Il est recommandé de charger les modules de formulaire à l’aide de l’interface d’utilisation de Form Manager plutôt que de l’interface d’utilisation du gestionnaire de modules CRX, car le chargement de modules via le gestionnaires de modules CRX peut parfois entraîner des anomalies.

AEM Forms vous permet de créer des formulaires adaptatifs basés sur les modèles de formulaires suivants. Les modèles de formulaire font office d’interface pour l’échange de données entre un formulaire et un système AEM et fournissent une structure XML pour le flux de données à l’intérieur et à l’extérieur d’un formulaire adaptatif. En outre, les modèles de formulaire imposent des règles et des contraintes aux formulaires adaptatifs sous la forme de schémas et de contraintes XFA.

• Aucun  : les formulaires adaptatifs créés avec cette option n’utilisent aucun modèle de formulaire. Les données XML générées à partir de ce type de formulaire présentent une structure plate avec des champs et des valeurs correspondantes.
• Schéma XML ou JSON  : les schémas XML et JSON représentent la structure dans laquelle les données sont générées ou utilisées par le système back-end de l’entreprise. Vous pouvez associer un schéma à un formulaire adaptatif et utiliser ses éléments pour ajouter du contenu dynamique à un formulaire adaptatif. Les éléments du schéma sont disponibles dans l’onglet Objet du modèle de données du navigateur de contenu pour la création de formulaires adaptatifs. Vous pouvez faire glisser et déposer les éléments du schéma pour créer le formulaire.
• Modèle de formulaire XDP  : il s’agit d’un modèle de formulaire idéal si vous investissez dans des formulaires HTML5 basés sur XFA. Il fournit une méthode directe de conversion des formulaires de type XFA en formulaires adaptatifs. Toutes les règles XFA existantes sont conservées dans les formulaires adaptatifs associés. Les formulaires adaptatifs qui en résultent prennent en charge les éléments XFA, tels que les validations, les événements, les propriétés et les modèles.
• Modèle de données de formulaire  : il s’agit du modèle de formulaire idéal si vous souhaitez intégrer les systèmes back-end tels que les bases de données, les services web et un profil utilisateur AEM pour préremplir des formulaires adaptatifs et enregistrer des données de formulaire envoyé dans les systèmes back-end. Un éditeur de modèle de données de formulaire vous permet de définir et de configurer des entités et des services dans un modèle de données de formulaire que vous pouvez utiliser pour créer des formulaires adaptatifs. Pour plus d’informations, voir Intégration des données AEM Forms.

AEM Forms fournit des modèles prêts à l’emploi que vous pouvez utiliser pour créer des formulaires adaptatifs. Vous pouvez également créer vos propres modèles. AEM fournit des modèles statiques et modifiables.

• Les modèles statiques sont définis et configurés par les développeurs.
• Les modèles modifiables sont créés par les auteurs et autrices à l’aide de l’éditeur de modèles. L’éditeur de modèles permet de définir une structure de base et un contenu initial dans un modèle. Toute modification dans la couche de structure est répercutée dans tous les formulaires utilisant ce modèle. Le contenu initial peut inclure un thème préconfiguré, un service de préremplissage, une action d’envoi, etc. Cependant, ces paramètres peuvent être modifiés pour un formulaire à l’aide de l’éditeur de formulaires. Pour plus d’informations, voir Modèles de formulaires adaptatifs.

Pour définir le style d’une instance ou d’un panneau spécifique, utilisez le style en ligne. Vous pouvez également définir une classe dans un fichier CSS et spécifier le nom de classe dans la propriété CSS Class du composant.

Intégrez une bibliothèque cliente à un composant pour appliquer de manière constante des styles aux formulaires adaptatifs ou aux fragments utilisant ce composant. Pour plus d’informations, reportez-vous à la section Création d’un composant de page de formulaire adaptatif.

Appliquez des styles définis dans une bibliothèque cliente pour sélectionner les formulaires adaptatifs, en spécifiant le chemin d’accès à la bibliothèque cliente dans le champ relatif au chemin d’accès au fichier CSS des propriétés du conteneur de formulaire adaptatif.

Pour créer une bibliothèque cliente de vos styles, vous pouvez configurer le fichier CSS personnalisé dans la bibliothèque cliente de base de l’éditeur de thème ou dans les propriétés du conteneur de formulaire.

Les formulaires adaptatifs proposent des dispositions de panneau (dispositions réactives en onglet ou en accordéon par exemple) ainsi qu’un assistant pour contrôler la disposition des composants de formulaire. Vous pouvez créer des dispositions de panneau personnalisées et les rendre accessibles aux auteurs et autrices de formulaire. Pour plus d’informations, voir Création de composants de disposition personnalisés pour les formulaires adaptatifs.

Vous pouvez également personnaliser les composants spécifiques d’un formulaire adaptatif tels que les champs et la disposition des panneaux.

• Utilisez la fonctionnalité Recouvrement d’AEM pour modifier une copie d’un composant. Il n’est pas recommandé de modifier les composants par défaut.
• Pour personnaliser la disposition des composants de formulaire adaptatif prêts à l’emploi dans /libs, créez des composants de disposition personnalisés en plus des dispositions par défaut.
• Intégrez les interactivités personnalisées en créant des widgets ou des apparences personnalisés. Il n’est pas recommandé de modifier les composants par défaut. Pour plus d’informations, consultez Structure de l’apparence.

Pour connaître les recommandations relatives à la gestion des données d’identification personnelle, reportez-vous à la section Gestion des informations d’identification personnelle.

Utilisez le navigateur d’objets de la barre latérale pour accéder rapidement aux champs dans la partie la plus basse de la hiérarchie du formulaire. Vous pouvez utiliser la zone de recherche pour rechercher des objets dans le formulaire ou l’arborescence d’objets pour passer d’un objet à un autre.

Pour afficher et modifier les propriétés d’un composant dans le navigateur de composants dans la barre latérale, sélectionnez le composant, puis cliquez sur . Vous pouvez également double-cliquer sur un composant pour afficher ses propriétés dans l’explorateur de propriétés.

Utilisez les raccourcis clavier pour effectuer des actions rapides sur vos formulaires. Voir Raccourcis clavier AEM Forms.

L’utilisation des composants de formulaire adaptatif est recommandée uniquement dans les pages de formulaire adaptatif. Les composants dépendent de leur hiérarchie parent. Par conséquent, ne les utilisez pas dans une page AEM.

Utilisez des noms uniques et pertinents pour les champs de formulaire et les composants afin d’éviter tout conflit potentiel lors de la définition des règles.

Utilisez l’opérateur this pour un composant afin d’y faire mention lors de l’expression d’une règle. Ainsi, la règle reste valide même si le nom du composant est modifié. Par exemple, field1.valueCommit script: this.value > 10.

Utilisez les noms de composant lorsque vous faites référence à d’autres composants de formulaire. Utilisez la propriété value pour récupérer la valeur d’un champ ou d’un composant. Par exemple, field1.value.

Désignez les composants selon une hiérarchie relative unique afin d’éviter tout conflit. Par exemple, parentName.fieldName.

Lorsque vous manipulez des règles complexes ou fréquemment utilisées, pensez à définir la logique commerciale comme fonctions dans une bibliothèque cliente distincte que vous pouvez spécifier et réutiliser dans les formulaires adaptatifs. La bibliothèque client doit être une bibliothèque autonome et ne doit donc avoir aucune dépendance externe, à l’exception de jQuery et Underscore.js. Vous pouvez également utiliser la bibliothèque cliente pour imposer la revalidation côté serveur des données de formulaire envoyées.

Les formulaires adaptatifs fournissent un ensemble d’API que vous pouvez utiliser pour communiquer et effectuer des actions sur les formulaires adaptatifs. Les principales API sont les suivantes. Pour plus d’informations, voir Référence d’API de bibliothèque JavaScript pour les formulaires adaptatifs.

• guideBridge.reset() : permet de réinitialiser un formulaire.

• guideBridge.submit() : permet de soumettre un formulaire.

• guideBridge.setFocus(somExp, focusOption, runCompletionExp) : permet de se concentrer sur un champ.

• guideBridge.validate(errorList, somExpression, focus) : permet de valider un formulaire.

• guideBridge.getDataXML(options) : permet d’obtenir les données de formulaire en tant que XML.

• guideBridge.resolveNode(somExpression) : permet d’obtenir un objet de formulaire.

• guideBridge.setProperty(somList, propertyName, valueList) : permet de définir la propriété d’un objet de formulaire.

• En outre, vous pouvez utiliser les propriétés de champ suivantes :

  • field.value pour modifier la valeur d’un champ ;
  • field.enabled pour activer/désactiver un champ ;
  • field.visible pour modifier la visibilité d’un champ.

Les auteurs et autrices de formulaires adaptatifs peuvent avoir besoin d’écrire du code JavaScript pour créer une logique métier dans un formulaire. Bien que JavaScript soit puissant et efficace, il est susceptible de compromettre les attentes en matière de sécurité. Par conséquent, vous devez vous assurer que l’auteur ou l’autrice du formulaire est une personne de confiance et qu’il existe des processus pour examiner et approuver le code JavaScript avant qu’un formulaire ne soit mis en production. L’administrateur ou l’administratrice peut restreindre l’accès à l’éditeur de règles de certains groupes d’utilisateurs et d’utilisatrices en fonction de leur rôle ou de leur fonction. Voir Autorisation d’accès à l’éditeur de règles pour des groupes d’utilisateurs et d’utilisatrices sélectionnés.

Vous pouvez utiliser des expressions dans les règles pour rendre les formulaires adaptatifs dynamiques. Toutes les expressions sont des expressions JavaScript valides qui utilisent des API de modèle de script pour les formulaires adaptatifs. Ces expressions renvoient des valeurs de certains types. Pour plus d’informations sur les expressions et les meilleures pratiques associées, voir Expressions des formulaires adaptatifs.

Adobe recommande d’utiliser des opérations synchrones JavaScript plutôt que asynchrones lors de la création de règles avec l’éditeur de règles. L’utilisation d’opérations asynchrones est fortement déconseillée. Cependant, si vous vous trouvez dans une situation où les opérations asynchrones sont inévitables, il est essentiel de mettre en œuvre les fonctions de fermeture (closures) de JavaScript. Vous pouvez ainsi vous protéger de manière efficace contre toute situation de concurrence potentielle, en veillant à ce que vos mises en œuvre de règles offrent des performances optimales et maintiennent la stabilité.

Supposons, par exemple, que nous devions récupérer des données d’une API externe, puis appliquer certaines règles basées sur ces données. Nous utilisons une fermeture pour gérer l’appel API asynchrone et nous assurer que les règles sont appliquées après la récupération des données. Voici l’exemple de code :

     function fetchDataFromAPI(apiEndpoint, callback) {
      // Simulate asynchronous API call with setTimeout
      setTimeout(() => {
        // Assuming the API call is successful, we receive some data
        const data = {
          someValue: 42,
        };
        // Invoke the callback with the fetched data
        callback(data);
      }, 2000); // Simulate a 2-second delay for the API call
    }
    // Rule implementation using Closure
    function ruleImplementation(apiEndpoint) {
      // Using a closure to handle the asynchronous API call and rule application
      // say you have set this value in street field inside address panel
      var streetField = address.street;
      fetchDataFromAPI(apiEndpoint, (data) => {
        streetField.value = data.someValue;
      });
    }
    // Example usage of the rule implementation
    const apiEndpoint = "https://example-api.com/data";
    ruleImplementation(apiEndpoint);

Dans cet exemple, fetchDataFromAPI simule un appel API asynchrone à l’aide de setTimeout. Une fois les données récupérées, elle appelle la fonction de rappel fournie, qui correspond à la fermeture permettant de gérer l’application de la règle suivante. La fonction ruleImplementation contient la logique de règle.

Il est recommandé de créer si possible des formulaires adaptatifs à l’aide du modèle de données de formulaire XSD, et ce, même lors de la conversion d’un XFA en formulaire adaptatif.

Incluez uniquement les champs et les panneaux dans les formulaires adaptatifs qui capturent les informations de l’utilisateur ou de l’utilisatrice. Maintenez le contenu statique au minimum ou utilisez les URL pour les ouvrir dans une fenêtre séparée.

Bien que chaque formulaire soit conçu pour un rôle spécifique, certains segments sont communs à la plupart des formulaires. Par exemple, les informations personnelles, l’adresse, les détails du poste, etc. Créez des fragments de formulaire adaptatif pour les éléments et sections de formulaire communs et utilisez-les dans les formulaires. Vous pouvez également enregistrer en tant que fragment un panneau d’un formulaire existant. Toute modification apportée à un fragment est répercutée dans tous les formulaires adaptatifs associés. Cette fonction favorise la création en collaboration : plusieurs auteurs peuvent ainsi travailler simultanément sur différents fragments composant un formulaire.

• Comme pour les formulaires adaptatifs, il est recommandé de définir tous les scripts personnalisés et de style spécifiques aux fragments dans la bibliothèque cliente à l’aide de la boîte de dialogue du conteneur de fragments. Tentez également de créer des fragments autonomes qui ne dépendent pas d’objets extérieurs.
• Évitez d’utiliser des scripts de fragments croisés. Si vous devez désigner un objet situé hors du fragment, essayez de l’intégrer au formulaire parent. Si l’objet doit demeurer dans un autre fragment, mentionnez son nom dans le script.

Utilisez l’option Enregistrer et reprendre avec l’enregistrement automatique pour enregistrer régulièrement le formulaire adaptatif et permettre aux utilisateurs et aux utilisatrices de revenir plus tard pour le remplir.

Configurez les fragments à charger en différé. Au moment de l’exécution, le fragment qui doit être chargé en différé n’est rendu que lorsqu’il est nécessaire. Cette option permet de réduire considérablement le temps de chargement des formulaires volumineux. Elle peut également être utilisée dans des fragments avec des panneaux répétables. Pour plus d’informations, voir Configuration du chargement différé.

• Ne configurez pas le chargement différé sur les fragments dans une disposition en grille réactive ou dans le premier panneau.
• Les composants des pièces jointes et des conditions générales ne sont pas pris en charge dans les fragments chargés en différé.
• Marquez une valeur dans un panneau chargé en différé comme « Utiliser la valeur globalement » si cette valeur est utilisée dans une autre partie du formulaire afin que la valeur soit disponible lorsque le panneau de contenu est déchargé.
• Pensez à créer des règles de visibilité pour les fragments qui doivent s’afficher ou être masqués en fonction d’une condition.

Définissez la valeur de Nombre d’appels par requête dans le Servlet principal Apache Sling sur un nombre assez élevé. Cela permet au serveur Forms d’autoriser des appels supplémentaires. La configuration indique une valeur par défaut de 1 500. La valeur, 1 500 appels, correspond à d’autres composants d’Experience Manager tels que Sites et Assets. La valeur définie par défaut des formulaires adaptatifs est 20 000. Si vous rencontrez l’erreur too many calls dans les journaux ou si le rendu du formulaire échoue, essayez de définir la valeur sur un nombre plus élevé pour résoudre le problème. Si le nombre d’appels est supérieur à 20 000, cela signifie que le formulaire est complexe et qu’il peut prendre un certain temps pour générer le rendu du formulaire dans le navigateur. Cela ne se produit que lors du premier chargement du formulaire. Une fois le formulaire mis en cache, cela n’a aucun impact significatif sur les performances.

AEM Forms fournit un service de préremplissage pour lire les données d’un fichier XML de données prédéfini et préremplir les champs d’un formulaire adaptatif avec le contenu du fichier XML prérempli.

Les données XML de préremplissage doivent être conformes au schéma du modèle de formulaire associé au formulaire adaptatif.

Incluez les sections afBoundedData et afUnBoundedData dans le fichier XML prérempli pour préremplir les champs liés et non liés d’un formulaire adaptatif.

Pour les formulaires adaptatifs basés sur un modèle de données de formulaire, AEM Forms fournit un service de préremplissage de modèles de données de formulaire prêts à l’emploi. Le service de préremplissage récupère les sources de données pour les objets de modèle de données dans le formulaire adaptatif et préremplit les valeurs de champ lors du rendu du formulaire.

Vous pouvez également utiliser les formulaires adaptatifs de préremplissage de fichiers, CRX, service ou protocoles HTTP.

AEM Forms prend en charge les services de préremplissage personnalisés que vous pouvez intégrer en tant que service OSGi pour préremplir les formulaires adaptatifs.

Selon le modèle de données de formulaire sur lequel un formulaire adaptatif est basé, vous pouvez configurer un modèle de document d’enregistrement comme suit :

• Modèle de formulaire XFA  : utilisez le fichier XDP associé comme modèle de document d’enregistrement.
• Schéma XSD  : utilisez le modèle XFA associé qui utilise le même schéma XML que le formulaire adaptatif.
• Aucun  : utilisez un document d’enregistrement généré automatiquement.

Configurez l’en-tête, le pied de page, les images, la couleur, la police, etc. à partir de l’onglet Document d’enregistrement de l’éditeur de formulaires adaptatifs.

Utilisez DoRService pour générer le document d’enregistrement par programmation.

Excluez les champs masqués du document d’enregistrement.

Utilisez le paramètre de demande afAcceptLang pour afficher le document d’enregistrement dans une autre langue.

Utilisez les fragments de formulaire adaptatif pour les éléments courants des formulaires et localisez les fragments. Cela permet de traduire un fragment une seule fois et de répercuter la traduction dans tous les formulaires dans lesquels le fragment traduit est utilisé.

Les modifications telles que l’ajout d’un nouveau composant ou l’application d’un script dans un formulaire traduit ne sont pas automatiquement traduites. Par conséquent, vous devez finaliser un formulaire avant de le localiser pour éviter plusieurs cycles de localisation.

Utilisez le paramètre de requête afAcceptLang pour remplacer la langue du navigateur et pour rendre le formulaire dans la langue spécifiée. Par exemple, l’URL suivante force à effectuer le rendu du formulaire en japonais, indépendamment du paramètre régional spécifié dans les paramètres du navigateur :

https://'[server]:[port]'/<contextPath>/<formFolder>/<formName>.html?wcmmode=disabled&afAcceptLang=ja

AEM Forms prend actuellement en charge la localisation du contenu des formulaires adaptatifs vers l’anglais (en), l’espagnol (es), le français (fr), l’italien (it), l’allemand (de), le japonais (ja), le portugais du Brésil (pt-BR), le chinois (zh-CN), le chinois de Taïwan (zh-TW) et le coréen (ko-KR). Cependant, vous pouvez ajouter la prise en charge de nouveaux paramètres régionaux pour les formulaires adaptatifs à l’exécution. Pour plus d’informations, voir Prise en charge de nouveaux paramètres régionaux pour la localisation de formulaires adaptatifs.

Activez la compression de la bibliothèque client HTML pour Javascript et CSS à partir de la console Felix.

Masquez toutes les bibliothèques clientes sous /etc.clientlibs/fd et toutes les bibliothèques clientes personnalisées supplémentaires dans AEM Dispatcher pour améliorer la réactivité et la sécurité des formulaires publiés. Pour plus d’informations, reportez-vous à la section Dispatcher.

Ne mettez pas en cache les chemins d’accès /content/forms/af/ et /content/dam/formsanddocuments/*. Pour plus d’informations sur la configuration de la mise en cache de formulaires adaptatifs, voir Mise en cache de formulaires adaptatifs.

Activez le HTML via le module de compression de serveur web. Pour plus d’informations, voir Optimisation des performances du serveur AEM Forms.

Augmentez la configuration des appels par requête pour les formulaires volumineux. Voir Optimisation des performances de formulaires complexes et volumineux.

Créez des pages d’erreur personnalisées affichées par le gestionnaire d’erreur.

Sécurisez le serveur AEM Forms.

• Utilisez le mode d’exécution nosamplecontent pour vous assurer qu’aucun exemple de contenu ou d’utilisateur ne soit déployé sur le serveur de production. Voir Exécution d’AEM selon le mode prêt pour la production.

La taille du tas doit être de 8 Go au minimum. Pour connaître les autres paramètres, voir Optimisation des performances du serveur AEM Forms.

Utilisez les sessions utilisateurs du service au lieu des sessions d’administration pour exécuter les tâches au niveau du service. Pour plus d’informations, voir Authentification du service.

Stockage des données de brouillon  : si vous utilisez la fonction Brouillon des formulaires adaptatifs, vous devez implémenter une SPI (Service Provide Interface) personnalisée pour le stockage des données de brouillon dans un espace de stockage plus sécurisé comme une base de données. Pour plus d’informations, voir Exemple d’intégration d’un composant de brouillons et d’envois à la base de données.

Stockage des données d’envoi  : si vous utilisez l’envoi de stockage du portail de formulaires, vous devez implémenter une SPI personnalisée pour stocker les données d’envoi dans une base de données. Voir Exemple d’intégration d’un composant brouillons & envois à la base de données pour obtenir un exemple d’intégration.

Vous pouvez également écrire une action d’envoi personnalisée qui stocke les données de formulaires et les pièces jointes dans un espace de stockage sécurisé. Pour plus d’informations, voir Créer une action Envoyer personnalisée pour les formulaires adaptatifs.

Longueur de l’ID du brouillon  : lorsque vous enregistrez un formulaire adaptatif en tant que brouillon, un ID de brouillon est généré pour identifier de manière unique le brouillon. La valeur minimale pour la longueur du champ d’ID du brouillon est de 26 caractères. Adobe recommande de définir la longueur de l’ID du brouillon sur 26 caractères ou plus.

Utilisez en toute transparence le contrôle de version comme Git :

• L’isolation du code du contenu réduit considérablement les conflits Git lors de la gestion de contenu et favorise un référentiel bien organisé.
• Les fonctions personnalisées sont utiles pour les projets avec plusieurs contributeurs et contributrices travaillant simultanément.

Avantages techniques :

• Les fonctions personnalisées offrent la modularité et l’encapsulation.
• Les modules peuvent être développés, testés et conservés indépendamment.
• Améliore la réutilisation et la maintenance du code.

Processus de développement efficace :

• La modularité permet aux développeurs et développeuses de se consacrer aux fonctionnalités spécifiques.
• Réduit la charge des développeurs et développeuses en réduisant la complexité de l’ensemble de la base de code pour un processus de développement plus efficace.