Aller au contenu principal

Réponses possibles

Définition

Les réponses possibles traduisent les contraintes sur les réponses que l'utilisateur peut donner.

Détails

Les réponses possibles portent le nom de la variable qui sera utilisée par le template Twig pour générer le contrat.

Ces contraintes changent en fonction du type de question:

  • pour une question fermée les contraintes sont:
    • choix que l'utilisateur peut faire, avec un texte à afficher dans le bouton
    • des paramètres minimum et maximum sur le nombre de sélections peut faire l'utilisateur
      • 1 seul choix dans le cadre d'un booléen: il s'agit de réponse vrai ou faux à la question
      • 1 seul choix dans le cadre d'un single
      • éventuellement un nombre de choix maximum dans le cadre d'un multiple
  • pour une question ouverte les contraintes sont:
    • minimum: valeur minimale pour un int et nombre minimal de caractères pour une string
    • maximum: valeur maximale pour un int et nombre maximal de caractères pour une string
attention

Je ne sais plus pourquoi j'ai mis les contraintes au niveau des possibleAnswers. C'est plutôt au niveau des questions car c'est bien la question qui porte la contrainte dans le cadre d'un choice.

Représentation en base de données

Structure d'une réponse possible:

  • id: (int) identifiant unique de la réponse possible
  • text: (?string) texte d'affichage de la réponse. Il s'agit du texte du texte du bouton pour un choiceou un booléen ou du texte du placeholder (optionnel) pour une question ouverte.
  • section: (string) nom de l'objet json qui sera renvoyé à la vue Twig.
  • field: (string) nom de la propriété de l'objet json qui sera renvoyé à la vue Twig.
  • min: (?int) représente un contrainte minimale (voir la section §Détails).
  • max: (?int) représente un contrainte maximale (voir la section §Détails).
Précisions sur les propriétés de la section et des field

Le couple section.field doit être unique au sein d'un questionnaire modèle donné. Plusieurs questionnaires différents peuvent utiliser les mêmes noms de section.field.

Dans le cas particulier d'un booléen, celui-ci aura une convention spécifique:

  • la première entrée dans les possibleAnswers aura pour field un nom formé de isTrue (par exemple: insurance.subbieIsCoveredTrue)
  • la seconde entrée dans les possibleAnswers aura pour field un nom formé de isFalse (par exemple: insurance.subbieIsCoveredFalse)

Cette convention particulière est nécessaire pour une gestion homogène des transitions, tout en évitant le risque d'utiliser 2 variables identiques et des erreurs d'affichage dans la vue du contrat.

Relations des réponses possibles:

  • questions: une réponse possible n'appartient qu'à 1 et 1 seule question – une question possède 1 à n réponses possibles. On doit pouvoir récupérer l'ensemble des réponse possibles lorsque l'on appelle une question.
  • givenAnswers: une givenAnswer référence toujours une possibleAnswer. Une réponse possible possède 0 à n réponses données – 1 réponse donnée référence 1 et 1 seule réponse possible.
  • transitions: une transition part d'une réponse possible pour aller à une childQuestion. Une réponse possible peut avoir 0 à n transitions – une transition dispose de 0 à 1 réponse possible (cas de la transition initiale: une transition initiale n'a pas de possible answer référencée, elle ne peut avoir que des conditions – sinon, une transition a toujours une réponse possible).
  • conditions: une réponse possible peut être référencée 0 à N fois dans les conditions – une condition ne porte que sur 1 et 1 seule réponse possible