par ailleurs on l'implemente en tant que filtre (filtre_slugify_dist) qui ne risque pas la collision
+ un shorthand slugify() tout court qui en general marchera mais que l'on protege de la collision vu le nom courant de la fonction
-* avec un nom sans coherence avec l'autre constante existante
-* qui genere une erreur d'appel du pipeline qui n'est plus declare lorsque la constante est mise a false
On remet ca au propre, en renommant la constante _RELECTURE en _PREVISU_TEMPORAIRE_ACTIVE (qui complete donc _PREVISU_TEMPORAIRE_VALIDITE), et en deplacant le test au bon endroit pour que la desactivation ne provoque pas d'erreur sur fonction manquante
Tout comme `table_valeur()`, il est possible de préciser un chemin de clés associatives à l'intérieur du tableau et des sous-tableaux.
Un dernier argument optionnel, permet de fournir une valeur booléenne pour dire si l'ajout va se faire ou pas. Cela permet d'alléger l'écriture, notamment si un ajout ne doit se faire que si la valeur à ajouter existe.
[(#TABLEAU|push_table_valeur{a/b/c, valeur, #CONDITION})]
On peut imaginer pour celleux qui en aurait besoin, un filtre du même genre mais qui serait `set_table_valeur()` et qui ferait directement un "set", c'est-à-dire une assignation directe et non pas un "push" de liste. Autrement dit, dans le chemin "a/b/c", ce filtre assignerait toujours la valeur à "c" directement, ce qui est différent de faire de "c" une liste à laquelle on ajoute un élément.
Pour info : ce filtre (au moins ce "push"), est très utile pour permettre de créer des tableaux complexes en squelettes, ayant de nombreux niveaux, pour insérer des valeurs loin dans l'arborescence directement. Par exemple pour générer des JSON complexes en squelettes.
Du coup la fonction balise_img() devient moins pratique a utiliser dans le PHP.
Faut-il proposer un nommage alternatif |tag_img pour cela, voire |img_tag ou tout simplement |img ?
#INFO_<QUOI>{type_objet, id_objet}
Exemple :
#INFO_TITRE{article, 2}
#INFO_TITRE{patate, #ENV{id_patate}}
Il y a une fontion PHP associé qu'on peut donc utiliser dans ses scripts : generer_info_entite($id_objet, $type_objet, $info).
Par défaut une info est tout simplement le champ SQL de l'objet mais c'est personnalisable par une fonction generer_<quoi>_entite().
En effet, il y a des infos qui sont calculées et ne sont donc pas le champ directement.
De plus, deux infos sont prisent en compte en interne par la fonction : l'URL via generer_url_entite() et le titre car SPIP permet de déclarer un titre autre que le champ SQL "titre".
La fonction respecte la magie de SPIP : l'information demandée va être automatiquement transformée s'il y a des traitements automatiques de déclarés pour cette info (cf. la gobale $table_des_traitements). Notamment pour gérer directement les textes <multi> et autres transformations.
kent1@arscenic.info