Test de `supprimer_dates_nulles` pour pouvoir débrayer le vidage des dates considérées comme nulles #11

Closed
cy.altern wants to merge 2 commits from issue_10 into master

ajout du test d'une option supprimer_dates_nulles pour pouvoir débrayer le vidage des dates considérées comme nulles (1/1/1970 par ex) dans la fonction de normalisation des dates

Règle le ticket https://git.spip.net/spip-contrib-extensions/verifier/issues/10

ajout du test d'une option supprimer_dates_nulles pour pouvoir débrayer le vidage des dates considérées comme nulles (1/1/1970 par ex) dans la fonction de normalisation des dates Règle le ticket https://git.spip.net/spip-contrib-extensions/verifier/issues/10
cy.altern added 1 commit 2 months ago
Collaborator

Dans la mesure où il s'agit d'annuler un comportement par défaut, je verrai plutot une option conserver_date_nulle à mettre à true plutot que supprimer_date_nulle à true par défaut.

Dans la mesure où il s'agit d'annuler un comportement par défaut, je verrai plutot une option `conserver_date_nulle` à mettre à `true` plutot que `supprimer_date_nulle` à true par défaut.
Collaborator

Autre point : quand on ajoute des options à une verification, c'est bien de le mettre dans .yaml, pour permettre ensuite l'autodoc et tutti quanti.

Autre point : quand on ajoute des options à une verification, c'est bien de le mettre dans .yaml, pour permettre ensuite l'autodoc et tutti quanti.

Moi je crois que je préfère dans le premier sens de @cy.altern : il me semble que le nom d'une option doit être en priorité le nom d'une action en plus qui se fait, pas d'une anti-action qu'on annule, que ce soit activé par défaut ou pas. Donc "vider_date_nulle" (pour mieux reprendre le nom de la fonction appelée), qui est à true par défaut, mais qu'on peut mettre à false.

Moi je crois que je préfère dans le premier sens de @cy.altern : il me semble que le nom d'une option doit être en priorité le nom d'une action en plus qui se fait, pas d'une anti-action qu'on annule, que ce soit activé par défaut ou pas. Donc "vider_date_nulle" (pour mieux reprendre le nom de la fonction appelée), qui est à true par défaut, mais qu'on peut mettre à false.
Poster

il s'agit d'annuler un comportement par défaut

il s'agit surtout de corriger un comportement défaillant ceci dit !

le nom d'une option doit être en priorité le nom d'une action en plus qui se fait

+1 : vider_date_nulle à passer à false me semble nettement plus intelligible qu'une double négation.

Autre point : quand on ajoute des options à une verification, c'est bien de le mettre dans .yaml

OK mais pas tant que le nom/fontionnement de l'option n'est pas définitif

> il s'agit d'annuler un comportement par défaut il s'agit surtout de corriger un comportement *défaillant* ceci dit ! > le nom d'une option doit être en priorité le nom d'une action en plus qui se fait +1 : `vider_date_nulle` à passer à `false` me semble nettement plus intelligible qu'une double négation. > Autre point : quand on ajoute des options à une verification, c'est bien de le mettre dans .yaml OK mais pas tant que le nom/fontionnement de l'option n'est pas définitif
Collaborator

+1 : vider_date_nulle à passer à false me semble nettement plus intelligible qu'une double négation.

bah justement, là tu a une double negation : tu nie le fait de ne pas conserver les dates nulles :)

perso j'ai tjr tendance à penser que les options devraient être à false par défaut, et que le true est un ajout. Mais c'est dans un monde idéal où l'on se met d'accord en amont sur le bon comportement par défaut.

Donc je n'irais pas plus loin et je valide le nom d'option.

il s'agit surtout de corriger un comportement défaillant ceci dit !

