La philosophie de http fait bien la différence entre GET et POST, et j'ai l'impression que l'usage de ces deux méthodes est un peu confus dans spip.
Puisqu'on en est à discuter de refonte complète, ne pourrait-on pas embarquer ça ?
En gros :
- toutes actions "irrémédiables" (suppression d'éléments, formulaires d'une façon générale) sont en POST ;
- toutes actions de consultation + affichage de formulaires vierges sont en GET.
Ça a au moins deux avantages :
- sormalisation des comportements par rapport à ce qui (dans l'idéal) se fait dans le reste du monde ;
- aucun risque d'accident quand un administrateur lance un robot (par exemple d'analyse des erreurs 404 genre Xenu's Link Sleuth) ou un plugin de crawl dans son navigateur (car il bénéficie de ses informations de session et donc est potentiellement dangereux) alors qu'il aurait oublié de se déconnecter de l'interface privée.
Ce genre d'outils est assez souvent utilisé, en particulier par les sites collectifs où l'administrateur veut vérifier que tous les rédacteurs ont fait le nécessaire pour lier vers telle pièce jointe, tel article, etc. En tout cas quand j'étais administrateur d'une mini-ferme de spips, je le faisais assez souvent.
Un petit coup de bibliographie :
"Some methods (for example, HEAD, GET, OPTIONS and TRACE) are defined as safe, which means they are intended only for information retrieval and should not change the state of the server."
"By contrast, methods such as POST, PUT and DELETE are intended for actions which may cause side effects either on the server, or external side effects such as financial transactions or transmission of email. Such methods are therefore not usually used by conforming web robots or web crawlers, which tend to make requests without regard to context or consequences."
<http://www.answers.com/topic/http>
? on parle juste de réorganiser les menus de l'espace privé
ne pourrait-on pas
embarquer ça ?
L'idée est évidemment bonne. Une difficulté est qu'on a pas mal
d'actions qui sont cachées dans des liens A, qu'il faudrait donc
transformer en FORM. Ca implique de :
1) écrire une fonction qui donne le formulaire souhaité, conservant
grosso modo le même aspect qu'un lien
2) repérer tous les liens "irrémédiables"
? on parle juste de réorganiser les menus de l'espace privé
oui, mais on code aussi
je pense par exemple aux forums et aux documents dont les interfaces sont en refonte complète (bien avancées pour la première, en chantier pour la seconde)
ne pourrait-on pas
embarquer ça ?
L'idée est évidemment bonne. Une difficulté est qu'on a pas mal
d'actions qui sont cachées dans des liens A, qu'il faudrait donc
transformer en FORM. Ca implique de :
1) écrire une fonction qui donne le formulaire souhaité, conservant
grosso modo le même aspect qu'un lien
2) repérer tous les liens "irrémédiables"
Propositions de code bienvenues.
Oui mais c'est aussi à nous d'être vigilant.
Typiquement sur la refonte des documents en cours dans la mediathèque, j'ai reconduit certaines actions en simple lien vers une action par facilité au lieu de remplacer par un bouton et la prise en charge de son traitement, alors que je suis pourant deja dans un forumlaire.
C'est une pratique qu'il faut sans doute qu'on déclare comme mauvaise et à que l'on soit strict dessus. Car il faut profiter de la réécriture de nombreux formulaires et ajax en skel/cvt pour corriger cela.
Mais c'est vrai qu'en dehors d'un forumlaire il nous faut sans doute un mode bouton_action pour pouvoir réutiliser et coder rapidement les nouvelles interfaces...
