Désactivation javascript et Approche RestFul

Bonjour,

Je poste dans le forum accessibilité, j'espère que c'est le bon endroit. Ca concerne surtout la désactivation de javascript (qui peut aussi être volontaire pour des raisons de sécurité)


Je bute sur un conflit entre deux notions que je veux respecter à priorité égale: l'utilisation sans javascript et avoir un site Restful

Actuellement je suis Restful. Pour simplifier par rapport à ce qui concerne la question, je respecte bien la règle GET = consultation, POST = modification.

Je suis en train de spécifier le travail à fournir pour rendre mon application utilisable sans javascript.

Prenons une liste d'utilisateurs, avec en face de chaque utilisateur un ensemble d'actions possibles qu'on va limiter à 2: consulter et supprimer

Dugenou Marcel consulter supprimer
Mortadelle Raymonde consulter supprimer
...

La consultation est une action en lecture sur la ressource, j'ai donc un GET. Je m'en sors avec un anchor. Jusqu'ici c'est parfait.

La modification est par contre une action en écriture. Je dois faire un POST.

Comment ça marche actuellement? (avec javascript)

Et bien j'ai le code suivant pour l'action de suppression de l'utilisateur d'id 123:

<form id="mainform" method="POST" action="">
	...
	<a href="#" onclick="postAction('/suppr/123/')">Supprimer</a>
	...
</form>

La fonction postAction affecte l'action demandée au formulaire et soumet ce formulaire. Je récupère bien côté serveur une requête de type POST pour ma demande de suppression, c'est ce que j'attends.

Pour rendre ça accessible sans javascript, on pense tout de suite à remplacer l'anchor par un submit et mettre l'action là où elle doit se trouver, c'est à dire dans l'attribut action du form.

<form method="POST" action="/suppr/123/"><input type="submit" value="Supprimer" /></form>

On se retrouverait avec autant de formulaires que d'actions. C'est un peu crado et très lourd si c'est multiplié par 100 mais au moins ça règlerait le problème en apparence.

Là où ça se complique... c'est que j'ai aussi des champs cachés dans mon formulaire principal (je passe sur leur signification) C'est à dire qu'en vrai j'ai:

<form id="mainform" method="POST" action="">
	<input type="hidden" name="unparametre" value="blabla" />
	...
	<a href="#" onclick="throwAction('/suppr/123/')">Supprimer</a>
	...
</form>

Il est bien sûr inconcevable de recopier ce champ caché dans 100 formulaires.

Je ne peux pas non plus changer la gestion de ces champs cachés (par exemple en les mettant en session) car je veux qu'ils soient enregistrés si je bookmark ma page ou si je joue avec l'historique.

Je refuse bien sûr toute gestion en GET du type: <a href="/suppr/123/">Supprimer</a> (je veux rester Restful et je veux mes champs cachés)


Bref! Je suppose que ce n'est pas une problèmatique si rare et en fait je ne trouve pas de solution propre donc je m'en remets à vous: Quelles sont les best practices sur le sujet?

Merci pour votre aide!

Bonjour,

Je pense que c'est un problème de conception. Normalement on créer le site de façon à ce qu'il marche sans javascript. Le javascript est là pour l'habillage à la fin. Ce qui fait que tu ne perds pas de temps. Malheureusement tu as conçu ton site à l'inverse.

Sans en connaitre plus sur ton site je ne vois malheureusement pas qu'elle piste pouvoir te donner.

Pour ce qui est du Restful, je crois que tu as mal compris le principe. Les navigateurs utilisateurs utilisant mal le http le principe du REST ne peut s'appliquer uniquement que d'un serveur à un autre. exemple lien supprimer en GET -> serveur front de réception des message (schema routing et compagnie, vérification des droits) -> requete POST vers serveur gérant la base de donnée.

C'est plus comme ça que je le vois, c'est là que le REST est utile et pas autrement. Il faut pas faire du REST juste pour un effet de mode comme le XML il y a 5 ans (il y a eu vraiment de tout est n'importe quoi à l'époque), base de donnée XMl sur un système non natif xml et blablabla...

Bon courage

@ Tony Monast

Merci pour tes propositions.

J'ai pensé à la solution A. En effet elle s'applique bien dans la grande majorité des cas et c'est celle sur laquelle je comptais me rabattre si je ne trouve pas mieux.

Dans le cas de mon exemple de suppression, elle est même la meilleure solution car je dois quoi qu'il arrive demander une confirmation avant suppression et je dois donc trouver une alternative au confirm javascript.

Pour un "site" ça serait d'ailleurs suffisant et j'appliquerais ça à toutes les actions. De plus j'aime l'idée qu'un utilisateur soit conscient que son action apporte une modification de données et que ça ne se passe pas dans son dos.

