Deleting a branch is permanent. It CANNOT be undone. Continue?
#110 Ticket #4291 : faire fonctionner la balise #INFO_INTRODUCTION de la même façon que #INTRODUCTION.
Open
tcharlss
wants to merge 1 commits from dev/issue_4291_introduction into master
Reviewers
No reviewers
Labels
No Label
Milestone
No Milestone
Assignees
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
This pull request currently doesn't have any dependencies.
Loading…
There is no content yet.
Delete Branch 'dev/issue_4291_introduction'
(Reprise de la PR !5 qui est en rade)
Objectif
Faire fonctionner la balise
#INFO_INTRODUCTIONde la même façon que#INTRODUCTIONActuellement, 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_xxxrenvoie 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_entitepour prendre en charge les introductions.Cette fonction est mutualisée entre la balise normale
#INTRODUCTIONet#INFO_INTRODUCTION.En conséquent, une partie des choses qui étaient faites dans
#INTRODUCTIONest 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ètreslongueuretsuite)generer_introduction_entite(): normalise les données (tri dans les champs de texte, normalisation des paramètreslongueuretsuite)filtre_introduction_dist(): construit l'introductionLimites
#INFO_xxx, donc pas delongueuret 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_INTRODUCTIONqui 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_entitealors on lui passe ces arguments en plus aussi, après les arguments obligatoiresEt donc là en l'occurence,
generer_introduction_entiteauraitgenerer_introduction_entite($id_objet, $objet, $select, $longueur, $suite)Dans tous les cas la balise
#INFO_xxappellegenerer_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