Produits Entr'ouvert » w.c.s.

(une liste m'aiderait bien).

mais peut-être qu'il serait juste utile de comprendre pourquoi une telle liste aiderait.

Malgré tout, quand même, d'un œil ce qui aujourd'hui a une validation serveur qui ne peut pas du tout être réimplémentée en js :

• numéro de téléphone français
• regex arbitraire (parce que différences entre regex python et regex javascript)
• condition django

(mais je répète que clairement je ne bloquerais pas sur, par exemple, l'implémentation d'une validation javascript des numéros d'IBAN, que pour toutes les validations ça peut être fait côté serveur).

On est déjà passé par là et on a du faire marche arrière. #30419. C'était principalement des questions d'affichage (gérées par ton approche, il me semble) mais il y avait aussi des regex incompatibles entre python et javascript (malheureusement à l'époque je n'avais pas pu remettre la main sur celle rencontrée).

Oui en effet, dans ma proposition, il n'y a aucun problème d'affichage. On gère l'affichage comme bon nous semble (cf proto).
Pour les regex,

Je pense qu'il faut partir dans l'autre sens : il faut d'abord considérer la validation par requête vers le serveur, qui peut couvrir tous les cas, puis petit à petit, pour ce qui pourrait être fait en local, le faire. Bref pas de liste de ce qui doit être fait sur le serveur, la liste c'est "tout sauf ce qui peut être fait en local".

Dommage de charger le serveur par plein de micro-requêtes qui pourraient majoritairement être évitées. Mais OK.

Proposition :

Passer une url de validation via un attribut data : `data-validation-url="https://form-url/validation/field_name"`
L'idéal serait que le serveur retourne un objet compatible / équivalement à celui de l'API JS (en gardant uniquement le pertinant) :
Sachant que `valueMissing` peut être géré côté browser, qu'on n'utilise pas à ma connaissance ni les ranges, ni les steps. on se retrouve avec un json réduit
On conserve l'idée des messages d'erreurs dans l'html et le serveur retourne simplement

{ 
​  patternMismatch: true,
  tooLong: false,
​  tooShort: false,
​  typeMismatch: false,
​  valid: false
}

donc

• Si pas de value dans le champ : validation native via attribut required.
• Si value et pas de `data-validation-url`: validation native à travers les atrtibuts html.
• Si value et `data-validation-url`, demande de validation au serveur.

Je pense qu'il faut partir dans l'autre sens : il faut d'abord considérer la validation par requête vers le serveur, qui peut couvrir tous les cas, puis petit à petit, pour ce qui pourrait être fait en local, le faire. Bref pas de liste de ce qui doit être fait sur le serveur, la liste c'est "tout sauf ce qui peut être fait en local".

Dommage de charger le serveur par plein de micro-requêtes qui pourraient majoritairement être évitées. Mais OK.

Il s'agit biend'éviter ça mais "petit à petit", pour ne pas bloquer les développements ici sur une réimplémentation javascript de la validation des IBAN, et autres.

Sachant que `valueMissing` peut être géré côté browser (...)

Partiellement seulement, pas pour les blocs de champs je crois. (mais on peut exclure ça pour le moment)

On conserve l'idée des messages d'erreurs dans l'html et le serveur retourne simplement :

Ça me semble bizarre d'avoir une structure qui empile toutes les possibilités puis avoir dans le code un boucle pour trouver celle qui a été choisie,

  let errorType
  for (const key in validityState) {
    if (validityState[key]) {
      errorType = key
      break
    }
  }

autant renvoyer directement le type d'erreur, en suivant le format des messages de Publik, ça passerait avec : {'err': 1, 'err_code': 'pattern_mismatch'}, et sur base de l'err_code tu peux trouver le message correspondant ? Je ne capte pas dans le code proposé où viendrait l'interrogation du serveur, donc pas vraiment où il y aurait un gain à suivre la structure de validityState.

J'avais commencé à regarder pour poser de manière statique les différentes erreurs possibles dans des balises <template> mais ça ne va pas être possible pour tout, la réponse du serveur doit pouvoir contenir un message personnalisé, et à partir de là, autant tout le temps juste fournir le message.

https://git.entrouvert.org/entrouvert/wcs/commit/b99b04c19f3aca75ab21eaae2a664644389678b9

Ça me semble bizarre d'avoir une structure qui empile toutes les possibilités puis avoir dans le code un boucle pour trouver celle qui a été choisie,

Oui, dans le proto, je retourne pour le moment la première erreur que je trouve. Mais si toutes les erreurs sont exposées, c'est bien pour afficher potentiellement plusieurs messages d'erreurs en cas d'erreurs multiples, ce cas de figure est plutôt rare mais peut arriver théoriquement, par exemple avec une validation pattern + min-length comme avec le code postal par exemple.

la réponse du serveur doit pouvoir contenir un message personnalisé

Je ne suis pas sûr de comprendre, Il n'est pas possible de générer la personnalisation au chargement de la page, parce que le message est potentionnement composé de contenu de champs ( {{ form_var_* }} ?)
C'est un peu bizzare, cela signifie que le champ à remplir doit forcement l'être après un autre (qui n'est pas forcement obligatoire, ni conditionné), sinon le message d'erreur sera incomplet, ou il y a formement une condition d'affichage qui lie ces champs ?

Je ne suis pas sûr de comprendre, Il n'est pas possible de générer la personnalisation au chargement de la page, parce que le message est potentionnement composé de contenu de champs ( {{ form_var_* }} ?)

Il n'y a pas de possibilité (facile) d'une liste exhaustive des erreurs potentielles côté serveur, et comme il s'agit de tests qui devront nécessairement avoir lieu côté serveur, il me semble nettement plus évident sur ce moment d'également fournir le message associé. Et à partir du moment où sur les validations côté serveur on a des cas avec le message fourni au moment de l'interrogation, on doit pouvoir le gérer, et à ce compte autant fournir dans tous les cas le message précis.

C'est un peu bizzare, cela signifie que le champ à remplir doit forcement l'être après un autre

Mais ce champ pourrait être d'une page précédente, ou (surtout) l'information pourrait venir du champ lui-même (je n'ai pas d'exemple à donner parce que justement point précédent liste exhaustive compliquée à établir).

_~~

J'ai posé https://git.entrouvert.org/entrouvert/wcs/commits/branch/wip/75724-error-template-markup avec une série de commits brouillons/expérimentations autour de tout ça.

Il y a dedans l'ajout de <template> avec les textes d'erreur, les codes d'erreur, puis aussi

• https://git.entrouvert.org/entrouvert/wcs/commit/c78f71d819714cee24489e35b06ef3e288722a79 qui ajoute un attribut pour les validations "complexes", pour permettre côté js de savoir qu'il faut une validation iban, par exemple,

• https://git.entrouvert.org/entrouvert/wcs/commit/df17bed730f444f6e38742e191c43c98840643da qui ajoute data-check-condition-url, avec l'URL d'une API locale, et un bouton moche pour voir ça en action.

Dans la branche aussi maintenant un <template> avec le message d'erreur de validation personnalisé. Et le <template id="form_error_tpl"> présent dans codepen.io.

J'ai poussé une première version du JS.
À tester.