Js: add live field validation (#75724) #240

Closed
tjund wants to merge 11 commits from wip/75724-JS-live-validation into wip/75724-error-template-markup
Owner
No description provided.
tjund added 1 commit 2023-04-13 15:47:53 +02:00
gitea/wcs/pipeline/head There was a failure building this commit Details
04a3dedd08
Js: add live field validation (#75724)
fpeters reviewed 2023-04-13 15:58:28 +02:00
@ -777,0 +829,4 @@
break
}
}
return errorType
Owner

Il faudrait vraiment utiliser le message d'erreur fourni dans la réponse; comme je le notais il n'y a pas d'exhaustivité possible dans ce qui peut être ajouté à l'HTML dès le rendu.

(anecdotique : le javascript sans point-virgules, c'est quelque chose qui vient avec notre choix de linter ?)

Il faudrait vraiment utiliser le message d'erreur fourni dans la réponse; comme je le notais il n'y a pas d'exhaustivité possible dans ce qui peut être ajouté à l'HTML dès le rendu. (anecdotique : le javascript sans point-virgules, c'est quelque chose qui vient avec notre choix de linter ?)
Author
Owner

le javascript sans point-virgules

oui, norme standardJS : https://standardjs.com/rules.html#semicolons

Il faudrait vraiment utiliser le message d'erreur fourni dans la réponse

Ok

> le javascript sans point-virgules oui, norme standardJS : https://standardjs.com/rules.html#semicolons > Il faudrait vraiment utiliser le message d'erreur fourni dans la réponse Ok
Author
Owner

Dans le Json retourné par le serveur, est-ce qu'il n'y a qu' 1 seul message et 1 seul type d'erreur possible ?

Dans le Json retourné par le serveur, est-ce qu'il n'y a qu' 1 seul message et 1 seul type d'erreur possible ?
Owner

oui.

oui.
fpeters reviewed 2023-04-16 11:04:17 +02:00
@ -759,0 +763,4 @@
var form_content = $form.serialize();
$.ajax({
type: 'POST',
url: $form.attr('data-check-condition-url') + '?field=' + widget_id,
Owner

À tester davantage mainteannt je note ce passage, le code d'exemple, ici c'est "widget_id" qui était passé, il arrivait via

    <button type="button" onclick="check_condition(this, '{{ widget.get_name_for_id }}')">check condition</button> 

C'est différent de ce que le code proposé fait,

    return fetch( url+field.name, { 

avec field.name qui va être différent de widget.get_name_for_id.

Ça n'a pas d'importance pour les champs ordinaires mais ça compte pour les blocs de champs, qui vont avoir un name de la forme f1$element0$fx, mais $ pas autorisé pour les id, donc conversion en f1__element0__fx dans get_name_for_id.

Il n'y avait pas d'accès direct à cette valeur disponible dans un attribut du champ, j'ai ajouté ça dans la branche à jour dans #76632,

+       data-widget-name-for-id="{{ widget.get_name_for_id }}"

(sur le <div class="widget ...">, pas l'input).

À tester davantage mainteannt je note ce passage, le code d'exemple, ici c'est "widget_id" qui était passé, il arrivait via ``` <button type="button" onclick="check_condition(this, '{{ widget.get_name_for_id }}')">check condition</button> ``` C'est différent de ce que le code proposé fait, ``` return fetch( url+field.name, { ```` avec field.name qui va être différent de widget.get_name_for_id. Ça n'a pas d'importance pour les champs ordinaires mais ça compte pour les blocs de champs, qui vont avoir un name de la forme f1$element0$fx, mais $ pas autorisé pour les id, donc conversion en f1__element0__fx dans get_name_for_id. Il n'y avait pas d'accès direct à cette valeur disponible dans un attribut du champ, j'ai ajouté ça dans la branche à jour dans #76632, ``` + data-widget-name-for-id="{{ widget.get_name_for_id }}" ``` (sur le `<div class="widget ...">`, pas l'input).
fpeters reviewed 2023-04-16 12:08:54 +02:00
@ -759,0 +854,4 @@
async toggleStatus(field) {
if (excludedField(field)) return
const attrError = hasAttrError(field);
const serverError = this.widget.dataset.supportsCheckCondition
Owner

Dans la dernière mise à jour de #241 j'ai modifié le data-supports-check-condition en data-supports-live-validation (parce que globalement dans w.c.s. il y avait déjà une utilisation de check_condition et partager les mêmes mots rendait les choses confuses).

Ça vaut aussi pour un peu plus bas,

    checkUrl: form.dataset.checkConditionUrl + '?field=',

l'attribut est désormais data-supports-live-validation="true".

Dans la dernière mise à jour de https://git.entrouvert.org/entrouvert/wcs/pulls/241 j'ai modifié le data-supports-check-condition en data-supports-live-validation (parce que globalement dans w.c.s. il y avait déjà une utilisation de check_condition et partager les mêmes mots rendait les choses confuses). Ça vaut aussi pour un peu plus bas, ``` checkUrl: form.dataset.checkConditionUrl + '?field=', ``` l'attribut est désormais data-supports-live-validation="true".
Owner

Dans #244 ce code js de validation, rebasé sur la branche à jour + des petits commits assez triviaux d'ajustements et corrections puis un commit qui ajoute des XXX sur les bouts que je n'arrive pas à reprendre (sans gros changements).

Dans https://git.entrouvert.org/entrouvert/wcs/pulls/244 ce code js de validation, rebasé sur la branche à jour + des petits commits assez triviaux d'ajustements et corrections puis un commit qui ajoute des XXX sur les bouts que je n'arrive pas à reprendre (sans gros changements).
Owner

Poursuivi dans la PR #244

Poursuivi dans la PR https://git.entrouvert.org/entrouvert/wcs/pulls/244
fpeters closed this pull request 2023-04-18 14:29:53 +02:00
Some checks failed
gitea/wcs/pipeline/head There was a failure building this commit

Pull request closed

Sign in to join this conversation.
No reviewers
No Label
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: entrouvert/wcs#240
No description provided.