Insérer les champs par l'API de Saisies quand c'est possible #10

Open
opened 1 year ago by tcharlss · 4 comments
tcharlss commented 1 year ago
Owner

Si on détecte qu'un objet a son form d'édition déclaré avec Saisies, alors Champs extras devrait insérer ses saisies directement avec l'API bien proprement, plutôt qu'avec une regex à l'arrache dans le HTML avec <!--extras-->.

Par défaut, ça ajouterait tout à la fin du tableau de saisies déjà existant, ce qui reviendrait au même. Mais en plus de ça, on pourrait permettre d'indiquer une position précise, par exemple placer_avant / placer_apres, et dans ce cas chaque champ pourrait être à un endroit différent.

Ce qui serait un prélude au niveau du noyau, au ticket 2 de l'interface : spip-contrib-extensions/champs_extras_interface#2

Cela permettrait aussi nativement et directement, que les utilisations qui prennent les saisies d'un objet pour les mettre ailleurs (par exemple C&O qui permet d'ajouter les champs d'un contact/orga au form editer_auteur lié) prennent en compte les extras, sans avoir à refaire tout le même boulot en doublon ailleurs.
https://contrib.spip.net/Plugin-Contacts-Organisations#comment510526

$champs['spip_contacts']['secu'] = array(
	'saisie' => 'input', 
	'options' => array(
		'nom' => 'secu',
		'label' => 'Numéro de sécurité sociale',
		'sql' => "mediumtext DEFAULT '' NOT NULL",
		'defaut' => '',
		'placer_apres' => 'date_naissance',
	),
);
Si on détecte qu'un objet a son form d'édition déclaré avec Saisies, alors Champs extras devrait insérer ses saisies directement avec l'API bien proprement, plutôt qu'avec une regex à l'arrache dans le HTML avec `<!--extras-->`. Par défaut, ça ajouterait tout à la fin du tableau de saisies déjà existant, ce qui reviendrait au même. Mais en plus de ça, on pourrait permettre d'indiquer une position précise, par exemple `placer_avant` / `placer_apres`, et dans ce cas chaque champ pourrait être à un endroit différent. Ce qui serait un prélude au niveau du noyau, au ticket 2 de l'interface : https://git.spip.net/spip-contrib-extensions/champs_extras_interface/issues/2 Cela permettrait aussi nativement et directement, que les utilisations qui prennent les saisies d'un objet pour les mettre ailleurs (par exemple C&O qui permet d'ajouter les champs d'un contact/orga au form editer_auteur lié) prennent en compte les extras, sans avoir à refaire tout le même boulot en doublon ailleurs. https://contrib.spip.net/Plugin-Contacts-Organisations#comment510526 ```php $champs['spip_contacts']['secu'] = array( 'saisie' => 'input', 'options' => array( 'nom' => 'secu', 'label' => 'Numéro de sécurité sociale', 'sql' => "mediumtext DEFAULT '' NOT NULL", 'defaut' => '', 'placer_apres' => 'date_naissance', ), ); ```
tcharlss added the
amélioration
label 1 year ago
Owner

Comme qui dirait en lien avec ce ticket que j'avais mis dans interface : spip-contrib-extensions/champs_extras_interface#2

Comme qui dirait en lien avec ce ticket que j'avais mis dans interface : https://git.spip.net/spip-contrib-extensions/champs_extras_interface/issues/2

Je me permets de reformuler/généraliser le ticket plutôt qu'en faire un autre pour dire sensiblement la même chose.

Je me permets de reformuler/généraliser le ticket plutôt qu'en faire un autre pour dire sensiblement la même chose.
rastapopoulos changed title from Position des champs extras / Saisies to Insérer les champs par l'API de Saisies quand c'est possible 6 months ago
Poster
Owner

J'ai rien contre la reformulation en elle-même, par contre je suis toujours pas très très chaud pour qu'on s'autorise à modifier substantiellement les messages des autres.

À la rigueur pour des corrections mineures dans cas bien précis (exemple : ajouter des balises autour des extraits de code pour qu'ils soient lisibles, les gens oublient des fois).

Mais se voir attribuer des choses qu'on n'a pas écrites, ça fait bizarre.

J'ai rien contre la reformulation en elle-même, par contre je suis toujours pas très très chaud pour qu'on s'autorise à modifier substantiellement les messages des autres. À la rigueur pour des corrections mineures dans cas bien précis (exemple : ajouter des balises autour des extraits de code pour qu'ils soient lisibles, les gens oublient des fois). Mais se voir attribuer des choses qu'on n'a pas écrites, ça fait bizarre.

Autant je suis totalement d'accord pour les commentaires/forums (où on débat et qui contiennent toujours un avis personnel), autant pour les tickets eux-mêmes, j'ai pris le plis, pour moi c'est vraiment le même principe que pour des user stories : la description d'un truc à résoudre (titre + détails) devrait en permanence être à jour sur la chose attendue. Donc quand il y a des nouvelles informations/précisions, etc, le texte de départ doit pouvoir être changé pour refléter au plus précis ce qu'on cherche à résoudre, sans lire 30 commentaires plus bas. C'est normalement comme ça qu'on gère des user stories (c'est pas juste une recommandation, c'est obligatoire dans la méthodologie de réécrire en permanence les titres+détails suivant les retours des participants), et pour moi du coup les tickets c'est à peu près pareil. (Méthodologie qu'on avait reprise tout pareil dans le fonctionnement des sujets du Loomio : débats en commentaires, texte en haut tenu à jour.)

Autant je suis totalement d'accord pour les commentaires/forums (où on débat et qui contiennent toujours un avis *personnel*), autant pour les tickets eux-mêmes, j'ai pris le plis, pour moi c'est vraiment le même principe que pour des user stories : la description d'un truc à résoudre (titre + détails) *devrait* en permanence être à jour sur la chose attendue. Donc quand il y a des nouvelles informations/précisions, etc, le texte de départ doit pouvoir être changé pour refléter au plus précis ce qu'on cherche à résoudre, sans lire 30 commentaires plus bas. C'est normalement comme ça qu'on gère des user stories (c'est pas juste une recommandation, c'est obligatoire dans la méthodologie de réécrire en permanence les titres+détails suivant les retours des participants), et pour moi du coup les tickets c'est à peu près pareil. (Méthodologie qu'on avait reprise tout pareil dans le fonctionnement des sujets du Loomio : débats en commentaires, texte en haut tenu à jour.)
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.