J'ai un souci avec mon #1181 que je ne sait pas comment régler. On ( :) ) me demande un bouton, mais un bouton va valider le formulaire avec l'action sélectionné dans la combo-box. Je ne vois pas d'autre solution que de créer une ligne vide dans la combo-box d'action. Mais ça ne règle pas le fait que le bouton va valider la combo-box ce qui n'est pas le but. -- lipki

Dans blogroll le bouton valide tout le formulaire et il ni a pas de combo-box d'action. Un bouton dans un formulaire valide tout le formulaire, ou j'ai oublier un truc très important. (et je vais me cacher) -- lipki

CR de la "Discution" de ce soir :) par lipki *Problème* : Dans une liste de "truc" ici pour l'exemple la liste des pages. S'il on a une liste d'action, à effectuer sur une sélection de "truc", accompagné de son bouton de validation. Et un bouton pour une autre action, s'appliquant sur l'ensemble de la liste. Alors le bouton validera également l'action sélectionné dans la liste. On est dans un cas, 1 formulaire 2 actions. On prend en compte le cas du JavaScript d'activé. Le problème immédiat concerne la page posts_actions.php qui fait du traitement par lot et qui est assez complexe. Cette page à était revu récemment par bruno, pour la mise en page et quelque bug. *Solution proposé* : Que le bouton sélectionné pour faire le submit (s'il n'est pas le bouton de validation de la liste d'action) soit considéré comme l'action sélectionné. Pour les différentes listes de "truc" du corps, ça permet de déplacer certaine action dans un bouton, si les ergonomes ou les accessibilistes le juge nécessaire. Même chose pour les plugins qui ont des besoins que l'on ne peux pas deviné, cela leurs permettra de bénéficier de tout le système de liste et de traitement par lot du core avec une contrainte de moins (celle de mettre toutes les actions dans une combo). *Ce qui ressort de la discution* : Il faut un bouton, pour coller aux autres listes et parce que la combo-box fait du traitement sur les "truc" sélectionné. La solution est simple mais, la page (posts_actions.php) qui va abrité cette solution est une usine à gaze. Il faut réfléchir et en parler sur la ML. Mais il n'est pas question de mettre dans le core une fonction spécialisée utilisée par un plugin optionnel. Franckpaul propose dans parler lors de la reunion de lundi soir, IRC 21h.

Le problème exposé ici est particulier, et ça n'a pas été évoqué (ou très partiellement) par lipki est que l'URL de soumission du formulaire **n'est pas** la page qui gère l'affichage de la liste des pages (qui est un plugin) mais post_actions.php qui fait partie du core. Modifier le core pour gérer une spécificité d'un plugin n'est pas une bonne méthode — et montre au passage la limite lorsqu'on cherche à "tout" sortir du core pour en faire des plugins. Il faudrait, je pense, soit passer par un contrôleur qui aiguillerait en fonction du bouton de soumission, soit vers post_actions.php soit vers un traitement géré par le plugin, soit utiliser le behaviour présent (mais on a vu que ça a ses limites et nécessiterait de revoir post_actions.php qui est un peu bourrin aujourd'hui) dans post_actions.php. D'autre part il faut garder en tête que c'est un besoin très spécifique (dont on se passe très bien aujourd'hui) et que nulle part ailleurs on a cette problématique. Je passe sous silence les "ça peut servir un jour", vous savez ce que j'en pense ;-) (sinon cherchez YAGNI sur internet). Donc pour résumer, soit on trouve une solution simple et si possible élégante, soit on laisse tomber. My 42 cents Le 26 août 2013 00:48, Kozlika <kozlika(a)gmail.com&gt; a écrit : -- Franck

Le 26 août 2013 09:16, Lepeltier kévin <kevin(a)lepeltier.info&gt; a écrit : Combien y a-t-il de plugin qui utilise "adminDashboardItems". Perso j'en ai au moins 3 que j'ai développés. Combien de demande utilisateur pour la liste des favoris ou billets rapide. Les favoris sont une des demandes de l'étude ergo. > D'après les retours récent j'ai l'impression que c'était surtout une > initiative de l'équipe (ergo peut-être). > Et c'est bien ! C'est aussi a l'équipe de proposé des choses ! non ? Tout à fait, mais proposer ne signifie pas qu'on va l'intégrer, tout comme ouvrir un ticket ne signifie pas qu'on va l'accepter. -- Franck

Je me suis fait la même réflexion hier Julien. Le 26 août 2013 11:29, Julien Wajsberg <felash(a)gmail.com&gt; a écrit : -- Franck

Le 26 août 2013 11:44, Lepeltier kévin <kevin(a)lepeltier.info&gt; a écrit : particuliers d'icelles), je pense que ça ne doit pas être si ingérable que ça, si ? (je n'arrive pas a considérer pages comme un simple plugin indépendant) Et pourtant s'en est un :-)

J'aime bien cette idée, ça à l'air d'évité de modifier l'existant. Mais ce contrôleur devra aiguiller vers posts_actions.php en lui renvoyant tout les paramètres en POST. Un Simple http::redirect ne suffira pas n'est-ce pas ? -- lipki

Certes ça simplifierait le code, mais du côté utilisateur je me demande si on en comprendrait la "logique". Le 26 août 2013 11:27, Dsls <dsls(a)morefnu.org&gt; a écrit : -- Franck

A noter : c'est un des axes de réflexion que j'ai sur la branche twig actuellement, afin d'avoir des traitements plus "propres" et réutilisables. Un répertoire inc/admin/actionsets devrait bientôt apparaître sur cette branche. -- Bruno

Le 30 août 2013 21:25, Lepeltier kévin <kevin(a)lepeltier.info&gt; a écrit : (Post-redirect-get), ce qui évite de répéter l'action quand l'utilisateur fait F5 après avoir soumis le formulaire. http://fr.wikipedia.org/wiki/Post-Redirect-Get En clair : 1. L'utilisateur soumet le formulaire de modification en POST 2. La page posts_actions.php effectue le traitement voulu 3. elle envoie un redirect au navigateur pour revenir à la page initiale tout ça est fait car lors du post, un paramètre redir sert à indiquer où revenir après le traitement.