Logique de formulaire

  • Rversion finale: Xanadu
  • Mis à jour 1 août 2024
  • 2 minutes de lecture

    • Le contrôle de ce que les utilisateurs voient lorsqu’ils visitent un formulaire peut augmenter la productivité et la réactivité. Par exemple, les utilisateurs ne doivent voir que les champs qui leur sont utiles. Les utilisateurs peuvent avoir uniquement besoin de voir certains champs en fonction de ce qui est configuré dans le formulaire. Appliquez la logique de formulaire pour contrôler ce qui est visible, en lecture seule et obligatoire dans un formulaire.

    La question suivante vous aidera à prendre la bonne décision quant au moment de contrôler l’accès des utilisateurs à l’information : S’agit-il d’une suggestion ou d’une application ? Une suggestion rend le formulaire plus facile à remplir, tandis que l’application oblige l’utilisateur à faire quelque chose pour remplir le formulaire.

    Les politiques d’interface utilisateur sont utiles pour les suggestionsconditionnelles telles que l’affichage et le masquage de champs ou l’ajout de messages de champ basés sur la valeur d’un autre champ, tandis que les politiques de données et les règles métier sont mieux adaptées pour l’applicationconditionnelle comme rendre un champ obligatoire.

    La meilleure expérience utilisateur consiste à utiliser à la fois la suggestion et l’application.

    Pour plus d’informations, consultez l’article Politique d’interface utilisateur dans le module Scripting côté client.

    Créez des politiques d’interface utilisateur et des politiques de données pour gérer les activités côté client avant de scripter une logique côté client. Utilisation de scripts clients pour valider l’entrée de l’utilisateur et fournir des commentaires pendant que l’utilisateur remplit le formulaire.

    Voici quelques pratiques générales relatives au scripting client :

    • Optimisez les performances en utilisant GlideAjaxasynchrone sur GlideRecordcôté client ou plusieurs appels getReference().
    • Conservez la vérification isLoadingdans les scripts clients onChange.
    • Conservez la vérification newValueet ajoutez une vérification newValue != oldValue.
    • Utilisez tous les scripts côté client possibles avant d’effectuer un appel de serveur avec GlideAjax. Les allers-retours du serveur peuvent avoir un impact sur les performances.

    Voici quelques pratiques de scripting client à éviter :

    • Scripts clients globaux ou scripts d’interface utilisateur globaux : les scripts globaux s’exécutent à chaque chargement de page et introduisent un délai de chargement du navigateur.
    • Manipulation DOM : l’utilisation de la manipulation du modèle d’objet de document par rapport aux éléments d’interface utilisateur par défaut introduit des problèmes de risque de mise à niveau et de maintenabilité. L’exception est l’utilisation de la manipulation DOM par rapport au DOM dans les pages créées dans la même application incluse dans le périmètre, comme les pages de l’interface utilisateur ou les widgets du portail de services.