n'a été conservé dans saisies qu'à titre historique, pour ne pas casser
directement les plugins qui l'appelait. Mais n'a plus de raison d'être
en tant que tel. On peut donc se passer de son appel, et insérer
directement un div.
Permet d'éviter une Fatal error: Uncaught Error: Call to undefined function saisie_balise_structure_formulaire() in cextras_pipelines.php:135 lors de l'utilsiation d'un formulaire contenant des extras dans le public
On en profite pour inclure le même fichier dans cextras_editer_contenu_objet() qui utilise aussi cette fonction de saisies
Ca ne coute rien de verifier toutes les saisies, y compris celle sans
sql (et donc les fieldset par ex, ce qui permet d'éviter les pb avec les
afficher_si)
Celui-ci ne modifiait certes plus le champ des saisies masquées par
afficher_si, mais du coup même si une saisie était masquée, on
conservait en base son ancienne valeur.
Là on s'assure que si dans un formulaire une saisie est masquée par
afficher_si, le champ est remis à null en base.
On peut au cas par cas rétablir l'ancien comportement avec l'option
afficher_si_avec_post.
Cf. discussion ici
spip-contrib-extensions/saisies#49
Up de la dépendance à saisies.
aussi détecter lorsque le champ n'a pas été remplie, même si ce n'est
pas un entier.
Bon, tout ca n'arriverait pas si cextras utilisait l'API de saisies, qui
normalement fait proprement les choses (poke @Rastapopoulos).
Petit cour de logique booléenne.
On définit $a = 'a';
Alors:
1. $a != 'b' renvoie true;
2. !$a == 'b' renvoie false, car la négation d'une chaîne, c'est false;
3. !($a == 'b') renvoie true, car la négation de false, c'est true.
On évitera donc d'utiliser la syntaxe 2. à la place de la syntaxe 1.,
même en croyant utiliser la syntaxe $a (qui n'est en général pas
parlante.)
tester la présence éventuelle d'une variable `composition` dans _request() lors de la restriction d'extra, ainsi on peut afficher les extras d'un objet dans un formulaire perso en passant la composition à l'aide de set_request()
L’autorisation par défaut nécessite de connaitre la table sur laquelle elle s’applique, dans les options,
comme dans la fonction champs_extras_autorisations().
et arrive trop tôt pour que table_objet() puisse fonctionner correctement.
On désactive le chargement de public/interfaces du pipeline table objet sql, (qui ne servait pas vraiment à grand chose sinon à déclarer les constantees de _TRAITEMENT_*),
en ajoutant une note, et vu que la doc de Champs Extras indiquait déjà l’écriture correcte à avoir.
Alberto
