Depuis SPIP 1.9.x, la déclaration des tables dans les globales $tables_principales et $tables_auxiliaires était nécessaire pour que les tables soient prise en compte dans la sauvegarde. Le seul moyen disponible etait le peuplement direct des globales, et cela obligeait le plus souvent à inclure prealablement base/serial et base/aux avant, et à charger toute la description à chaque calcul a minima.
On se retrouvait du coup à charger plein de descriptions de table sans arrêt, avec des impacts perfo plutot négatifs.
Dans SPIP 2.0, la méthode qui fonctionnait en 1.9.x fonctionne *toujours*
Mais les 3 pipelines
declarer_tables_interfaces
declarer_tables_principales
declarer_tables_auxiliaires
ont été introduits. Ils sont appelés par le core lorsque celui-ci a besoin des description.
Par conséquent, les utiliser permet d'être plus efficace en ne chargeant les description de table que quand c'est vraiment nécessaire.
C'est une amélioration, mais il n'y a pas de rupture de compatibilité. Ce qui fonctionnait avant fonctionne toujours.
Mais il y a de la doc à rédiger, c'est certain.
Tout comme chaque fonction du code est documentée in situ, puis récupérée par doc.spip.org, je pense que chaque pipeline devrait aussi être décrit dans le code.
Car évidement, lorsqu'un développeur invente de nouveaux pipelines, il ne pense pas et/ou n'a pas le temps d'aller sur un site internet externe pour aller le documenter. Il faut donc qu'il le fasse directement dans le PHP, au moment où il le déclare.
Les pipelines ne sont pas à un endroit unique du code, chacun peut être placé moult fois. En revanche, il y a un fichier de SPIP qui les centralise tous : inc_version.php.
C'est donc dans ce fichier, collée à chaque ligne de déclaration (comme pour les fonctions en fait), que devrait se trouver la documentation de TOUS les pipelines de SPIP.
C'est un premier pas.
Ensuite, même si ça ne se fait pas tout de suite, cela va permettre de récupérer la doc automagiquement sur doc.spip.org exactement comme pour les fonctions. Ni plus, ni moins.
Mais pour ça il faut que ceux qui ont accès au code de SPIP commentent leurs inventions.
Oui, c'est ce que je veux dire (sur le principe technique, je te fais confiance).
- Y'a des bouts de doc un peu partout, il y a les textes de Marcimat qui contiennent des trucs presque directement réutilisables en doc officielle, etc.
- Y'a quelques trucs pas du tout documentés, mais peut-être pas tant que ça. Les docs en cours sur spip.net contiennent pas mal de choses.
- Manque en revanche une structuration pour découper ça sur la doc officielle en plusieurs «articles» faciles à consulter. La partie «Je fais mon plugin par l'exemple», c'est toujours bien, mais ça doit être complété par une doc technique de référence.
Est-ce que quelqu'un a déjà commencé à travailler sur une structuration de la doc des plugins?
Ce ne sont que quelques notes prises de tête, histoire de voir s'il y a moyen d'établir une structuration pour documenter les plugins. Si on arrivait à établir une telle structure, je pense que ça nous faciliterait beaucoup la rédaction de docs, même si pour une partie on commence avec des copier-coller pas totalement rédigés.
- Déclarer le plugin (plugin.xml)
- Librairies
- Dépendances
Il y a aussi une version non à jour sur doc.spip.org
- Gérer les autorisations
il y a un début de page : faire son premier plugin sur contrib on pourrait y lister toutes ces infos ?
je rajouterai aussi :
- ajax dans l'espace privé ( sur les formulaires notamment)
- gérer des urls différentes de celles proposées de base ( url_objet par exemple )
- mettre un lien dans cette doc vers la doc de CFG
- faire une liste des plugins permettant de couvrir des besoins ( notifications, CFG, autorité, ... ) ( et éventuellement de compléter ces plugins plutot que de réinventer la roue ou d'utiliser des points d'entrées sur ces plugins ? )
- mécanisme de sécurité ( appel de la fonction "securiser" ), est-ce utile dans un plugin (je dirais oui) ?
....