Algo de checklist pour wizard

[niahoo]

statefull = avec état, c'est à dire que tu demandes à une page de savoir exactement l'état de toutes les autres pages (ce que l'on fait avec les sessions dans le monde PHP, mais pour un minimum de truc qui sont vitales)

En ajax/comet tu transmets dans l'appel les paramètres qui t'intéressent, c'est stateless.

ça m'étonnerait que le client wow s'amuse à renvoyer l'intégralité de ton personnage à chaque fois que tu fais une petite modif dessus.

Tu me parles du statefull en ne mentionnant que la partie serveur et du stateless en faisant entrer la notion de client.

Je ne veux pas qu'une page ait accès à l'état de toute les autres pages, je veux que quand je reçois une requête sur un controlleur particulier il ait accès à un objet (qui peut être en BD, pas obligatoirement en session), qu'il puisse déduire de cet objet la prochaine vue à envoyer au client et que le client puisse savoir où il se trouve dans le système de création de mon objet pour ne pas être perdu.

C'est très courant dans le web, par exemple : http://www.zegeniestudios.net/ldc/

[srm]

Le client wow n'est justement pas une application web, toutes (ou pas loin en tout cas) les applications sont statefull, ce sont les sites web qui sont stateless.

Très courant j'irais pas jusque là, l'exemple que tu donnes est justement un exemple statefull, ou chaque page doit connaitre l'état qu'il y a eu sur toutes les précédentes du formulaire, c'est pas très/pas du tout efficient pour le web.

[niahoo]

Non je te disais que ton client wow, à l'instar de tes requêtes ajax, utilisent le même procédé : on n'envoie pas forcément toute la ressource en entier vers le serveur. HTTP est stateless mais beaucoup de sites web ne le sont pas pour autant j'ai l'impression.

Il faut que je comprenne en quoi ce wizard pour choisir sa distro n'est pas du tout efficient pour le web. parce que à première vue ça marche bien. Je vais essayer de le faire planter.

---

ça marche bien. Je pense aussi au panier d'une boutique en ligne : on doit pouvoir logguer l'user que si nécéssaire, ajouter ou enlever des étapes en fonction des modes de paiement et de livraison, etc..

[srm]

Non mais ça marche bien pas de soucis, mais pour le dire autrement : c'est pas dans les bonnes pratiques du web, qui veut que tout soit stateless.

[Sephi-Chan]

Il n'y a rien de choquant à vouloir découper un processus en plusieurs étapes.

Non mais ça marche bien pas de soucis, mais pour le dire autrement : c'est pas dans les bonnes pratiques du web, qui veut que tout soit stateless.

Pour que le processus soit stateless pour le client, l'état doit être maintenu côté serveur.
Que proposerais-tu pour implémenter un tel mécanisme (stateless) ?

[niahoo]

ça m'avance pas des masses ce que tu me dis depuis le début car tu ne donnes pas d'application censée être bien faite.

s tu de la doc sur comment on fait un panier de boutique en ligne en respectant ces bonnes pratiques. Comment on fait un formulaire en plusieurs pages, etc ?

[srm]

Et bien tu stock les données sur le serveur avec un ID de transaction et toutes les informations, que tu peux récupérer en ajax, ou modifier, ou en rajouter.

[niahoo]

Oui mais ce que je cherche c'est l'algo qui va justement gérér quelles informations sont manquantes ou disponibles dans les données de la dernière requête, quel écran envoyer sur le navigateur client etc.

Stocker dans une DB et faire des requêtes je sais le faire :p

[srm]

Bah c'est pas compliqué de stocker en plus de l'id de la transaction, le step de la transaction, genre 3 pour page 3, ou pour étape 3, etc.

[niahoo]

Sans vouloir te vexer vu que tu es quasiment le seul à t'intéresser à mon problème, avant de répondre des trucs évidents essaie de comprendre ce que je veux et si tu n'y parviens pas, demande moi ou laisse béton

Je suis à la recherche d'une lib ou d'un framework car comme tu as pu le lire dans mon premier message, je n'ai pas forcément des étapes dans un ordre précis mais au contraire, je dois pouvoir afficher une étape selon l'état particulier d'un objet et/ou des données POST reçues pendant la requête courante.

Je sais que c'est pas très clair

J'ai commencé à modéliser un truc sur du papier mais ce n'est pas très avancé

---

ah j'avais loupé ton message

Il n'y a rien de choquant à vouloir découper un processus en plusieurs étapes.

Non mais ça marche bien pas de soucis, mais pour le dire autrement : c'est pas dans les bonnes pratiques du web, qui veut que tout soit stateless.

Pour que le processus soit stateless pour le client, l'état doit être maintenu côté serveur.
Que proposerais-tu pour implémenter un tel mécanisme (stateless) ?

Je trouve qu'on mélange trop le "stateless" de HTTP et le "stateless" de l'application. Du moment que tu as un login et que le site peut t'afficher quelque chose de personnalisé tu ne peux plus dire que ton application est stateless, même si tout ça est stocké côté serveur : il y a bien un état, géré par le serveur, qui est déterminé par les requetes précédentes et qui influe sur les requetes futures. C'est statefull (si j'ai bien lu la doc en anglais cet aprèm).

Personnellement je cherche surtout un algorithme pour la logique de décision de ce qui doit être fait en fonction de l'état d'un objet. On pourrait l'imaginer en pur javascript, l'exemple des distributions linux peut-être réalisé en pur javascript, la question des requêtes HTTP ne se pose pas forcément pour moi.