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’actionShow 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 conditionnelElse
. 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 blocElse
.
- La règle comportant l’action
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’actionStop 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 actionExecute 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 !