Traitement des événements avec des ensembles d'actions
Une interface utilisateur (UI) peut inclure des contrôles qui permettent aux utilisateurs de compléter certaines actions avant d'envoyer un formulaire, afin de rendre l'expérience utilisateur plus interactive.
Le modèle événement-action
Les contrôles actionnables sont basés sur un modèle événement-action, qui établit une relation de cause à effet pour des contrôles comme une case à cocher ou un bouton. L'événement (event) est un déclencheur (trigger) actionné par l'utilisateur, comme un clic sur un bouton ou une saisie dans un champ. L'action est une réponse de l'application, telle que la création d'un dossier ou l'affichage d'informations sur un champ pour guider l'utilisateur.
Prenons un exemple : un commerçant en ligne souhaite permettre à ses clients d'utiliser l'adresse d'expédition d'une commande comme adresse de facturation. Le formulaire de saisie de l'adresse de facturation comporte une case à cocher. Si l'utilisateur coche cette case, l'application copie les informations de l'adresse d'expédition dans les champs de l'adresse de facturation et désactive la modification des champs correspondant à l'adresse de facturation. Si l'utilisateur décoche la case, l'application vide les champs de l'adresse de facturation et permet à l'utilisateur de saisir une adresse.
Au centre de l’image suivante, faites glisser la ligne verticale pour voir comment l'affichage du formulaire d'adresse évolue lorsque l'utilisateur coche ou décoche la case en question.
Le tableau suivant présente des exemples de paires événement-action.
Evénement | Action |
---|---|
Clic sur un contrôle, tel qu’un bouton, un lien ou une icône | Ouverture d’une nouvelle fenêtre |
Double clic sur une ligne de la grille | Permet de modifier le contenu de la ligne concernée |
Pression sur la touche Entrée du clavier | Affichage d'un menu |
Sélection d'une valeur dans une liste de régions ou de provinces | Mise à jour de la liste de localisation des bureaux |
Saisie d’une valeur dans le champ Quantité | Vérification du stock pour honorer une commande |
Ensembles d’actions
Dans une application Pega Platform™, vous utilisez un ensemble d’actions pour configurer un contrôle actionnable. Un ensemble d'actions (action set) est constitué d'un ou de plusieurs événements et d'une ou de plusieurs actions. Vous pouvez également associer des conditions à chaque action afin que l'action ne se déclenche que lorsque les conditions sont remplies.
Dans l'image suivante, cliquez sur les icônes + pour découvrir comment un ensemble d’actions peut déclencher le remplissage des champs d'adresse de facturation sur un formulaire lors de l'envoi d'une commande à un commerçant en ligne.
Vérifiez vos connaissances avec l’interaction suivante :
Optimisation d’un ensemble d’actions
Lors de la configuration d’un ensemble d’actions (action set), tenez compte de la façon dont l’expérience utilisateur et les données sont affectées par les actions d’actualisation et les appels au serveur. Par exemple, le flux utilisateur est interrompu lorsque l’utilisateur doit attendre qu’un écran s’actualise (refresh) ou revenir manuellement à un écran précédent.
Actualisez une section lorsque :
- Les valeurs de propriété sont mises à jour sur le serveur et l’interface utilisateur doit refléter les nouvelles valeurs.
- Une action entraînant une modification de plusieurs propriétés se produisant uniquement sur le client, telle que la suppression d’une ligne, doit être soumise.
- Certaines parties de l’interface utilisateur doivent être supprimées du modèle DOM (Document Object Model) en raison d'une autre entrée.
N’actualisez pas une section lorsque :
- Vous devez soumettre une saisie utilisateur. À la place, utilisez une action Post value.
- Vous devez appeler une data transform ou une activité après une action utilisateur.
- Vous devez recalculer la visibilité (visibility), l’état activé/désactivé (enabled/disabled) ou l’état lecture seule (read-only). Sélectionnez la case Evaluate on client à côté du champ de l’expression.
Utilisez une action Refresh When dès que possible pour déclarer les dépendances. Pour conserver des données exactes, utilisez une action Refresh When pour les références en lecture seule qui doivent rester synchronisées avec les données sur le serveur. Par exemple, actualisez une section Informations de l'hôtel qui doit être mise à jour uniquement lorsque l’emplacement de l’hôtel change.
Lorsqu’il n’est pas possible d’utiliser une action Refresh When, utilisez une action Refresh Other Section, qui est une actualisation ciblée. Par exemple, si vous avez des références modifiables qui sont mises à jour en fonction d’autres entrées ou en fonction d’entrées non traçables, telles que des clics de bouton, utilisez Refresh Other Section.
Consolidation des actions dans l’ensemble d’actions
Chaque action de l’ensemble d’actions (action set) génère au moins une requête HTTP au serveur et s’exécute dans l’ordre séquentiel de configuration. Pour optimiser les actions et réduire le nombre de requêtes HTTP au serveur, reportez-vous aux bonnes pratiques suivantes :
- Si les pre-activity et pre-data transform s'exécutent dans le même contexte que l’actualisation de section, configurez-les dans l’action Refresh section.
- Modifiez le contenu de pre-activity si nécessaire lors de son exécution dans le contexte de Refresh section.
- Utilisez Wrapper Activity ou Wrapper Data Transform pour consolider toutes les actions.
Au centre de l’image suivante, faites glisser la ligne verticale pour voir comment les actions d’un ensemble d’actions peuvent être consolidées dans Wrapper Activity.
Différencier les Post actions des Refresh section actions
Par défaut, une action Refresh section renvoie au serveur toutes les modifications en attente appliquées à un formulaire. Il est inutile d'utiliser une action Post value avant une action Refresh section , par exemple Refresh This Section.
Une action Post value actualisera le serveur et forcera toutes les conditions Refresh When à réévaluer. Une action Post value peut affecter plusieurs sections en utilisant les conditions when. Utilisez une action Post value au lieu d’utiliser une Refresh section pour chacune de ces sections. Utiliser une action Post value pour actualiser toutes les sections permet aussi d’éviter de coder en dur le nom de la section dans l’ensemble d’actions lors de l’utilisation de Refresh Other section.
Par exemple, dans une application d’achat de véhicule, un utilisateur saisit son ID client pour afficher des accessoires supplémentaires. Lorsque la valeur de l’ID client change, les conditions de deux sections sont évaluées par rapport aux données client stockées, telles que le statut d’adhésion Elite, la durée d’adhésion active et le nombre total d’achats de véhicules. La section Exclusive lifestyle accessories s’actualise uniquement lorsqu’un identifiant client valide est associé à un utilisateur qui a acheté au moins trois véhicules. La section Elite car accessories s’actualise uniquement lorsqu’un identifiant client valide est associé à un utilisateur qui est un membre Elite actif depuis plus de dix ans.
Au centre de l’image suivante, faites glisser la ligne verticale pour comparer la vue qui s’affiche pour un utilisateur invalide à la vue qui s’affiche pour un membre Elite :
This Topic is available in the following Module:
Want to help us improve this content?