[SPIP Zone] Metas + (réflexions)

tcharlss · Janvier 23, 2018, 6:58

Hello tetue et erational (et les autres contributeur.ice.s du plugin).

Merci pour le plugin métas+, très pratique pour implémenter rapidement les trucs opengrapho-dublino-twitteresques.
Je me demande s'il n'y aurait pas moyen de faciliter un peu l'implémentation.

Rappel du fonctionnement actuel pour se rafraichir la mémoire :
- Le plugin fournit des squelettes à inclure dans le <head> de nos squelettes.
- Il y a des inclure spécifiques pour les principaux objets éditoriaux (articles, rubriques, évènements, etc.), et un inclure générique pour le reste.
- Pour les objets non prévus par le plugin, il faut créer des nouveaux squelettes dans son projet.

Je pense qu'on pourrait avoir un squelette générique à inclure qui permettrait une prise en charge basique de tous les objets éditoriaux, puisqu'on peut récupérer la plupart des données nécessaires au moyen de la balise #INFO (titre, description, url, logo, etc.) ou de boucles sur les tables de liens (pour les auteurs, la localisation, les coordonnées et cie).
Bien sûr cette prise en charge a ses limites, on ne peut pas deviner exactement toutes les valeurs (par exemple l'og:type, qui serait "article" par défaut).
Dans les cas où ce squelette ne suffirait pas, et *uniquement* dans ce cas, il faudrait alors créer des variantes spécifiques dans nos squelettes.
Dans le plugin au final, il n'y aurait plus besoin que du seul squelette générique.

Au niveau du rangement/nomenclature, je pensais à quelque chose inspiré de z-core :
inclure
|_ metasplus
|_dist.html => le squelette générique par défaut
|_papate.html => les squelettes optionnels de certains objets *uniquement si nécessaires*

Et l'inclusion marcherait ainsi :
- s'il existe une variante précise pour tel objet, on la prend
- sinon, on récupère nous même les infos de façon générique

Je me dis également que l'inclusion dans le <head> pourrait être automatique.
Avantage : on active le plugin => pouf, ça marche ! Ça prend en charge toutes les pages du site par défaut, sans avoir rien à faire.
Et au niveau intégration, on n'aurait plus qu'à créer quelques squelettes dans inclure/metasplus uniquement quand on veut plus d'informations que ce que fournit le squelette générique pour tel objet.

Voilà ce que j'avais fait pour un projet récent, pour avoir une idée de ce à quoi pourrait ressembler le squelette générique : http://spip.pastebin.fr/52943

Bon, ça pose des questions pour la rétro-compatibilité, mais c'est pour voir déjà ce que vous pensez du principe.

Glop !

rastapopoulos · Janvier 23, 2018, 7:21

Le 23/01/2018 à 19:58, Charles Razack a écrit :

Avantage : on active le plugin => pouf, ça marche ! Ça prend en charge
toutes les pages du site par défaut, sans avoir rien à faire.
Et au niveau intégration, on n'aurait plus qu'à créer quelques
squelettes dans inclure/metasplus uniquement quand on veut plus
d'informations que ce que fournit le squelette générique pour tel objet.

+1

--
RastaPopoulos

erational · Janvier 24, 2018, 7:26

Hello Charles,

Sur le principe général, je suis d'accord,
Cela simplifie la mise en œuvre et le rendre automatiquement extensible

Quelques questions / remarques:
- sur l'insert automatique dans head, oui volontiers pas mais il faut pouvoir avoir la main dans les cas
.... où on ne veut rien insérer sur certaines pages (pages techniques ou non indexables, ....)
.... où on veut forcer manuel un ou des paramètres
- sur la retro-compatibilité, on peut le signaler par un changement de y. ce n'est pas bloquant il me semble
- il reste aussi un point sur le code langue ex.fr_FR,
pour l'instant c'est une bidouille
à terme, il faudrait pouvoir le gérer proprement

Le 23/01/2018 à 19:58, Charles Razack a écrit :

Hello tetue et erational (et les autres contributeur.ice.s du plugin).

Merci pour le plugin métas+, très pratique pour implémenter rapidement les trucs opengrapho-dublino-twitteresques.
Je me demande s'il n'y aurait pas moyen de faciliter un peu l'implémentation.

Rappel du fonctionnement actuel pour se rafraichir la mémoire :
- Le plugin fournit des squelettes à inclure dans le <head> de nos squelettes.
- Il y a des inclure spécifiques pour les principaux objets éditoriaux (articles, rubriques, évènements, etc.), et un inclure générique pour le reste.
- Pour les objets non prévus par le plugin, il faut créer des nouveaux squelettes dans son projet.

Je pense qu'on pourrait avoir un squelette générique à inclure qui permettrait une prise en charge basique de tous les objets éditoriaux, puisqu'on peut récupérer la plupart des données nécessaires au moyen de la balise #INFO (titre, description, url, logo, etc.) ou de boucles sur les tables de liens (pour les auteurs, la localisation, les coordonnées et cie).
Bien sûr cette prise en charge a ses limites, on ne peut pas deviner exactement toutes les valeurs (par exemple l'og:type, qui serait "article" par défaut).
Dans les cas où ce squelette ne suffirait pas, et *uniquement* dans ce cas, il faudrait alors créer des variantes spécifiques dans nos squelettes.
Dans le plugin au final, il n'y aurait plus besoin que du seul squelette générique.

Au niveau du rangement/nomenclature, je pensais à quelque chose inspiré de z-core :
inclure
|_ metasplus
|_dist.html => le squelette générique par défaut
|_papate.html => les squelettes optionnels de certains objets *uniquement si nécessaires*

Et l'inclusion marcherait ainsi :
- s'il existe une variante précise pour tel objet, on la prend
- sinon, on récupère nous même les infos de façon générique

Je me dis également que l'inclusion dans le <head> pourrait être automatique.
Avantage : on active le plugin => pouf, ça marche ! Ça prend en charge toutes les pages du site par défaut, sans avoir rien à faire.
Et au niveau intégration, on n'aurait plus qu'à créer quelques squelettes dans inclure/metasplus uniquement quand on veut plus d'informations que ce que fournit le squelette générique pour tel objet.

Voilà ce que j'avais fait pour un projet récent, pour avoir une idée de ce à quoi pourrait ressembler le squelette générique : http://spip.pastebin.fr/52943

Bon, ça pose des questions pour la rétro-compatibilité, mais c'est pour voir déjà ce que vous pensez du principe.

Glop !

----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

--
_________________________________________

tcharlss · Janvier 24, 2018, 11:04

Le 24/01/2018 à 08:26, erational a écrit :

Quelques questions / remarques:
- sur l'insert automatique dans head, oui volontiers pas mais il faut pouvoir avoir la main dans les cas
.... où on ne veut rien insérer sur certaines pages (pages techniques ou non indexables, ....)
.... où on veut forcer manuel un ou des paramètres

Je vois 2 possibilités :

- Toujours sur le principe de z-core, quand on ne veut pas de l'ajout sur certaines pages, il faudrait créer des fichiers vides inclure/metasplus/[page].html
- Ou alors une constante / page de config ou on pourrait lister les pages à ignorer

Dans le cas où on voudrait forcer certains paramètres sur des pages précises (tout en conservant les autres params), on pourrait, toujours dans inclure/metasplus/[page].html, faire <INCLURE{fond=inclure/metasplus/dist, param1=truc, param2=machin />

- sur la retro-compatibilité, on peut le signaler par un changement de y. ce n'est pas bloquant il me semble

Oui je pense qu'on peut rerouter les squelettes actuels vers le nouveau sans trop de difficulté, en indiquant qu'ils sont comme obsolètes en commentaire.
Il y a une difficulté tout de même : les gens ont déjà ajouté des inclures dans leur head. S'ils ne pensent pas à le retirer, il faudrait dans ce cas ne pas faire l'inclusion automatique.

- il reste aussi un point sur le code langue ex.fr_FR,
pour l'instant c'est une bidouille
à terme, il faudrait pouvoir le gérer proprement

Oui tout à fait.

b_b · Janvier 24, 2018, 11:33

Hop,

Le 23/01/2018 à 19:58, Charles Razack a écrit :

Hello tetue et erational (et les autres contributeur.ice.s du plugin).

Merci pour le plugin métas+, très pratique pour implémenter rapidement les trucs opengrapho-dublino-twitteresques.
Je me demande s'il n'y aurait pas moyen de faciliter un peu l'implémentation.

Bonne idée

Voilà ce que j'avais fait pour un projet récent, pour avoir une idée de ce à quoi pourrait ressembler le squelette générique : http://spip.pastebin.fr/52943

Par contre, je doute sur l'implémentation, le squelette que tu donnes en exemple contient 6 balises #INFO_ et donc autant de requêtes SQL, alors qu'aujourd'hui il n'y en a que deux (sous forme de boucle) pour un article par exemple. Mais bon, ça n'est peut-être pas si grave que ça...

++
b_b

erational · Janvier 24, 2018, 12:20

Le 24/01/2018 à 12:04, Charles Razack a écrit :

Le 24/01/2018 à 08:26, erational a écrit :

Quelques questions / remarques:
- sur l'insert automatique dans head, oui volontiers pas mais il faut pouvoir avoir la main dans les cas
.... où on ne veut rien insérer sur certaines pages (pages techniques ou non indexables, ....)
.... où on veut forcer manuel un ou des paramètres

Je vois 2 possibilités :

- Toujours sur le principe de z-core, quand on ne veut pas de l'ajout sur certaines pages, il faudrait créer des fichiers vides inclure/metasplus/[page].html
- Ou alors une constante / page de config ou on pourrait lister les pages à ignorer

Dans le cas où on voudrait forcer certains paramètres sur des pages précises (tout en conservant les autres params), on pourrait, toujours dans inclure/metasplus/[page].html, faire <INCLURE{fond=inclure/metasplus/dist, param1=truc, param2=machin />

dans ce cas ca me va.

- sur la retro-compatibilité, on peut le signaler par un changement de y. ce n'est pas bloquant il me semble

Oui je pense qu'on peut rerouter les squelettes actuels vers le nouveau sans trop de difficulté, en indiquant qu'ils sont comme obsolètes en commentaire.
Il y a une difficulté tout de même : les gens ont déjà ajouté des inclures dans leur head. S'ils ne pensent pas à le retirer, il faudrait dans ce cas ne pas faire l'inclusion automatique.

- il reste aussi un point sur le code langue ex.fr_FR,
pour l'instant c'est une bidouille
à terme, il faudrait pouvoir le gérer proprement

Oui tout à fait.

hormis la remarque de perf de b_b
on dit go go go ?

ajoute toi dans auteur du plugin et de la doc.

merci

----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

--
_________________________________________

tcharlss · Janvier 24, 2018, 12:44

Le 24/01/2018 à 13:20, erational a écrit :

hormis la remarque de perf de b_b
on dit go go go ?

C'est parti !
À ton avis, un changement de x ou de y ?
Je copie le trunk dans une branche v1 avant de faire les changements ?

Pour les remarques sur la perf, c'est noté, je vais voir si et comment il y a moyen d'optimiser.

erational · Janvier 24, 2018, 1:31

Le 24/01/2018 à 13:44, Charles Razack a écrit :

Le 24/01/2018 à 13:20, erational a écrit :

hormis la remarque de perf de b_b
on dit go go go ?

C'est parti !
À ton avis, un changement de x ou de y ?

comme tu veux

Je copie le trunk dans une branche v1 avant de faire les changements ?

oui stp

Pour les remarques sur la perf, c'est noté, je vais voir si et comment il y a moyen d'optimiser.

bosse bien !

----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

--
_________________________________________

rastapopoulos · Janvier 24, 2018, 2:24

Le 24/01/2018 à 12:33, Bruno Bergot a écrit :

Par contre, je doute sur l'implémentation, le squelette que tu donnes en
exemple contient 6 balises #INFO_ et donc autant de requêtes SQL, alors
qu'aujourd'hui il n'y en a que deux (sous forme de boucle) pour un
article par exemple. Mais bon, ça n'est peut-être pas si grave que ça...

Calomnie.

Depuis son tout premier commit cette fonction ne fait *qu'une* requête
SQL avec "*" sur la table de l'objet, et garde dans une static. La
prochaine balise #INFO sur la même table (dans le même squelette ou même
un autre, du moment que c'est dans le même hit PHP) va donc piocher dans
la static qui a déjà tout.

#INFO c'est bon, mangez-en ! (ça fait de l'#INFObésité)

--
RastaPopoulos

b_b · Janvier 24, 2018, 2:28

Hop,

Le 24/01/2018 à 15:24, RastaPopoulos a écrit :

Calomnie.

Depuis son tout premier commit cette fonction ne fait *qu'une* requête
SQL avec "*" sur la table de l'objet, et garde dans une static. La
prochaine balise #INFO sur la même table (dans le même squelette ou même
un autre, du moment que c'est dans le même hit PHP) va donc piocher dans
la static qui a déjà tout.

#INFO c'est bon, mangez-en ! (ça fait de l'#INFObésité)

Cool, thx pour l'#INFO_

#INFO_XXX - SPIP <= à préciser ici pit-être ? Afin d'éviter toute calomnie future...

++
b_b

maieul · Janvier 24, 2018, 2:30

Le 24/01/2018 à 15:28, Bruno Bergot a écrit :

Hop,

Le 24/01/2018 à 15:24, RastaPopoulos a écrit :

Calomnie.

Depuis son tout premier commit cette fonction ne fait *qu'une* requête
SQL avec "*" sur la table de l'objet, et garde dans une static. La
prochaine balise #INFO sur la même table (dans le même squelette ou même
un autre, du moment que c'est dans le même hit PHP) va donc piocher dans
la static qui a déjà tout.

#INFO c'est bon, mangez-en ! (ça fait de l'#INFObésité)

Cool, thx pour l'#INFO_

#INFO_XXX - SPIP <= à préciser ici pit-être ? Afin d'éviter toute calomnie future...

++
b_b
----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

je découvre, donc oui !

Debondt_Didier · Janvier 24, 2018, 3:08

Depuis son tout premier commit cette fonction ne fait *qu'une* requête
SQL avec "*" sur la table de l'objet, et garde dans une static. La
prochaine balise #INFO sur la même table (dans le même squelette ou même
un autre, du moment que c'est dans le même hit PHP) va donc piocher dans
la static qui a déjà tout.

#INFO c'est bon, mangez-en ! (ça fait de l'#INFObésité)

Cool, thx pour l'#INFO_

#INFO_XXX - SPIP <= à préciser ici
pit-être ? Afin d'éviter toute calomnie future...

Je découvre aussi, et je suis certain qu'on est un gros paquet à penser
que cela fait une requête par balise INFO_

Du coup, le préciser dans la documentation me semble indispensable !