Malheureusement j'ai une appli avec de nombreuses interactions complexes du fait de règles métiers un peu lourdes (ça je ne le maîtrise pas) et dans l'optique de "gagner des clicks" et d'améliorer la fluidité d'utilisation, je ne peux pas mettre une confirmation derrière chaque action.
Un exemple que je trouve parlant: J'ai certains documents qui à l'ouverture sont notés comme étant lus par l'utilisateur en cours. C'est une action de modification (la base de données est mise à jour) mais si je mets un message de confirmation à l'ouverture de chaque document je me fais insulter quotidiennement par les utilisateurs.

Cependant, comme l'utilisation de javascript correspond malgré tout à un mode dégradé je ne rejette pas complètement cette éventualité. Mais ça pénaliserait vraiment les utilisateurs car ce genre d'action il y en a toutes les minutes.


Pour la solutions B:

Ca semble tout bête comme solution, je me demande même pourquoi je n'y ai pas pensé.
En fait je sais: c'est parce que je pars du principe qu'il doit n'y avoir qu'un submit par formulaire: Dans mon idée, le submit est le bouton qui déclenche un POST du formulaire lorsqu'on appuie sur Entrée. C'est peut-être là que j'ai tort.
Est-ce vraiment admis d'avoir plusieurs submit dans un même formulaire?
Si oui, effectivement ça règle mon problème en deux coups de cuillère à pot car je n'ai qu'à modifier le rendu HTML de mes actions sans toucher au fonctionnement général du formulaire.

saucissonsec a écrit :

Est-ce vraiment admis d'avoir plusieurs submit dans un même formulaire?

Oui, puisque c'est à la fois valide et les navigateurs le supportent bien. Il faut toutefois savoir qu'en appuyant sur ENTER lorsque le formulaire a le focus, c'est normalement le premier bouton Submit qui se trouve dans le code HTML du formulaire qui est envoyé. Pour éviter qu'une action non désirée soit déclenchée en appuyant sur Enter, tu peux mettre un input submit en haut du formulaire qui ne fait rien de particulier. À la limite, tu peux le cacher en CSS. Attention, de mémoire, si tu le mets en display:none, le navigateur agira comme s'il n'était pas là.

OK, là j'apprends un truc. Je pensais vraiment que ce n'était pas toléré.

Bref, ça répond parfaitement à mon problème. J'enverrai un feedback lorsque j'aurais vraiment implémenté le truc mais voila comme je compte finalement faire:

En mode javascript:
Comme avant: Je change en javascript l'action du formulaire et je mets éventuellement un message de confirmation avant.

En mode non javascript:
j'affiche un submit à la place de l'anchor avec le système que tu décris. Et pour la confirmation je rajoute une case à cocher sur la même ligne.

En faisant comme ça les modifications à apporter à l'existant sont légères et surtout très localisées, ce qui me va très bien. (bon, il y a un nouveau mécanisme de récupération de l'action déclenchée mais c'est pas la mort)

Merci beaucoup!

Une dernière chose. Tu peux sans problème mettre plusieurs <input type="submit" ...> dans un même formulaire, et il sera facile de savoir lequel a été utilisé lors de la soumission du formulaire. Par contre, si tu souhaites utiliser des <button type="submit" ...>, IE6 n'envoi pas seulement le button cliqué, mais aussi tous les autres <button> Donc aucun moyen de savoir lequel a été utilisé. Va savoir pourquoi...
Modifié par Tony Monast (21 Jul 2009 - 16:47)

a écrit :
==> Je ne veux pas qu'un lien en GET pointe sur la modification d'une ressource.

Si tes craintes sont liés à la sécurité d'une telle manoeuvre, il y a moyen de sécuriser ça plus ou moins correctement. C'est courant aujourd'hui, je trouve que tu t'imposes une énorme limitation. Ton problème serait rapidement résolu si tu faisais sauter cette contrainte, qui ne joue absolument aucun rôle sur l'accessibilité, et qui est, à mon sens, superflue.


Sinon pour ton problème, je pense que le plus simple est une liste déroulante multiple ou pas, et deux boutons submit modifier et supprimer. L'avantage de la site déroulante multiple est que tu peux supprimer plusieurs enregistrements en une seule opération. Pratique pour faire le tri...

Et puis pour le confirm javascript, c'est pas dramatique si tu en utilises : si javascript est désactivé, il n'y aura pas de demande de confirmation mais il sera tout de même possible d'effectuer la suppression. Puisque le formulaire est utilisable sans javascript, il n'y a aucun problème. La confirmation est juste là pour le confort d'utilisation, ce qui correspond bien à la raison d'être théoriquement principale de javascript.