ca c'est surtout une question de point de vue, qui dépend essentiellement du contexte d'usage (sinon du reste on aurait pas d'option)

> +1 : vider_date_nulle à passer à false me semble nettement plus intelligible qu'une double négation. bah justement, là tu a une double negation : tu nie le fait de ne pas conserver les dates nulles :) perso j'ai tjr tendance à penser que les options devraient être à false par défaut, et que le true est un ajout. Mais c'est dans un monde idéal où l'on se met d'accord en amont sur le bon comportement par défaut. Donc je n'irais pas plus loin et je valide le nom d'option. > il s'agit surtout de corriger un comportement défaillant ceci dit ! ca c'est surtout une question de point de vue, qui dépend essentiellement du contexte d'usage (sinon du reste on aurait pas d'option)
Poster

les options devraient être à false par défaut, et que le true est un ajout

pour faire simple : je n'ai pas envie de tergiverser des jours là-dessus...
Tout ce qui m'intéresse c'est que cette PR soit opérationnelle le plus vite possible alors n'importe quel choix sera OK pour moi :-)

> les options devraient être à false par défaut, et que le true est un ajout pour faire simple : je n'ai pas envie de tergiverser des jours là-dessus... Tout ce qui m'intéresse c'est que cette PR soit opérationnelle le plus vite possible alors n'importe quel choix sera OK pour moi :-)
Collaborator

comme dit il ne me manque que l'option dans le yaml et c'est bon pour moi.

comme dit il ne me manque que l'option dans le yaml et c'est bon pour moi.
cy.altern added 1 commit 2 months ago
maieul closed this pull request 2 months ago
Collaborator

Alors en fait comme le .yaml c'est pour construire des formulaires, et que ceux-ci ne peuvent envoyer que des chaines, et pas des booléens, on peut pas proposer false dans un .yaml. La convention du coup dans l'univers saisies c'est d'avoir des options qui peuvent prendre 'non' comme valeur, équivalent à false.

Bref j'ai corrigé le .yaml, squashé tout, et j'ai mis cela sur master en eba1ddd (et pour la v1 en 32ff4e6).

Je t'envie à regarder ce commit pour comprendre concrètement mon explication.

Alors en fait comme le .yaml c'est pour construire des formulaires, et que ceux-ci ne peuvent envoyer que des chaines, et pas des booléens, on peut pas proposer `false` dans un .yaml. La convention du coup dans l'univers saisies c'est d'avoir des options qui peuvent prendre 'non' comme valeur, équivalent à false. Bref j'ai corrigé le .yaml, squashé tout, et j'ai mis cela sur master en eba1ddd (et pour la v1 en 32ff4e6). Je t'envie à regarder ce commit pour comprendre concrètement mon explication.
Collaborator

Je t'invite à regarder

**Je t'invite** à regarder
Poster

OK : merci pour la modif !

on peut pas proposer false dans un .yaml

ça confirme bien pourquoi je préfère json à yaml pour stocker des données de config...

OK : merci pour la modif ! > on peut pas proposer false dans un .yaml ça confirme bien pourquoi je préfère json à yaml pour stocker des données de config...

Euh on peut parfaitement avoir des booléens en YAML hein, c'est des valeurs de base, encore heureux. C'est pas le YAML qui a pas de false, c'est qu'il sert à générer des saisies (ça serait pareil en JSON donc), et en HTML, les champs ne peuvent renvoyer que des chaines (ou des tableaux de chaines), jamais de booléens. Cela dit une saisie peut renvoyer chaine vide, qui vaut false. Et c'est d'ailleurs ce que font les cases à cocher par défaut : "on" pour true et "" pour false.

Euh on peut parfaitement avoir des booléens en YAML hein, c'est des valeurs de base, encore heureux. C'est pas le YAML qui a pas de false, c'est qu'il sert à générer des saisies (ça serait pareil en JSON donc), et en HTML, les champs ne peuvent renvoyer que des chaines (ou des tableaux de chaines), jamais de booléens. Cela dit une saisie peut renvoyer chaine vide, qui vaut false. Et c'est d'ailleurs ce que font les cases à cocher par défaut : "on" pour true et "" pour false.
This pull request cannot be reopened because the branch was deleted.
Sign in to join this conversation.
No reviewers
No Label
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This pull request currently doesn't have any dependencies.

Loading…
There is no content yet.