Documentation en ligne

Utiliser les conditions

Les conditions sont des formules qui vont se réveler vraies ou fausses, on va pouvoir les utiliser pour :

  • afficher (ou pas) un champ ou une page
  • permettre (ou pas) de quitter une page
  • déclencher (ou pas) une action de workflow

Il ne faut pas confondre les conditions avec les gabarits qui eux produisent du texte (même s'il y a des usages approchant comme les filtres)

Pour vérifier qu'une condition fonctionne quelle qu'elle soit, il est souvent très utile de consulter les pages d'inspection.

Les exemples qui suivent respectent la syntaxe Django, qui est celle qui devra être utilisée par défaut. Historiquement, les conditions étaient écrites en langage Python. Vérifiez que c'est bien la syntaxe Djanqo qui est sélectionnée dans votre condition (à côté de l'engrenage), si vous souhaitez utiliser ces exemples.

Condition sur les dates

Les conditions sur les dates sont monnaie courante et assez spécifiques.

Si nous avons un champ date ayant comme identifiant « date »,  nous utiliserons form_var_date|date pour obtenir une chaîne de caractère utilisable dans l'écriture des conditions. Par ailleurs la variable today est un objet date qui contient la date du jour. il faudra lui aussi le transformer en une chaîne de caractère à l'aide du filtre |date pour l'exploiter dans l'écriture des conditions. Quelques exemples :

  • On peut faire varier la façon dont une date va s'afficher grâce à des paramètres du filtre |date. Par exemple avec la variable today (qui contient la date du jour), on aura :
{{ today|date:"Y-m-d" }} --> affiche la date au format ISO, par exemple 2019-02-25

{{ today|date:"d/m/Y" }} --> affiche la date au format plus habituel 25/02/2019
  • On pourra souhaiter ne récupérer que :
    • L'année : today|date:"Y"
    • Le mois : today|date:"m"
    • Le jour : today|date:"d"
  • Pour vérifier qu'une date est postérieure à la date du jour on écrira form_var_date|date > today|date : cette condition sera vraie si la date de la variable est postérieure à la date du jour.

  • Pour vérifier qu'une date 1 est postérieure à une date 2 on écrira form_var_date1|date > form_var_date2|date : cette condition sera vraie si la date 1 est postérieure à la date 2.

  • |add_days va permettre de soustraire ou d'ajouter des jours à une date. Pour déclencher une action 2 jours avant une date particulière (vérifier qu'on est à deux jours ou moins d'une échéance), on écrira par exemple form_var_date|date|add_days:-2 >= today|date : cette condition deviendra vraie deux jours avant la date de la variable, elle sera fausse jusqu'à -2 jours avant la date de la variable.

  • Pour vérifier que la date se situe à plus de 30 jours avant la date du jour, on écrira form_var_date|date|add_days:30 <= today|date : cette condition sera vraie si la date de la variable est inférieure de 30 jours ou plus à la date du jour, fausse sinon.

  • Le même type de calcul est possible en se basant sur un délai lié à un nombre d'heures. On utilise alors form_var_date|add_hours:3 (on ajoute 3 heures à la date sélectionnée).

Pour plus d'informations sur les filtres date dans Publik consulter la section filtres sur les dates et pour creuser encore plus loin consulter la documentation Django pour une référence complète concernant l'utilisation du filtre date et du filtre time.

Calculs

Les données tirées d'un formulaire, d'options de workflows, etc.  sont des chaînes de caractères. Pour en faire des nombres, aptes aux opérations arithmétiques, il faut les entourer de Decimal().

Pour calculer un prix total, fruit de la multiplication d'un coût (mis en option dans le formulaire) et d'un nombre d'exemplaires (renseigné par l'usager dans le formulaire) on aura :
  Decimal(form_option_cout_unitaire) * Decimal(form_var_nbre_exemplaire)

Comme l'objectif peut ensuite être de mettre le résultat du calcul dans un champs, il faut, après le calcul, faire la conversion inverse, retourner de décimal à chaine de caractères. Ainsi :
  str( Decimal(form_option_cout_du_document) * Decimal(form_var_nbre_exemplaire) )

Lorsque vous utilisez des nombres décimaux directement dans vos calculs, prenez bien garde d'utiliser le point et non la virgule comme séparateur.

Utiliser une liste à choix multiples

Mettons une telle liste, avec des valeurs simplement définies dans le backoffice (i.e. pas de source de données), l'identifiant du champ est mis à foobar.

Mettons une demande remplie, avec deux éléments cochés.

On va avoir comme variables form_var_foobar : "pomme, poire" (type chaine de caractère)

  •  voir si l'élément « poire » a été coché :

   "poire" in form_var_foobar

  •  voir si l'élément « poire » n'a pas été coché :

   "poire" not in form_var_foobar

  •  évidemment ça marche aussi pour plusieurs cases à cocher, voir si  les éléments « poire » ET « pomme » ont été cochés :

  "poire" in form_var_foobar and "pomme" in form_var_foobar

  •  ou bien voir si l'un ou l'autre élément a été coché :

   "poire" in form_var_foobar or "pomme" in form_var_foobar

  •  et de manière générale, toutes les opérations possibles sur les ensembles peuvent également avoir lieu en passant par le type approprié (set) et donner des expressions plus lisibles que des successions de and/or etc.

Conditionner la valeur d'une variable (if... else)

Prenons l'exemple d'une démarche que l'on peut faire pour soi ou pour le compte d'un tiers. On pose une question dont la réponse est stockée dans form_var_nature_demande (c'est soit « Me concerne », soit « Concerne quelqu'un d'autre »).

En fonction de la réponse, je veux stocker dans une donnée de traitement « Commune » (form_var_commune),  la commune de la personne concernée (information demandée sur une page particulière) ou la commune du demandeur (demandée sur une autre page). Lorsque la demande est faite pour un tiers, il faut prendre la commune de la personne concernée, la commune du demandeur sinon. Pour modifier la valeur d'une donnée de traitement form_var_commune, on va écrire sous forme de gabarit Django :

{% if form_var_nature_demande == "concerne quelqu'un d'autre" %} {{form_var_commune_personne_concernee}}{% else %} {{form_var_commune_demandeur }}{% endif %}

Les champs d'un formulaire sont tous définis, même si l'usager n'est pas passé par la page contenant tel ou tel champ. Nos deux variables form_var_commune_personne_concernee et form_var_commune_demandeur existent donc toujours.

Dernière mise à jour le 31 mai 2019 18:03 — Éditer