Je ne sais pas comment sont mappées tes routes mais ça m'a pas l'air super pratique si tu ne peux pas réserver un path pour un controller …
Et c'est valable dans tout les contextes ; si tu utilises le même nom pour désigner deux choses différentes, forcément à un moment donné ça bloque. C'est un peu comme dire si je nomme ma variable i alors je ne peux plus nommer comme ça une autre variable dans la même fonction. Ben oui …
Bref, effectivement il reste un header. Mais si jamais une route utilise ce même nom de header pour autre chose, comment tu fais ? :p Je te taquine.
Edit, autre solution qui reste totalement dans le scope du formulaire : une valeur du formulaire (booléene) qui indique qu'on veut simplement faire le check. Si elle vaut true, alors le formulaire est rejetté quoi qu'il arrive. Mais si c'est la seule erreur renvoyée ça signifie que le reste du formulaire est bon. Ça permet de laisser la gestion du truc en javascript uniquement : JS affiche toutes les erreurs dans la page sauf cette erreur spécifique, les formulaires pur HTML n'ont tout simplement pas le champ. Et côté serveur tu vas plus facilement centraliser la validation de champs communs à tous les formulaires (genre player_id, session_id, datetime, etc. et donc "dry_run" ou "force_reject") plutôt que de devoir faire une branche de code (genre un "if") pour détecter le header/paramètre de route et appeler ou pas le reste du traitement. Mais bon ça change pas grand chose.
Re-Edit : en termes de sémantique, selon moi on ne veut pas faire la même chose : d'un côté valider des données, d'un autre envoyer ces données au jeu pour effectivement changer l'état du jeu. Et ça pour moi ça veut dire que l'URL doit changer. Ou le verbe, ta première idée.
Citation :Bon, après, avec un paramètre GET/POST, j'ai un soucis du même type: si jamais le endpoint voulait utiliser le paramètre GET "validateOnly" (pour une raison idiote : ) ), alors ce paramètre issu du endpoint empiètera sur le paramètre général servant à dire "fait juste la validation".
Et c'est valable dans tout les contextes ; si tu utilises le même nom pour désigner deux choses différentes, forcément à un moment donné ça bloque. C'est un peu comme dire si je nomme ma variable i alors je ne peux plus nommer comme ça une autre variable dans la même fonction. Ben oui …
Bref, effectivement il reste un header. Mais si jamais une route utilise ce même nom de header pour autre chose, comment tu fais ? :p Je te taquine.
Edit, autre solution qui reste totalement dans le scope du formulaire : une valeur du formulaire (booléene) qui indique qu'on veut simplement faire le check. Si elle vaut true, alors le formulaire est rejetté quoi qu'il arrive. Mais si c'est la seule erreur renvoyée ça signifie que le reste du formulaire est bon. Ça permet de laisser la gestion du truc en javascript uniquement : JS affiche toutes les erreurs dans la page sauf cette erreur spécifique, les formulaires pur HTML n'ont tout simplement pas le champ. Et côté serveur tu vas plus facilement centraliser la validation de champs communs à tous les formulaires (genre player_id, session_id, datetime, etc. et donc "dry_run" ou "force_reject") plutôt que de devoir faire une branche de code (genre un "if") pour détecter le header/paramètre de route et appeler ou pas le reste du traitement. Mais bon ça change pas grand chose.
Re-Edit : en termes de sémantique, selon moi on ne veut pas faire la même chose : d'un côté valider des données, d'un autre envoyer ces données au jeu pour effectivement changer l'état du jeu. Et ça pour moi ça veut dire que l'URL doit changer. Ou le verbe, ta première idée.