Deleting a branch is permanent. It CANNOT be undone. Continue?
dev/issue_4291_introduction
into master
No due date set.
This pull request currently doesn't have any dependencies.
Deleting a branch is permanent. It CANNOT be undone. Continue?
(Reprise de la PR !5 qui est en rade)
Objectif
Faire fonctionner la balise
#INFO_INTRODUCTION
de la même façon que#INTRODUCTION
Actuellement, cette balise ne renvoie rien, à part si l'objet possède un champ « introduction ». Il serait préférable d'avoir la vraie introduction calculée par SPIP en fonction des autres champs.
Fonctionnement actuel
La balise
#INFO_xxx
renvoie tout simplement le champ « xxx » de l'objet, s'il existe.Les cas particuliers sont gérés de 2 façons :
Solution
Ce PR ajoute donc une fonction
generer_introduction_entite
pour prendre en charge les introductions.Cette fonction est mutualisée entre la balise normale
#INTRODUCTION
et#INFO_INTRODUCTION
.En conséquent, une partie des choses qui étaient faites dans
#INTRODUCTION
est déportée dans cette fonction.Pour résumer, voici l'ordre d'appel et le rôle des balises et fonctions :
#INTRODUCTION
/#INFO_INTRODUCTION
: récupère les données brutes (champs textes, paramètreslongueur
etsuite
)generer_introduction_entite()
: normalise les données (tri dans les champs de texte, normalisation des paramètreslongueur
etsuite
)filtre_introduction_dist()
: construit l'introductionLimites
#INFO_xxx
, donc pas delongueur
et desuite
.introduction
, donc l'étoile n'a aucun effet (cf. commentaire).#INFO_xxx
, cf. commentaireTests
Testé les cas suivants, tout fonctionne :
#INFO_INTRODUCTION{article,#ID_ARTICLE}
#INTRODUCTION
#INTRODUCTION{100, ...}
#INTRODUCTION{...}
Ça me gêne un peu d'introduire une
#INFO_INTRODUCTION
qui ne supporte pas les paramètres longueur et suite. Je suppose qu'on peut adresser ça en définissant une balise qui collecte ces 2 arguments en plus du objet et id_objet de la balise generique#INFO_
.Enfin, il faudrait éviter que ce qu'on faisait avant à la compilation sur #INTRODUCTION soit maintenant fait à chaque calcul :
Questionnement : plutôt que définir une balise dédiée en plus, est-ce qu'on ne pourrait pas dans la balise générique INFO_XXX prendre en compte les arguments supplémentaires si on en donne :
generer_XXX_entite
alors on lui passe ces arguments en plus aussi, après les arguments obligatoiresEt donc là en l'occurence,
generer_introduction_entite
auraitgenerer_introduction_entite($id_objet, $objet, $select, $longueur, $suite)
Dans tous les cas la balise
#INFO_xx
appellegenerer_info_entite()
qui ensuite délègue éventuellement.Il faut donc gérer les arguments supplémentaires eventuels via un tableau d'args je pense qu'on ajoute à
generer_info_entite()
et qui est ignoré par défaut et passe en splat sur les fonction de délégation si il y en a alors...Enfin au choix l'un ou l'autre, mais je pense qu'il serait bon de traiter le problème d'emblée qu'on ait au moins un fonctionnement cohérent de l'ensemble
bé oui, on dit pareil donc :)
ça doit être générique, dès qu'il y a des args en plus à la balise squelette, on les récupère et passe dans les fonctions suivantes