K2 Smartforms : demander confirmation à l’utilisateur

Il est courant lorsque l’on développe une application, de devoir demander la confirmation de l’utilisateur avant de réaliser une action ou série d’actions. Par exemple, lorsque notre utilisateur clique sur le bouton « Annuler » d’un formulaire, lui afficher un message lui demandant « Êtes-vous sûr de vouloir annuler votre demande ? », afin d’éviter d’annuler directement une demande qu’il aurait mis du temps à renseigner, simplement parce qu’il a cliqué par inadvertance sur le mauvais bouton 

Dans cet article, nous allons voir comment les K2 Smartforms nous facilitent la vie pour gérer ces cas de figure.

Il y a trois possibilités pour demander la confirmation d’un utilisateur en Smartforms, deux « out of the box », avec quelques limites sur la personnalisation de la fenêtre, et une troisième qui nécessite un peu de conception (rassurez-vous, pas de code !), mais qui offre donc plus de liberté en matière de présentation.

Action « Get confirmation from user »

Première technique, depuis une règle smartforms, ajouter une action dont le nom ne laisse pas de place au doute : Get confirmation from user.

C’est la méthode la plus basique, elle vous permet de faire apparaître à l’écran une pop-up dont vous pouvez spécifier le titre, et le message (avec mise en forme HTML éventuellement), uniquement en dur.

Pour intégrer des champs dynamiques dans vos messages pop-up, il faudra utiliser l’une des deux autres façons de procéder.

Très bien, nous avons configuré notre action :

Voilà à quoi elle ressemble à l’exécution :

Maintenant, comment configurer correctement ma règle pour obtenir un comportement différent, dans la même règle, selon qu’on a cliqué sur OK ou sur Cancel ?

Vous allez voir, c’est très simple mais ça mérite une explication :

• Lorsque l’utilisateur clique sur le bouton OK, la règle poursuit normalement son exécution, un peu comme si on avait affiché une pop-up avec l’action Show a message.
• En revanche, quand l’utilisateur clique sur le bouton Cancel, il y a deux possibilités
  • La règle comportant l’action Get confirmation from user ne contient pas de bloc conditionnel Else. Dans ce cas, la règle s’arrête tout bonnement après le message de confirmation.
  • Si la règle contient un bloc Else, alors elle n’exécute pas les actions après la confirmation et saute directement aux actions dans le plus proche bloc Else.

Ce mode de fonctionnement soulève tout de même un léger problème : pour avoir un comportement spécifique, autre que de simplement arrêter l’exécution de la règle, lorsqu’on clique sur le bouton Cancel, il nous faut absolument un bloc Else. Et pour avoir un bloc Else dans une règle, il nous faut une condition préalable, autrement le Designer ne nous laissera pas, et à juste titre, enregistrer notre règle.

Lorsque l’on ne souhaite pas vérifier de condition avant de demander confirmation à l’utilisateur, le moyen de contournement consiste donc à ajouter une condition toujours vraie à notre règle, dans laquelle on placera la demande de confirmation ainsi que les instructions à exécuter en cas de clic sur OK, puis les instructions à exécuter en cas de clic sur Cancel dans le bloc Else, qui sera bien accepté par le Designer cette fois.

Action « Show a message »

Avez-vous remarqué que l’instruction Show a message to the user permet de choisir le type de message à afficher à l’utilisateur ? Nous avons le choix entre Default, Error, Info, Warning, None et Confirmation, qui est naturellement l’option à sélectionner pour pouvoir demander la confirmation de l’utilisateur.

Une fois le Message Type Confirmation sélectionné, le principe de fonctionnement est exactement le même que pour l’action “Get confirmation from user” d’un point de vue exécution de la règle. En revanche, nous avons un peu plus de liberté sur la customisation du message que l’on souhaite afficher à l’utilisateur : nous disposons de trois champs de saisie pour donner un titre à notre message Title, une entête Heading et un corps de message Body, dans lesquels nous pouvons ajouter des variables provenant du context browser. Les champs Heading et Body peuvent également gérer de la mise en forme HTML grâce à leurs cases à cocher Literal.

Voilà l’allure de ma pop-up à l’exécution :

Utiliser une subview ou un subform

Enfin, la dernière méthode possible pour demander la confirmation d’un utilisateur, est de tout bonnement se créer sa propre vue, voire son propre formulaire, qui sera utilisé comme subview (ou subform). La liberté ici est donc totale sur l’allure de votre pop-up, les libellés des boutons, etc. Mais nécessite logiquement un peu de conception. Je ne vais pas épiloguer sur cette option, qui pourrait faire l’objet d’un article à part entière, néanmoins voici quelques indications pour parvenir à un résultat probant :

• Utilisez l’action Stop the rule execution, qui comme son nom l’indique, permet d’interrompre l’exécution de la règle avant d’arriver au bout de toutes ses instructions.
• L’action Execute another rule est elle aussi extrêmement pratique. A noter que l’action Stop the rule execution interrompt non seulement la règle qui l’appelle, mais si la règle en question avait été déclenchée par une action Execute another rule d’une règle parente, elle sera interrompue également !
• Vous pouvez également utiliser des champs cachés sur votre formulaire qui appelle votre subview (ou subform) pour garder en tête sur quel bouton aura cliqué votre utilisateur et donc adapter votre traitement

Avec ces trois astuces combinées, vous pourrez définir des comportements bien plus complexes que ce que vous pourriez faire avec les options Get confirmation from the user ou Show a message.

En ce qui me concerne, je reste assez simple lorsque je me crée une fenêtre personnalisée. Je me contente d’une vue avec un Data Label en mode Literal, de deux boutons, et de quelques paramètres, comme par exemple la langue dans laquelle je souhaite afficher mon message.

C’est tout pour cette fois, see you next week !