Un trim sur les afficher_si ? #74

Open
opened 2 months ago by maieul · 3 comments
maieul commented 2 months ago
Collaborator

Sur un champ textarea, il est fréquent de mettre des retours lignes en trop.

Du coup un test du type @textarea_1@ affichera la saisie conditionnée par la valeur de textarea_1 que celle si soit effectivement rempli ou bien remplie avec uniquement desespaces /retours lignes.

Je me demandais donc si on ne devait pas

  • soit appliquer un trim par défaut sur la valeur du champs lors du test
  • soit ajouter une option dans la syntaxe d'afficher_si pour faire @textarea@:TRIM

Cas d'usage : je voudrais dans le constructeur des saisies conditionner les sous réglages d'afficher_si (dans l'onglet 'afficheage') au fait d'avoir un afficher_si :p

Sur un champ textarea, il est fréquent de mettre des retours lignes en trop. Du coup un test du type `@textarea_1@` affichera la saisie conditionnée par la valeur de textarea_1 que celle si soit effectivement rempli ou bien remplie avec uniquement desespaces /retours lignes. Je me demandais donc si on ne devait pas - soit appliquer un trim par défaut sur la valeur du champs lors du test - soit ajouter une option dans la syntaxe d'afficher_si pour faire `@textarea@:TRIM` Cas d'usage : je voudrais dans le constructeur des saisies conditionner les sous réglages d'afficher_si (dans l'onglet 'afficheage') au fait d'avoir un afficher_si :p

je ne crois pas qu'on puisse faire ça en masse, notamment parce que c'est pas que les gens qui utilisent le constructeur, mais aussi dans des développements PHP, et qu'il pourrait parfaitement y avoir des cas, des champs, où les gens distinguent " " (== true) et "" (== false). Est-ce qu'on peut le faire que pour les textareas ? Là ça pourrait car c'est pas comme les checkboxs etc, là pour un textarea c'est forcément une attente de texte long, donc y attendre vraiment un espace vide est très beaucoup plus improbable.

introduire une syntaxe encore en plus pour ça… C'est pas une critique, je sais bien que ça répond à une utilité, mais franchement je trouve que ça devient de plus en plus abscon les syntaxes persos rajoutées à maintenir nous-mêmes, alors qu'à la base c'était juste pour avoir des tests "qui sont les mêmes pour PHP et pour JS", mais donc surtout un truc qui ressemblent à des tests de langage de programmation, sans inventer tout un nouveau langage. Je ne pense pas être loin du compte si je dis que seule 3 personnes au monde comprennent/connaissent l'ensemble de la syntaxe et l'utilisent vraiment, au delà des tests classiques de base.

Plus concrètement là @champ@:TOTAL c'était une valeur en soi (le nombre de truc coché est en soi sémantiquement une valeur utile à tester), même si c'est bien une fonction (genre length(truc)) appliqué en fait. Alors que :TRIM ça serait vraiment une transformation faite sur la valeur d'un champ pour la modifier, c'est pas pareil qu'une autre valeur en soi. Mais bon derrière dans les deux cas c'est une fonction appliquée dessus…

je ne crois pas qu'on puisse faire ça en masse, notamment parce que c'est pas que les gens qui utilisent le constructeur, mais aussi dans des développements PHP, et qu'il pourrait parfaitement y avoir des cas, des champs, où les gens distinguent " " (== true) et "" (== false). Est-ce qu'on peut le faire que pour les textareas ? Là ça pourrait car c'est pas comme les checkboxs etc, là pour un textarea c'est forcément une attente de texte long, donc y attendre vraiment un espace vide est très beaucoup plus improbable. introduire une syntaxe encore en plus pour ça… C'est pas une critique, je sais bien que ça répond à une utilité, mais franchement je trouve que ça devient de plus en plus abscon les syntaxes persos rajoutées à maintenir nous-mêmes, alors qu'à la base c'était juste pour avoir des tests "qui sont les mêmes pour PHP et pour JS", mais donc surtout un truc qui ressemblent à des tests de langage de programmation, sans inventer tout un nouveau langage. Je ne pense pas être loin du compte si je dis que seule 3 personnes au monde comprennent/connaissent l'ensemble de la syntaxe et l'utilisent vraiment, au delà des tests classiques de base. Plus concrètement là `@champ@:TOTAL` c'était une valeur en soi (le nombre de truc coché est en soi sémantiquement une valeur utile à tester), même si c'est bien une fonction (genre `length(truc)`) appliqué en fait. Alors que :TRIM ça serait vraiment une transformation faite sur la valeur d'un champ pour la modifier, c'est pas pareil qu'une autre valeur en soi. Mais bon derrière dans les deux cas c'est une fonction appliquée dessus…
Poster
Collaborator

Laissons en suspens alors. Je n'étais pas chaud non plus pour une enième syntaxe (même si la maintenance est facilité désormais). Et je suis moyen chaud également pour mettre une exception par type, à l'heure où l'on essaie de simplifier.

A voir si le besoin se fait ressentir vraiment à l'usage.

Laissons en suspens alors. Je n'étais pas chaud non plus pour une enième syntaxe (même si la maintenance est facilité désormais). Et je suis moyen chaud également pour mettre une exception par type, à l'heure où l'on essaie de simplifier. A voir si le besoin se fait ressentir vraiment à l'usage.

oui tu as raison, par type non plus c'est pas super, de faire des trucs implicites, non demandés, si c'est pas tout le temps pareil

oui tu as raison, par type non plus c'est pas super, de faire des trucs implicites, non demandés, si c'est pas tout le temps pareil
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.