Mise à jour du "lastReachedPage" plus réactif

[Grafikart]

Contexte

lastReachedPage permet de mémoriser la dernière page atteinte dans un formulaire. Cette valeur est mis à jour dès que l'utilisateur dépasse le précédent lastReachedPage lors de la navigation.

Problème

L'implémentation actuelle ne prévoit pas que cette valeur puisse décroître, ce qui pose des problèmes dans plusieurs situations :

• Si l'utilisateur change une réponse en amont qui révèle une nouvelle page entre la page courante et le lastReachedPage.
• Si l'utilisateur change une réponse en amont qui masque la page marquée par le lastReachedPage.
• Si l'utilisateur change une réponse qui change le nombre d'itération d'une boucle future :
  • Si le lastReachedPage était sur une sous page de la boucle qui n'existe plus alors il doit avancer.
  • Si une itération est ajoutée le lastReachedPage doit venir se placer au début de cette nouvelle itération.

Il y a donc plusieurs souci pour implémenter un lastReachedPage qui soit plus dynamique :

• Déterminer dans laquelle des 4 situations précédentes on se trouve lors d'un changement de valeur.
• Déterminer où il faut aller et surtout dans quelle direction faire évoluer le lastReachedPage.

Idée 1 : page attendant une réponse

Une première idée exprimée par l'issue #1026 est d'avoir un concept de "page avec réponse manquante" et de plutôt utiliser ce concept pour déterminer la dernière page atteinte par l'utilisateur. Cette solution possède malheureusement aussi des problème :

• On doit parcourir l'ensemble des pages à partir de la page courante à chaque changement de variable pour obtenir la valeur (calcul potentiellement lourd)
• Certains champs ne sont pas obligatoire mais on ne le sait pas nécessairement sans exécuter tous les conditionFilter / control. Le problème devient particulièrement complexe lors d'une boucle non paginée pour déterminer si elle attend une réponse ou non.

Idée 2 : conditionFilter au niveau page

Une seconde idée serait d'associer à chaque page une condition d'affichage (comme un conditionFilter mais au niveau de la page). Avec cette approche on pourrait calculer plus facilement si une page est atteignable ou non. Cela implique tout de même d'avoir de nombreux calcul de fait à chaque changement de valeur de variables.

[ddecrulle]

Au moment de la génération, il est possible de déduire les différents champs de réponse qui créent un changement de navigation (décrits dans les problèmes ci-dessus) et de connaître à l'avance les pages concernées. Ainsi, on pourrait exécuter les calculs nécessaires uniquement lors des changements de ces valeurs spécifiques et calculer la valeur appropriée de lastReachedPage.

Voici une première réflexion sur la structure de ce processus :

{
    "componentType": "Input",
    //...
    "response": {
        "name": "RESPONSE_VARIABLE"
    },
    "effect": {
        "page": { "from": "", "to": "" }, // Le PageTag des pages affectées sachant que l'on peut avoir un from sans to et inversement
        "filter": [
            { "variableName": "Nom de la variable de filtrage", "page": "{la page de ce filtre}" }, // Supposant que les filtres de condition sont toujours des variables calculées (ce qui n'est pas le cas aujourd'hui)
            { "variableName": "Nom de la variable de filtrage", "page": "{la page de ce filtre}" }
        ]
    }
}

En utilisant cette approche, nous pourrions mieux gérer les changements de navigation et rendre lastReachedPage plus dynamique et réactif aux différentes situations rencontrées par l'utilisateur.

[BulotF]

Si la page courante est inférieure au lastReachedPage, alors on analyse les cleaning et resizing avec l'ancienne et la nouvelle valeur de la variable modifiée.

On peut ainsi calculer la liste des variables qui deviennent visibles. Si l'une d'entre elles est avant lastReachedPage, on le met à jour...

[laurentC35]

Une approche naïve et peu couteuse pour l'idée 1 serait de ne rien faire côté Lunatic et de laisser l’orchestrateur gérer ça:

• le bouton suite de l'entretien reviendrait à faire goNext tant que la page courante contient des réponses

Avantage:

• solution très peu couteuse, rien à faire côté Eno ou Lunatic
• robuste: à partir du moment où le booléen indiquant si la page a au moins une réponse répond bien

Inconvénient:

• un peu lent, oblige l’utilisateur à "attendre", mais ça peut apparaître comme acceptable
• peu élégant niveau algo

[AnneHuSKa]

@romaintailhurat @QRuhier : réflexions MOAE et DSDS en cours sur le fonctionnel proposé