Produits Entr'ouvert » w.c.s.

ooooohhh mon précieux #637 !

La situation présente, elle est celle où il y a réflexion quant aux champs où un identifiant est posé, ou plutôt celle où des identifiants sont déjà posés partout ?

Parce que ça a des conséquences à différents endroits, dont ce qui est produit par les API, mais s'il y a déjà des identifiants partout, le coût de ces conséquences n'est pas vraiment à mesurer.

S'ils sont déjà posés de manière systématique, juste manuellement, il n'y aurait alors pas de différence à générer un identifiant par défaut. Sinon, il y aurait à mesurer les choses. (j'ai quand même déjà un peu regardé et ça devrait aller, surtout si on peut supprimer la génération statiques de variables de substitution)

Je n'ai pas tout compris :/

J'indique en formation de mettre systématiquement des identifiants sur les champs, et je le fais moi-même quand je construis un formulaire.

Marie a peut-être un peu compris ta réponse Fred, moi pas vraiment, pas faute d'avoir relu. La seule chose que je pense percevoir c'est qu'il faut évaluer des choses (l'énigmatique "le coût de ces conséquences n'est pas vraiment à mesurer" pourrait laisser penser le contraire mais il concerne un cas d'usage "pas d'identifiants partout" qui ne me semble pas à considérer - pour donner moi aussi dans la formule alambiquée).

La demande est explicite je crois : avoir pour les champs (fiches, blocs de champs, formulaires, données de traitement, formulaires de workflows) des identifiants "par défaut" générés automatiquement en slugifiant le libellé du champ. L'identifiant reste éditable.

Ce serait tout à fait utile, mais si c'est trop coûteux pour une raison ou pour une autre oublions et rejetons le ticket.

Je mets aussi, et recommande, de mettre systématiquement des identifiants. Les avoir générés automatiquement pourrait cependant augmenter les formulaires avec des champs ayant le même identifiant ce qui pourrait poser des soucis de debuggage si les utilisateurs venait à prendre l'habitude de faire usage des variables sans faire de contrôle sur ce point. Peut-être serait t-il envisageable d'avoir des identifiants générés automatiquement qui soient assurés uniques ou à défaut avoir une alerte sur tous les formulaires qui ont des identifiants en double, ce qui ne serait pas un soucis si cela était fait sciemment.

Il faut analyser aujourd'hui les différences de traitement qui ont lieu selon qu'un champ ait un identifiant, ou pas. Par exemple avoir un identifiant va ajouter le champ dans l'API, ce qui va entrainer le champ dans wcs-olap/bijoe, ce qui va entrainer aussi que dans une action webservice de POST avec les données de la demande, il y aura davantage de champs.

Bien sûr, si aujourd'hui la pratique est de toute façon déjà mettre des identifiants partout, il n'y aura pas de changements.

Pareil pour l'impact côté performances. (même si j'avais brièvement regardé, et posé que "ça devrait aller, surtout si on peut supprimer la génération statiques de variables de substitution").

C'est donc ça l'objet de ma question "La situation présente, elle est celle où il y a réflexion quant aux champs où un identifiant est posé, ou plutôt celle où des identifiants sont déjà posés partout ?" : le ticket entrainera des identifiants partout, est-ce déjà le cas ? (ce qui rassurerait sur les conséquences, réduirait l'analyse à faire).

De mon côté, c'est une pratique quasiment systématique (peut-être à tord ? ). Il faudrait regarder sur les démarches faites depuis un an, j'ai l'impression que c'est assez généralisé.

J'ai compris maintenant, merci.

De mon côté ça n'est pas systématique, je mets des identifiants quand j'en ai besoin. Mais ça va quand même concerner aujourd'hui 80% des champs je dirais.

Pierre Cros a écrit :

De mon côté ça n'est pas systématique, je mets des identifiants quand j'en ai besoin. Mais ça va quand même concerner aujourd'hui 80% des champs je dirais.

Idem

Marie Kuntz a écrit :

Pierre Cros a écrit :

De mon côté ça n'est pas systématique, je mets des identifiants quand j'en ai besoin. Mais ça va quand même concerner aujourd'hui 80% des champs je dirais.

Idem

À part pour les champs de mise en page (titre, sous-titre...), je renseigne manuellement des identifiants partout

• consensus sur l'intérêt même du comportement (cf. notes ci-dessus)
• apporterait de la cohérence dans Publik

[1] une donnée calculée créée avec libellé "ceci est un libellé de donnée calculée, un peu long" donne {{ form_var_ceci_est_un_libelle_de_donnee_calculee_un_peu_long }}

Si j’ai le droit de plussoyer plusieurs fois, je dirais +10.
Harmonisation avec le comportement de champs côté WF.
Et puis surtout, on gagnerait un temps fou.

Et en prime, on pourrait activer le message d’alerte indiquant que deux champs ont le même identifiant (sans toutefois l’interdire).