Salut les gens, je suis en train de jeter un œil sur diverses choses et je voudrais juste rappeler un détail important à propos des formulaires : Dès qu'il y a enregistrement (d'un fichier ou de quoi que ce soit qui modifie la BDD), c'est en POST. Toujours. Les formulaires en GET, c'est uniquement pour générer un affichage non sauvegardé. C'est tout pour l'instant. _______________________________________________ Dev mailing list Dev(a)list.dotclear.org http://ml.dotclear.org/listinfo/dev

> Tu évoques ça dans quel contexte ? Dans formfilters, on stocke les filtres/colonnes dans userprefs, ça compte ? Si oui, alors je préfère changer de comportement pour passer par un paramètre de session plutôt que de partir en POST. Oui, ça compte, c'est justement là que je l'ai vu. Je vois parfaitement d'où ça vient, puisqu'auparavant c'était en get, mais il n'y avait pas d'enregistrement des préférences.

> Je reviens sur cette affaire de GET/POST. Pour ne rien cacher, ça > m'embête un peu : il est plus que courant d'avoir un requêtage GET > quand on fait une recherche (voir la partie publique du blog). > Remplacer cette requête par un POST impose alors d'avoir du PRG, ie. > une redirection après chaque > application/ajout/suppression/modification de filtre. Ca ne fait pas > un peu lourd ? Il faut différencier l'enregistrement des filtres de l'affichage. Tant que ça n'agit que sur l'affichage, on peut rester en GET. Dès qu'il y a modif de la base, désolé, c'est du POST, ne serait-ce que par sécurité (gestion du nonce.) > En fait, je serais presque favorable à ne pas stocker ces informations > dans les préférences utilisateurs, mais plutôt directement dans la > session admin de l'utilisateur. Après tout, quelle est la persistance > que l'on souhaite pour ces mémorisations ? Le fait de perdre les > filtres mémorisés quand on se déconnecte est-il si grave ? Pour moi, > il y a un intérêt à mémoriser un filtre uniquement pendant une > session. Imaginons par exemple que l'utilisateur d'un blog multi-utilisateurs ne veuille voir par défaut que ses propres billets : oui, ça fait sens de sauvegarder le filtre. Après, il va s'agir de réfléchir sur plusieurs niveaux : modification des filtres (sans changement de la liste) => session ou get Enregistrement des filtres modifiés et appplications d'iceux => post Affichage particulier sans modification de la base (par exemple lien depuis la page d'admin d'un plugin) => get. _______________________________________________ Dev mailing list Dev(a)list.dotclear.org http://ml.dotclear.org/listinfo/dev

> Heu là franchement, je suis d'accord avec Bruno, c'est de la modification > d'affichage, donc c'est pour ça que c'est passé en GET. Après, on nous a dit > qu'il fallait enregistrer l'état pour l'ergo, ce que l'on a appliqué. Non, ce n'est pas de la modification d'affichage : la première passe, c'est la modification des filtres, et cette modification ne modifie pas l'affichage *tant qu'on n'a pas cliqué sur "enregistrer"*.

Le gros problème de la version actuelle, c'est qu'on a un formulaire dont la moitié a un effet immédiat, l'autre moitié n'a d'effet que lorsqu'on clique sur le bouton, c'est cet état de fait qui n'est pas possible, ergonomiquement parlant. Il faut soit qu'on puisse agir sur les filtres, tous les filtres, sans aucune modification d'affichage tant qu'on n'a pas cliqué sur "appliquer", soit que tous les filtres aient un effet immédiat., avec possibilité d'enregistrement. _______________________________________________ Dev mailing list Dev(a)list.dotclear.org http://ml.dotclear.org/listinfo/dev

> Attends, ça veut dire que dès qu'on modifie/ajoute sur un filtre, il y a une > requête ajax qui part pour enregistrer l'état? > J'ai pas vu ça dans le code pourtant. Non : quand on modifie un filtre, le formulaire est envoyé tout de suite. Quand on modifie les colonnes affichées, il faut cliquer sur le bouton.

> Mouais bon, je vais regarder comment c'est fait dans les filtres alors parce > que je me greffe sur eux et leur formulaire pour l'affichage des colonnes Non, parce que les filtres ne fonctionnent pas comme ils le devraient : il s'enregistrent en BDD, alors que le formulaire passe en GET, et ça c'est niet.

Il faudra regarder ça à tête reposée

mais moi je vois ça comme ça : -filtres et colonnes peuvent être modifiés sans toucher ni à l'affichage, ni à la BDD : POST, enregistré dans la Session (éventuellement de l'AJAX par au dessus, mais c'est après.) -On peut appliquer/enregistrer les modifs : POST enregistré dans la BDD. Redirection avec des paramètres. De cette façon, l'affichage n'est effectivement déterminé que par les paramêtres, mais le jeu avec la session et la BDD se fait en post. Je crois qu'il faut revoir le truc en profondeur, pas patcher ce qu'on a, même si il est hors de question de jeter le gros boulot qu'à fait Bruno sur les classes : c'est très bien conçu, mais il faut pouvoir les dédoubler pour gérer la session ET la BDD. (dédoubler le traitement, donc certaines variables, pas les classes entières, bien entendu.) _______________________________________________ Dev mailing list Dev(a)list.dotclear.org http://ml.dotclear.org/listinfo/dev

> Tu as surement raison parce que je suis complètement embrouillé là, je > comprends plus rien sur le comportement que ça doit avoir et comment > l'executer. Bien sûr que j'ai raison : c'est dans ton contrat. :) Normalement, la semaine prochaine, j'ai un gros changement de rythme au boulot, mais une fois que je l'aurai digéré, je devrais avoir du temps libre. De toutes façons, comme on va s'appuyer sur les librairies de Bruno, il va falloir qu'il soit dans le coin, mais pour l'instant, il a autre chose à faire (ça avance, les préparatifs, Bruno ?)