Produits Entr'ouvert » w.c.s.

J'aime pas vraiment, je sais plus quand on en avait parlé, mais les mots clés on a plutôt décidé que ça restait des vrais mots et pas un outil technique.

« Comme le slug d'une catégorie n'est pas une donnée éditable » : quid d'en faire justement une donnée éditable ?

Ou bien, pour arrêter de bidouiller ces trucs basés sur des slugs ou que sais-je, de proposer sur les catégories, comme sur les formdef, un attribut explicite "extra_css_class" ?

comme sur les formdef, un attribut explicite "extra_css_class"

Tu veux dire comme sur les champs. Parce qu'en fait, ça m'irait de taper ça sur les formdefs.

Frédéric Péters a écrit :

comme sur les formdef, un attribut explicite "extra_css_class"

Tu veux dire comme sur les champs. Parce qu'en fait, ça m'irait de taper ça sur les formdefs.

J'ai pas été bien clair, je voulais dire : avoir un champ "extra_css_class" sur les catégories, mais aussi, pourquoi pas, sur les formulaires (formdefs). Et tout ça sur le même modèle que pour les champs.

Complétement raté l'info "variations du template de rendu", et donc mon idée de css → /dev/null. Et j'aime pas l'idée des mots-clés non plus.

En quoi alors la gestion par slug (on peut adapter le slug d'un formulaire) poserait soucis ?

Complétement raté l'info "variations du template de rendu", et donc mon idée de css → /dev/null.

Le truc étant que extra_css_class est avec le temps devenu plus large, permettant également d'influencer le template de rendu d'un champ; la même logique serait en place ici, avec directement un libellé qui ne parlerait pas de CSS (cf #17975).

En quoi alors la gestion par slug (on peut adapter le slug d'un formulaire) poserait soucis ?

C'est pour s'appliquer à toute une série de formulaires, genre tous les formulaires "signalement", je préfère ne pas avoir à maintenir quantité de liens symboliques.

#17975, il faut vraiment que j'aille consulter à propos Alzheimer. Donc oui, et peut-être ne pas appeler le champ "extra_css_class", mais "style_classes" ou whatever.

Appearance keywords : on avait parlé de

Dans le message "hint" ajouter "separated by spaces" parce qu'on doute sans arrêt.

Lors du add_option_line, « self.formdef.appearance_keywords and self.formdef.appearance_keywords or C_('appearance|Default') » : le premier and est de trop, mais aussi pas fan de "Default". Je pense à ça parce que pour la traduction, j'aimerai éviter le léger anglicisme "par défaut" et indiquer plutôt "standard", alors peut-être C_('appearance|Standard') ?

L'ordre dans :

        'wcs/front/foobar/formdata_status.html',
        'wcs/foobar/formdata_status.html',
        'wcs/front/plop/formdata_status.html',
        'wcs/plop/formdata_status.html',
        'wcs/front/formdata_status.html',
        'wcs/formdata_status.html'

        'wcs/front/foobar/formdata_status.html',
        'wcs/front/plop/formdata_status.html',
        'wcs/front/formdata_status.html',
        'wcs/foobar/formdata_status.html',
        'wcs/plop/formdata_status.html',
        'wcs/formdata_status.html'

Et je pencherais pour "appearance-xxx" comme nom de répertoire au lieu du "xxx" seul, mais c'est juste un peu ma hantise des conflits — et aussi pour qu'un simple "ls" dans les templates permette de comprendre à quoi sert le répertoire. Mais c'est peut-être lié au fait qu'on utilise "foobar" et "plop" dans les tests qui sont non signifiants.

has_site_option('formdef-appearance-keywords') peut-être à checker aussi dans def appearance_keywords_list(self): (sinon les styles vont continuer à s'appliquer sans être visibles dans l'UI, même si l'option est désactivée après avoir été activée et testée). Mais bon je me pose quand même la question de cette option et des questions à répétition qui viendront (de nos collègues) pour activer ou pas, etc. (on va surement activer par défaut dans le déployeur Publik en proposant une version "no-agent-name", et donc, pourquoi pas activer par défaut dès maintenant ?).

Dans le message "hint" ajouter "separated by spaces" parce qu'on doute sans arrêt.

yep.

Lors du add_option_line, « self.formdef.appearance_keywords and self.formdef.appearance_keywords or C_('appearance|Default') » : le premier and est de trop, mais aussi pas fan de "Default". Je pense à ça parce que pour la traduction, j'aimerai éviter le léger anglicisme "par défaut" et indiquer plutôt "standard", alors peut-être C_('appearance|Standard') ?

Oui ça me va bien, Standard.

L'ordre dans :
[...]
là comme ça, ne me parait pas forcément pertinent, j'aurais imaginé à :
[...]
mais sans avoir d'avis tranché sur la question... (en réalité on mixera sans doute jamais les deux possibilité wcs/front/foobar/ et wcs/foobar, sauf folie passagère ?)

C'est bien possible qu'on fasse ça mais ton ordre comme le mien donnerait le même résultat, il me semble. Mais sans voir vraiment de situations raisonnables où une différence serait apportée, ça me va quand même bien de switcher sur l'ordre que tu propose.

Et je pencherais pour "appearance-xxx" comme nom de répertoire au lieu du "xxx" seul, mais c'est juste un peu ma hantise des conflits — et aussi pour qu'un simple "ls" dans les templates permette de comprendre à quoi sert le répertoire. Mais c'est peut-être lié au fait qu'on utilise "foobar" et "plop" dans les tests qui sont non signifiants.

Oui, ok.

has_site_option('formdef-appearance-keywords') peut-être à checker aussi dans def appearance_keywords_list(self): (sinon les styles vont continuer à s'appliquer sans être visibles dans l'UI, même si l'option est désactivée après avoir été activée et testée).

J'avoue avoir hésité puis zappé, ok.

Mais bon je me pose quand même la question de cette option et des questions à répétition qui viendront (de nos collègues) pour activer ou pas, etc. (on va surement activer par défaut dans le déployeur Publik en proposant une version "no-agent-name", et donc, pourquoi pas activer par défaut dès maintenant ?).

Pour moi il faut d'abord qu'il y ait un travail de développeur pour qu'un template particulier existe avant que l'option n'ait un sens, et donc le développeur à ce moment-là il active l'option. (alternativement je pourrais ajouter un 'has-form-templates: true' dans le themes.json et c'est ça qui in fine activerait l'option mais je préfène ne pas charger les themes.json pour le moment, avant d'avoir pu réfléchir davantage à leur contenu).

Frédéric Péters a écrit :

Lors du add_option_line, « self.formdef.appearance_keywords and self.formdef.appearance_keywords or C_('appearance|Default') » : le premier and est de trop

La forme est celle-ci pour suivre la forme employée par les autres options.

Y'a vraiment des gens, c'est des rigides.

Ack.