Algo de checklist pour wizard

[srm]

Cette lib n'existe pas, faire ton propre truc n'est pas bien compliqué.
Soit tu as un scénario du type :
si pas de pseudo : demander pseudo
si pas de classe : demander class
si pas de continent : demander continent
etc..

Donc tu as une liste de truc à demander dans un ordre précis et ça stocké en base et tu déroules le scénario 1 à 1.
Si c'est un autre type de scénario même chose.

[niahoo]

Cette lib n'existe pas

ok ! les autres, rien non plus ?

Je me la ferai dans ce cas mais ça m'étonne quand même ...

[srm]

Bah c'est déjà pas très courant et de manière générale pas très utile, les gens codent en dur leur mini truc vite fait.
On fait pas trop comme ça sur le web normalement ^^

Si tu veux trouver des trucs tu cherche form multi page sur google, tu trouveras plein de trucs

[Sephi-Chan]

C'est vrai que j'aurais tendance à coder ça moi-même, en utiliser mes petits contrôleurs RESTful et une ou plusieurs tables pour stocker les états.

Ce qui pourrait être amusant (toute mesure gardée) serait que tu nous décrives précisément un processus avec ses différents embranchements, et on pourrait réfléchir à son implémentation, et même faire un prototype. Un cas vraiment concret et un minimum complexe.

[niahoo]

via MP

mais en gros il s'agit de créer n'importe quel contenu, et que pendant ce processus on puisse demander à l'utilisateur de s'enregistrer ou de se loguer. Il faut aussi, pendant le processus, créer d'autres contenus.

Mettons que vous créez un article, qu'il inclut des dessins, et que pour pouvoir faire des dessins pour les mettre dans l'article il faille être loggué.

[Ter Rowan]

perso, mais je suis pas un "à la pointe"


je ferais tout ça par session pour le stockage de données (après tout doit pas y en avoir des masses, et le gars n'a pas besoin d'être identifié pour commencer

on démarre le wizard

et après, défini quelque part,

1) ordre des états
2) à chaque "état", la liste des prérequis (login != NULL, etc...)

à chaque appel serveur,

initialisation état = état 0
boucle tant que état existe :
si tous les prérequis de état sont validés passage au suivant
sinon envoi du {questionnaire ou que sais je} de l'état concerné

[niahoo]

Oui c'est ce que je fais plus ou moins mais c'est dans la modélisation que je pêche.

Mais j'avance un peu.

Pour ce qui est de la session / cookie / db / etc. ce n'est pas important, ça revient plus ou moins au même

Bon j'en suis passé par les FSM (finite state machine) seulement ça ne convenait pas. Je suis en train de partir sur un truc un peu inverse à la FSM, malheureusement je n'arrive pas à mettre un nom dessus ce qui me permettrait surement de trouver une implémentation déjà existante.

La FSM a un état interne privé, quand on lui envoie un signal, elle effectue des actions puis change (ou pas) d'état et c'est tout.

Tandis que ce que je fais c'est l'inverse, c'est plus simple aussi, les différents états modélisent juste un algo, la seule chose que l'on fait c'est d'envoyer l'état initial et de le récupérer à la sortie.

Est-ce que vous savez si un pattern ressemble à ça ?

[niahoo]

Bon ben je l'ai implémenté à moitié et ce design pattern est mauvais car c'est en fait une abstraction d'algorithme. ça n'apporte que de la syntaxe allégée mais ça prive de tout ce qui n'est pas réimplémenté. inutile.

Je pars plutot sur une checklist de prérequis, ça sera très simple à faire et ça devrait faire le taf.

[Sephi-Chan]

Il y a moyen de voir ce que ça donne (en terme de code) ou bien c'est sensible ?

[niahoo]

Heu non c'était pas sensible mais j'ai tout balancé. En gros ça ressemblait à l'implémentation d'un DSL très simpliste (car c'est ce que c'était) à l'arrache et avec la syntaxe de php (des parenthèses et des flèches partout). Et ça faisait pas grand chose.