Contrôle du flux à l'aide de conditions

Des conditions peuvent être utilisées pour contrôler le flux d'un utilisateur dans un script IEG. La progression d'un utilisateur par le biais d'un script IEG va suivre un chemin linéaire d'une page à l'autre dans le script, sauf si vous, en tant qu'auteur du script, décidez de modifier ce flux. La raison principale pour laquelle ce flux peut être modifié consiste à vouloir s'assurer que les utilisateurs ne reçoivent pas des questions inutiles ou non pertinentes. Les réponses d'un utilisateur doivent permettre de déterminer si les questions lui sont associées ou non. Par exemple, une page peut capturer des informations détaillées sur l'enseignement supérieur d'une personne. Cette page ne doit pas s'afficher pour l'utilisateur s'il a déjà indiqué n'avoir jamais fait d'études. Pour y parvenir, vous pouvez entourer une ou plusieurs pages d'un élément de condition pour indiquer dans quelles conditions cette page (ou ces pages) doit s'afficher ; par exemple :

Figure 1. Elément de condition
<condition expression="attendedThirdLevel==true">
  <question-page id="ThirdLevelDetailsPage">  
    ...
  </question-page>
</condition>

Lorsque l'utilisateur clique sur le bouton Suivant sur la page précédant cette condition, le système évalue l'expression 'attendedThirdLevel==true'. S'il l'évalue comme ayant la valeur true, la ou les pages de la condition s'afficheront pour l'utilisateur ; si elle est définie sur false, le système ignore la ou les pages et affiche la page suivant l'élément de condition.

Dans cet exemple, attendedThirdLevel correspond à l'ID d'une question posée plus tôt dans ce script de contrôle. La réponse donnée sera utilisée dans l'évaluation de l'expression. Si vous souhaitez plutôt utiliser la valeur d'un attribut dans le magasin de données, vous devez lui attribuer en préfixe le nom de l'entité dans laquelle il se trouve (par ex. Person.attendedThirdLevel).

Lors de l'utilisation d'expressions sur les conditions (ou ailleurs), vous devez vous assurer que tous les attributs utilisés dans l'expression auront une valeur réelle au moment où ils sont évalués. Par défaut, les attributs dans le magasin de données sont Null jusqu'à ce qu'une valeur ait été définie pour eux, et ils garderont ce statut si l'utilisateur n'entre pas ou ne choisit pas de valeur pour la réponse appropriée.

En règle générale, deux façons permettent de s'assurer que les attributs ont des valeurs avant d'être utilisés dans des expressions : rendre obligatoires les questions qui les remplissent ou leur donner des valeurs par défaut dans votre schéma de magasin de données (vous pouvez également utiliser l'élément définir-attribut dans certains cas, voir définir-attribut).

Des conditions peuvent contenir toute combinaison de pages (y compris des pages de synthèse), boucles et autres conditions. Par exemple :

Figure 2. Condition imbriquée
<condition expression="attendedThirdLevel==true">
  <question-page id="ThirdLevelDetailsPage">
    ...        
  </question-page>
  <condition expression="hasMasters==true">
    <question-page id="MastersDetailsPage">
      ...        
    </question-page>
  </condition>
</condition>

Cela signifie que ThirdLevelDetailsPage ne s'affichera que si la réponse attendedThirdLevel est true, et MastersDetailsPage ne s'affichera que si attendedThirdLevel est true et hasMasters également.

Il est également possible d'appeler une fonction personnalisée à partir d'une condition ou d'une autre expression. Les informations sont automatiquement fournies à la fonction pour accéder au magasin de données, par exemple l'ID d'entité racine, l'ID d'exécution du script et actuellement l'ID d'entité (si la condition est dans une boucle). Il convient de noter que les fonctions personnalisées qui ont un effet secondaire (par exemple pour alimenter certaines réponses dans le magasin de données) ne doivent pas être utilisées dans de telles expressions, car elles ne seront pas nécessairement évaluées avant le chargement du contenu de la page.

La fonction personnalisée isNotNull est prête à l'emploi dans IEG, afin de permettre aux expressions de traiter les valeurs NULL en tant que paramètres. Par exemple, pour valider la date de naissance d'une personne, il peut d'abord s'avérer nécessaire de s'assurer qu'une valeur existe :

Figure 3. Utilisation de la fonction personnalisée 'isNotNull'
<validation expression="
      isNotNull(Person.dateOfBirth)
      and isNotNull(Person.today)
      and (subDates(Person.dateOfBirth, Person.today) < 0)">
    <message id="DateOfBirthValidation">
      Votre date de naissance doit être antérieure à la date actuelle
    </message>
</validation>