Je connais ton code moins bien que toi, mais en tout cas à la ligne 100 de balise/formulaires.php il y a:
isset($valeurs['action']) ? ....
qui auparavant ne pouvait être que toujours faux sauf erreur de ma part.
oui,
oui ? alors pourquoi laisser un code inutile qui va faire partir sur la piste d'un bug au premier souci ?
l'action des CVT est eventuellement définissable dans certains cas particuliers (ie le formulaire de recherche qui ne comporte aucune phase de verification, donc peut poster ailleurs),
eh oui, et c'est mon cas.
mais *toujours* sur self() dès qu'il faut vérifier() la saisie, donc en particulier avec le formulaire_editer_article. L'implémentation des formulaires_editer_xx de l'espace privé ne prévoit donc jamais une url de post différente de self() car cela casse le fonctionnement de l'étape verifier().
ok, donc ça ne sert à rien d'avoir mis 'redirect' => generer_url_ecrire(...) dans le contexte,
et d'ailleurs ces valeurs sont ignorées comme je le disais dans en 12822, et cela explique le bug que vient de signaler Realet et auquel je n'ai pas cru sur le coup: dans le cas des sites, tu as mis:
'redirect'=>generer_url_ecrire("sites")
qui est faux car il manque le id_rubrique, mais jusqu'à présent il était ignoré et remplacé par self() comme je disais. Maintenant que le nouveau code considère que ce que tu as pris la peine d'écrire mérite considération, il n'y a plus 2 bugs s'annulant l'un l'autre et ça pète.
Pfiouuuuuuuuu
cela alourdit nettement l'ecriture
L'écriture de quoi ?
du formulaire en lui meme
Bof, préciser qu'on ne met pas "form" s'il n'y a rien pour son attribut obligatoire "action", c'est plutôt une mesure de salubrité.
Je ne comprends pas: dans le cas habituel je produis le même HTML qu'avant.
mais le formulaire n'est pas intégralement produit par son squelette, donc le hit ajax de CVT qui renvoie le contenu généré par la balise #FORMULAIRE_EDITER_ARTICLE va renvoyer un morceau de formulaire incomplet.
la prise en charge automatisée de l'ajax repose sur la concordance formulaire_xx= produit de la fonction balise_forumlaire__dyn et du squelette formulaires/xx.html
Dont rajout sort de ce schéma.
Bon, ça c'est une objection fondée.
pipeline ==> php ===> fuite des webdesigner. Ce que je propose se fait intégralement par squelettes.
n'exagerons pas, et dans ce cas, si l'on veut vraiment rester au stade des squelettes, le plus simple est encore d'ajouter un mecanisme d'inclusion dans le squelette du formulaire lui meme, sur le modele de ce que j'ai fait dans style_prive_plugins qui inclut tous les fonds style_prive_plugin_xxx trouvés dans le path.
Ce serait plus propre oui, mais pour le coup c'est ça qui risquerait d'alourdir l'écriture: A inclut B en lui transmettant des infos dont il se fout mais qu'il devra transmettre à C. Ouf.
Par ailleurs en relisant le commentaire de ton commit je note aussi que
- #ACTION_FORMULAIRE ne fonctionnera pas correctement en dehors du squelette du formulaire car il ne dispose pas du contexte du formulaire
- l'ajout de champs en dehors du formulaire comme tu le propose est inutilisable car ne permet pas d'avoir le contexte du formulaire, donc en particulier les erreurs, les valeurs de la saisie précédente ou pré remplie ...
Si les ajouts se font sans référence au contexte std, ça n'a pas d'importance. C'est ni plus ni moins dérogatoire que le formulaire de recherche dont tu parlais.
En résumé, je pense que cet ajout est conceptuellement lourd de consequences, et ne devrait a tout le moins pas figurer dans la branche stable, et de plus cela me fait plus penser a un vilain hack en cela qu'il donne certes une réponse à deux besoins que je crois comprendre :
- un est d'ajouter des champs dans le formulaire, mais pas via le pipeline
- l'autre de rediriger apres le post, mais je n'ai toujours pas compris en quoi le mécanisme d'origine ne fonctionnait pas
mais au prix de dysfonctionnements serieux car il ne couvre pas tous les cas.
Hormis le cas révélé par le bug de Relaet et qui se corrige en enlevant les Redirect puisqu'ils ne servent pas, je ne vois pas où il y a dysfonctionnement. Cela dit j'admets que ce que j'ai envoyé ne recouvre pas tous les cas, mais je l'ai fait parce que je pensais que CVT couvrait tous les cas et que mon blocage ne pouvait être qu'un bug dans son implémentation, pas dans sa conception.
Maintenant deux solutions:
- la propre: on affirme que CVT ne peut faire retour que sur lui-même et on retranche un paramètre dans toutes les balises FORMULAIRE_EDITER.
- la pratique: on admet que CVT peut faire un peu plus mais pas tout et donc on laisse en l'état, sans documentation.
Et je reviens encore à ma question initiale :
pourquoi le post sur self() suivi d'une redirection sur $retour dans la fonction traiter() ne suffisait pas ?
complétée par une autre
car moi aussi j'ai parfois:
du vieux code reconditionné ...
Committo,Ergo:Sum
