[spip-dev] les metas

Dev
1

Je suis en train de regarder le fonctionement de Spip, et il me semble qu'il y a un truc bizzare dans la gestion des metas.

Spip aime bien les variables globales, soit, c'est un choix.

Donc lorsqu'on appelle la page index.php3, sommaire.php3 est appelé qui lui même appelle inc-public.php3.
Système classique pour centraliser le code tout en ayant des urls qui ressemble à quelquechose.

inc-public.php3 appelle inc-meta.php3 avec un système équivalent à include_once apparu avec PHP 4.0.1pl2.
inc-meta.php3 propose 3 fonctions : lire, ecrire, effacer. Il y a même un système de cache pour éviter de martyriser Mysql inutilement.

Sauf qu'il y a quelques soucis de logique, on peut effacer une clef, mais pas en créer, juste en modifier. Est il envisageable de normaliser la syntaxe pour que des contribs utilise le système des métas sans tout casser?
En utilisant une clef avec un prefixe, par exemple 'maContrib.maClef', comme ça, on peut faire le ménage avec un LIKE 'maContrib.%'.

Deuxième soucis, le cache.
Le script réecrit var_export apparu dans php 4.2.0, c'est pour des raisons historique et de compatibilité, normal, et puis ça marche trés bien. A la fin, le script appele lire_metas() qui déclenche une requète SQL.
Le cache est court circuité.

Visiblement, inc-metas.php3 était appelé par ecrire/inc.php3 aprés avoir vérifié la présence du cache.
Maintenant, il est appelé directement.

Tout étant imbriqué, je ne sais pas par quel bout il faut attaquer pour corriger ça sans tout casser.

M.

2

Bart Braem wrote:

3

Salut Mathieu,

On voit aussi un petit soucis avec les métas, 1 requète avec un COUNT,
puis 2 SELECT alors que le résultat est censé être en cache. Les métas
sont fréquement utilisés dans le code (63 occurences de ecrire_meta, 430
pour lire_meta), en corrigeant ça, on doit pouvoir gagner des pouillèmes.

Le inc_meta_cache n'est utilisé que par l'espace public, cela permet
d'éviter les connexions inutiles à MySQL.
Pour l'espace privé, les requêtes MySQL sont le plus souvent
négligeables face aux temps de parsing et d'interprétation PHP.

Amicalement

Antoine.

4

on pourrait ptet intégrer cela en standart sur la 1.8
http://www.gasteroprod.com/2004/06/09/galerie_spip_pour_reutiliser_facilement_images_documents_383.html

5

Cela serait également intéressant pour pouvoir gérer un agenda de façon plus précise ou pour permettre un classement des articles plus précis (si je veux remettre un article en avant pas besoin de changer la date, changer l'heure suffit on gagne en souplesse). Cela peut etre également une solution pour les problemes de décalage horaire
http://www.spip-contrib.net/ecrire/articles.php3?id_article=633

6

Elle est marquée "compatible avec la 1.8alpha; est-ce qu'elle est aussi compatible avec la CVS courante,
notamment en mode protégé ?

      Emmanuel

7

Déesse A. a écrit :

on pourrait ptet intégrer cela en standart sur la 1.8
http://www.gasteroprod.com/2004/06/09/ galerie_spip_pour_reutiliser_facilement_images_documents_383.html

Je me demande s'il n'y a pas plus ergonomique, genre une nouvelle page, carrement, accesible depuis la rédaction d'un article pour association rapide certes, mais surtout accessible depuis la page des documents.

Cette page présenterait les documents bien rangés, et permettrait de les associer aux articles, parmi d'autres outils de gestion (déplacer, etc).

C'est une idée, mais je pense qu'il y a quelque chose de bien a faire pour les documents dans Spip, surtout dans le cadre de cette nouvelle admin dont l'ergonomie ferait frémir la nasa :).

@+
BoOz

note : en Français gallery s'écrit galerie.

8

Je reste toujours opposé à la galerie de documents dans l'espace privé. C'est une contrib, en ce sens que son usage est problématique et doit rester limiter aux webmestres qui savent ce qu'ils font (et, franchement, je doute que ça soit même le cas...).

- Réutiliser des documents à différents endroits reste problématique. C'est chiant comme tout.
      * Si on réutilise tel quel (simple <imgXX> dans plusieurs articles), alors c'est une catastrophe: supprimer ou modifier un élément (que ce soit le document lui-même ou simplement ses titre et descriptif) conduit à un désastre ailleurs;
      * si on «duplique» automatiquement, on fabrique de la redondance de fichiers, au passage à chaque fois on augmente le nombre de documents identiques dans cette «galerie»...

- Dans la pratique, réutiliser un document dans plusieurs documents est problématique et induit des comportements et des structures de sites totalement bancales. Principalement parce que, que ce soient des documents joints ou des images, cela signifie qu'on promeut un comportement de redondance: publier plusieurs choses dans différents endroits structurels du site (une même image dans plusieurs articles, un même document joint à plusieurs endroits...).
      * Soit c'est de l'élément d'information, et alors la duplication d'information dans la structure de SPIP signifie généralement une mauvaise structuration de l'information;
      * soit c'est de l'émément «décoratif», et là ça signifie qu'on s'amuse à faire du graphisme depuis l'espace privé.

- Par ailleurs, gros travail sur la version actuelle pour favoriser la création de portfolios.
      * Donc multiplication des documents, donc soit on complexifie à l'extrême l'interface de la «galerie de documents», soit elle devient rapidement inutilisable;
     * les portfolios favorisent la séparation entre les «galeries» et le contenu textuel, avec des interfaces automatisées plus agréables; avec la «galerie de documents», on introduit un élément de confusion très pénible entre les «portfolios» tels que publiés et une «galerie» de l'espace privé.

Bref, énormément d'inconvénients, avec essentiellement le fait que ça favorise énormément un mauvais usage du CMS (redondance d'information dans la structure) alors que les usages réellement utiles sont peu évidents.

