Contrôler 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 besoin d’afficher uniquement certains champs en fonction de ce qui est configuré sur le formulaire. Appliquez une 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 des 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 effectuer une 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. Utilisez des 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 en matière de 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 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 des données mensuelles (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 risques de mise à niveau et des problèmes de maintenabilité. L’exception est l’utilisation de la manipulation des données mensuelles par rapport aux données mensuelles 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.