[SPIP Zone] Évolution de metaplus

Archives Zone
1

Hello,

Je suis les commits sur métaplus, et je ne suis pas certain que la voie
que tu as choisie soit la bonne.

Premièrement, je trouve que pour le besoin exprimé, le code est super
complexe. Avant on avait une structure de squelettes simple et facile à
étendre que n'importe qui pouvait comprendre en un coup d'œil.
Le code des métas était déjà mutualisé dans un unique fichier ce qui ne
posait donc aucun soucis de maintenance.

Maintenant il faut comprendre les arcanes de ce fichier
https://zone.spip.org/trac/spip-zone/browser/plugins/metaplus/trunk/inclure/metasplus/dist.html
et de cette fonction
https://zone.spip.org/trac/spip-zone/browser/plugins/metaplus/trunk/metasplus_fonctions.php#L26

Quelques questions me viennent :

- Est-ce qu'on a vraiment besoin de sortir l'artillerie REGEXP pour
insérer quelques balises méta ?

- Est-ce que cela vaux vraiment la peine de casser la
  rétro-compatibilité ? (cf:
  https://zone.spip.org/trac/spip-zone/changeset/108619)

Aussi, quand j'ai lu ce commit
(https://zone.spip.org/trac/spip-zone/changeset/108626) je me suis dit
qu'il fallait peut être ce poser quelques questions, parce que j'ai
l'impression que l'on est en train de créer une "silver bullet"
(https://fr.wikipedia.org/wiki/Pas_de_balle_en_argent)

Voilà voilà :slight_smile:

2

Le 25/01/2018 à 19:55, Debondt Didier a écrit :

Je suis les commits sur métaplus, et je ne suis pas certain que la voie
que tu as choisie soit la bonne.

Cf la discussion qu'il y a eu hier avec les arguments.

Le code des métas était déjà mutualisé dans un unique fichier ce qui ne
posait donc aucun soucis de maintenance.

Si puisqu'il *fallait* créer un nouveau fichier d'implémentation pour
chaque nouvel objet ou page qu'on voulait ajouter : l'horreur.

Ce n'est plus le cas aujourd'hui, maintenant par défaut il y a toujours
des informations pertinentes trouvées automatiquement, et *si et
seulement si* tu veux soit supprimer soit changer, uniquement là tu
crées un fichier pour telle page.

C'est donc plus simple pour les vraies intégrateurices finales.

Maintenant il faut comprendre les arcanes de ce fichier
et de cette fonction

Non : seulement les quelques devs qui vont maintenir ce plugin auront
besoin de comprendre le code générique automagique.

Celleux qui intègrent auront juste à
- activer le plugin et c'est tout dans 98% des cas \o/
- à savoir qu'illes peuvent personnaliser pour une page précise
- à connaitre la liste des paramètres s'illes veulent utiliser
l'inclusion dans leur squelette de personnalisation pour tel objet

C'est donc vraiment plus simple pour elleux, y compris pour les 2% qui
ont besoin de personnaliser en tant qu'intégration seulement.

- Est-ce que cela vaux vraiment la peine de casser la
  rétro-compatibilité ?

Oui puisque le but est de simplifier immensément pour la majorité des
gens : z'ont même plus à insérer des inclusions dans leurs squelettes,
ce qui fait que ça marche aussi pour celleux qui n'y connaissent rien et
que c'est même pas leur propre squelette (quand illes installent un
squelette générique ou un fourni par un prestataire, etc). Et ça c'est
vraiment cool. :slight_smile:

Et même pour celleux qui font leurs propres squelettes (toi, moi, nous)
c'est beaucoup plus simple à maintenir, car y compris nous-mêmes on a
juste à activer la plugin dans la majorité des cas. Et ensuite quelques
rares ajouts dans nos fichiers pour personnaliser une ou deux pages. Ça
fait gagner pas mal de temps et de maintenance.

Voilà voilà :slight_smile:

Voilà voilà :slight_smile:

--
RastaPopoulos

3

Bon ça aurait été mieux de continuer sur le fil de discussion d’origine du coup (je sais pas si tu l’as vu ?). Quand tu parles de « voie choisie », c’est que tu n’es pas d’accord avec le nouveau paradigme (automatisation), ou la façon dont c’est implémenté ? Alors je ne sais pas trop si tu parles avec ta casquette de dev qui voudrait contribuer au plugin, ou avec ta casquette d’intégrateur qui voudrait juste l’utiliser et éventuellement personnaliser des trucs (un peu des 2 ?). Ces évolutions se destinent avant tout à simplifier la vie des intégrateurs et des utilisateurs. Avant, la récupération des données s’effectuait obligatoirement dans de multiples fichiers metasplus-xxx.html, et ces données étaient utilisées pour le code des metas dans le fichier metasplus.html Donc non, ça ne faisait pas un unique fichier à maintenir mais 6. Maintenant, tout se fait dans un unique fichier dist.html, qui comprend aussi toute la partie récupération des données. Oui il est fatalement plus long que l’ancien metasplus.html, car on doit faire en 1 seul fichier ce qui prenait 6+ fichiers avant . Mais partie avec le code des metas est quasiment identique à ce qu’il y avait avant, tu peux comparer : - avant : - après : Si tu as une solution plus simple, je prends. J’aurais aimé la conserver mais ça ne me semble pas possible. Étant donné qu’on change un peu de paradigme pour l’utilisation/intégration, ça me semble moins problématique tout de même. Oui c’est la partie qui me pose problème et dont je ne suis pas satisfait (lignes 28 à 45) : La problématique est de retrouver le type de page en cours dans une fonction appelée depuis insert_head, et cette information ne se trouve pas de façon consistante dans le contexte global. Je cherche toujours une meilleur solution.

4

salut tous,

perso je ne sais pas encore quoi choisir des deux solutions : - un code simple moins facile à mettre en œuvre, mais facile à comprendre - un code complexe très simple à mettre en œuvre, c’est quand même attirant Le second sera maintenu par moins de monde… Mais l’un n’empêche pas l’autre sur la zone, on peut encore choisir celui qu’on veut utiliser… En tout cas merci pour les 2 versions, je vais de ce pas tester la nouvelle… :-*

5

Ça me parait en effet très problématique d’introduire encore du code qui repose sur cette globale contexte qui a toute les chances de disparaitre dans le futur, en plus ici de n’avoir pas grand chose de robuste.

(en plus ta fonction devrait être dans un fichier options car elle est appelée à chaque hit, et le fichier fonctions n’est appelé qu’en cas de calcul de la page, donc pas à chaque hit)

--
Cédric

On 26 janv. 2018 à 08:48 +0100, Charles Razack <tcharlss@bravecassine.com>, wrote:

Oui c'est la partie qui me pose problème et dont je ne suis pas satisfait (lignes 28 à 45) : Connexion · GitLab
La problématique est de retrouver le type de page en cours dans une fonction appelée depuis insert_head, et cette information ne se trouve pas de façon consistante dans le contexte global.
Je cherche toujours une meilleur solution.

6

Le 26/01/2018 à 09:10, cedric@yterium.com a écrit :

Ça me parait en effet très problématique d’introduire encore du code qui
repose sur cette globale contexte qui a toute les chances de disparaitre
dans le futur, en plus ici de n’avoir pas grand chose de robuste.

Oui c'est un gros problème (globals quoi… arg).

Mais le problème d'origine c'est qu'on a un très bon pipeline
"recuperer_fond" qui a *toutes* les infos de contexte dans ses "args",
et qui est mieux qu'affichage_final puisqu'avant cache… sauf qu'il n'est
apparemment pas appelé pour les squelettes racines ! Gros problèmes de
cohérence donc, on l'a pour tous les squelettes (content/truc etc) mais
pas quand on a besoin du <html> ou <head>.

On ne comprend pas pourquoi quand on connait ce pipeline (et encore
moins pour quelqu'un qui découvrirait SPIP…) et d'ailleurs la doc ne
l'explique pas, ni même ne le mentionne (donc par défaut on se dit que
c'est bien pour tous les squelettes) :

Il y a peut-être une explication logique connues de deux personnes :),
mais la logique voudrait quand même qu'on ait accès à la même
fonctionnalité quelque soit le squelette, c'est quand même plus facile à
apprendre et comprendre.

Sinon comme justement recuperer_fond ne marche pour l'instant pas, ça se
base sur ce que tu avais proposé à Fil pour Dublin Core :

S'il y a mieux ou si on peut corriger la cohérence de recuperer_fond,
oui oui oui !

--
RastaPopoulos