ARNO*

9

ok tres bonnes remarques je suis convaincu on laisse en contrib.
Et pour l'integration du parametre heure minute dans les dates?

10

- Dans la pratique, réutiliser un document dans plusieurs documents est
problématique et induit des comportements et des structures de sites
totalement bancales. Principalement parce que, que ce soient des
documents joints ou des images, cela signifie qu'on promeut un
comportement de redondance: publier plusieurs choses dans différents
endroits structurels du site (une même image dans plusieurs articles,
un même document joint à plusieurs endroits...).
      * Soit c'est de l'élément d'information, et alors la duplication
d'information dans la structure de SPIP signifie généralement une
mauvaise structuration de l'information;
      * soit c'est de l'émément «décoratif», et là ça signifie qu'on
s'amuse à faire du graphisme depuis l'espace privé.

Il y a un troisième usage à mi-chemin, c'est l'usage illustratif. Quand
j'insère une image dans un article, ce n'est pas à proprement parler de
l'information (sauf si c'est un diagramme très précis, ou une photo
prouvant la présence d'armes de destruction massives dans un champ de
haricots), mais ce n'est pas de la décoration pure non plus. Il y a un
rapport au sujet de l'article sans que ce soit exclusif. Penser par
exemple aux peintures modernes utilisées dans le Diplo (bon, là le
rapport au sujet peut être assez lointain ;-)). Sur un gros site, il
peut être utile de vouloir réutiliser ces images de temps en temps.

Plus couramment, la réutilisation est souhaitable quand on gère des
traductions entre articles, et qu'il y a des illustrations. La plupart
du temps, les illustrations originales conviennent (et même quand il
faudrait les retravailler pour les adapter au contexte linguistique, les
traducteurs ont la flemme ou ne maîtrisent pas les outils nécessaires).
Il y a le cas souvent sur www.spip.net.

Souvent, les images qu'on insère (par opposition à "lier" ou "joindre")
dans les articles sont dépourvues de titre et de descriptif, donc pas de
problème d'adéquation de ce côté-là.

Enfin, il est pénible de réinsérer une image déjà insérée par un autre
auteur, surtout si on n'a pas de copie locale : il faut alors la
télécharger sur son disque dur puis la réuploader, la plupart des
rédacteurs sont perdus face à ce genre de manoeuvre.

D'une manière générale, dans la plupart des cas la réutilisation n'est
pas justifiée (surtout pour les documents contenant de l'information
textuelle : c'est-à-dire tout ce qui n'est pas images et éventuellement
animations Flash).

La contrib "galerie" sus-citée a l'effet de bord intéressant de proposer
une vue générale des documents du site, même si la visualisation est
assez faillible AMHA (et le principe d'un bouton dans la barre d'icones
alors que les formulaires d'ajout de documents sont à gauche ne me
paraît pas génial non plus). Il y a une version améliorée chez Linagora,
je crois qu'elle sera mise à disposition si elle en vaut la peine.

a+

Antoine.

11

Pour abonder dans le sens d'Antoine, exemple à l'appui

site association sportive : j'ai une photo d'un(e) coureur(euse) dans une course, ca peut illustrer de maniere tout aussi pertinente un article sur la course, ou un autre sur son cv sportif, ou un autre sur un geste technique, ou un autre sur le matériel qu'il utilise, ou encore un autre sur l'historique d'un club, etc ....

site technique : j'ai une photo (ou un graphe généraique) sur une passerelle (exemple parmi d'autre), ca peut tout aussi bien illustrer un article sur l'objet architectural, un autre sur les structures, un autre sur le CV du concepteur, ou encore un autre sur l'évolution des passerelles au cours des ages

Cet usage ne me parait pas bancal, et cela me parait dommageable de se priver d'une possibilité de gestion de la banque d'image et de documents que beaucoup de sites spip finissent par se constituer naturellement

Par contre ce qui peut poser probleme c'est la légende qui n'est pas la même en général (suffit de pas l'afficher et de la mettre dans le texte) et comme cité par ARNO les contraintes de cohérence dans le temps : faudrait peut etre disposer des liens comme pour les articles en traductions.

@+
Nicolas RIQUOIS
http://www.pucroller.com

12

Bonjour,

on pourrait ptet intégrer cela en standart sur la 1.8
http://www.gasteroprod.com/2004/06/09/galerie_spip_pour_reutiliser_facilement_images_documents_383.html

Il reste à traiter les droits d'accès aux documents, pour que n'importe qui n'ai pas accès à tous les documents ...

-Nicolas

13

Bonjour,

Elle est marquée "compatible avec la 1.8alpha; est-ce qu'elle est aussi compatible avec la CVS courante, notamment en mode protégé ?

J'avoue ne pas l'avoir essayée avec les dernières versions du CVS.

-Nicolas

14

[...] le principe d'un bouton dans la barre d'icones
alors que les formulaires d'ajout de documents sont à gauche ne me
paraît pas génial non plus).

J'ai jugé qu'il y avait une différence entre la gestion des docs attachés à l'article (à gauche) et l'utilisation de n'importe quel doc du site dans le texte, qui a plus sa place dans la barre de raccourcis.

Il y a une version améliorée chez Linagora,
je crois qu'elle sera mise à disposition si elle en vaut la peine.

En tout cas, toute version améliorée de ce que je fais m'intéresse toujours, bien sûr !

-Nicolas