Cette page à pour but de noter en vrac les idées sur le sujet de la page ReveS.
Pour l’instant, je pense qu’il est trop tôt pour coder quoi que ce soit, mais ça n’empèche pas de lister les points techniques à ne pas oublier, les idées de solutions et les approches techniques possibles.
Premier point : plus j’y réfléchis, plus les objets et les classes s’imposent.
Pas de panique, il n’est pas question de sortir UML, EJB ou je ne sais quel MVC, mais de simplement profiter de la notion d’espace de nommage qu’apporte la syntaxe objet (on parle donc bien de syntaxe objet, pas de programmation objet et encore moins de modélisation objet)
Par exemple, pour mettre en place la fonctionnalité xyz, qui nécessite de définir les actions machin et truc, il suffit d’inclure un fichier qui défini une classe xyz avec les méthodes machin et truc pour pouvoir appeler xyz::machin.
On l’utilise comme une fonction de base, comme c’est le cas partout dans spip (à quelques exceptions près), mais au moins, on profite de la notion de classe pour que n’importe qui puisse comprendre que la fonction machin fait partie du module xyz sans trop alourdir le code.
Coté admin, il "suffit" d’avoir une configuration qui gère une table pour faire la relation entre la fonctionnalité xyz et le fichier xyz_toto.php qui est la version toto de l’implémentation de xyz.
Il suffit de changer cette entrée pour mettre une autre implémentation de xyz à la place, par exemple pour profiter d’un module php spécifique.
Quand un code utilise la fonctionnalité xyz, il suffit qu’il appelle include_module("xyz")qui va lire la config pour faire le require_once du fichier spécifié.
En php5 (à vérifier pour php4), il est possible de définir des "callback" à appeler lorsqu’on demande une fonction inexistante. Ce callback peut alors s’occuper automatiquement du require_once.
Le cas du module de cache est un peu différent, puisqu’il peut y avoir plusieurs exemplaires de cache en même temps (squelettes, pages, metas ..). Du coup, il faut, par exemple des classes cache_squelette, cache_page et cache_meta, sauf que rien n’empèche d’utiliser la même implémentation pour les 2 premiers et une autre pour la troisième ! De plus, chaque fonctionnalité à besoin de ses propres paramètres (répertoire et fichiers du cache par exemple).
Cette fois, il faut donc utiliser des instances :
Le début peut être généré facilement par la gestion de config, mais ensuite, chaque appel devient un peu plus lourd à écrire. En php4, on peut (je crois) écrire $nomDeLaClasse::méthode(..), mais il me semble que c’est interdit en php5 (quelqu’un peut-il confirmer ?).
Le point précédent montre qu’il y a deux groupes de modules : ceux dont on peut avoir besoin en plusieurs exemplaires (cache par exemple, mais aussi accès bdd ou authentification (spipi+ldap par exemple)) et ceux pour lesquels ça n’a pas de sens (metas et i18n par exemple).
Par ailleurs, on peut différencier des modules de premier niveau, c’est à dire permettant demettre en place une fonction de spip en lui même (moteur typo, compilateur de squelettes), de ceux de deuxième niveau, c’est à dire des outils utilisés par ceux de premier niveau (accès bdd, gestion de session)
C’est LE point compliqué de l’histoire, car il faut pouvoir monter une nouvelle brique, la démonter, et la remplacer par une autre (y compris si elle a des dépendences vers d’autres) sans tout casser. le montage doit prévoir des opération de pré-montage (pour préparer le terrain), ld’installation proprement dite (ajout de fichiers uniquement théoriquement) et de post-montage (ajout de tables, modifications de fichiers, changement de droits ...)
On peut d’ailleurs imaginer des briques ne contenant que des opérations de pré et post, comme par exemple la configuration du charset. Ainsi, l’installation d’un charset consiste juste à faire un post pour mettre la variable de config à jour, et le remplacement d’un charset par un autre consiste à faire un pré de type "export a l’ancien charset", et un post de type "config du charset puis import du contenu au nouveau charset".
Le système de packaging autour de PHP est PEAR. L’installeur mérite un coup d’oeil : gestion des dépendances, interface simple. Il n’a pas l’air de supporter les scripts de pré et post-montage. La base de donnée centrale de PEAR , qui sert à distribuer des librairies et des applications SPIP, propose des lignes directrices pour la qualité et la présentation du code qu’il pourrait être intéressant de considérer. [Minh]
Je creuse la piste sur la page LegoPear ...
Une brique doit donc contenir :
N’étant ni developpeur php, ni javascripteur confirmé, je ne peux ici que livrer mes premières impressions de graphiste sur ce doux rève :
SPIP 2.0 modulable, accessible, valide xhtml et CSS, multilingue ; le bonheur .
Évolution ou révolution ?
Actuellement en train de plancher avec bionet sur le nouveau squelette de BIOSPIP XL (sous SPIP 1.8b2) qui, à l’instar de ce projet, reprend le principe des modules mais, du point de vue admininistrateurs/rédacteurs/utilisateurs, je ne comprends toujours pas pourquoi des développeurs compétents continuent à proposer un noyau hermétique, surchargeable par de rares échappements gourmants et complexes (mes_fonctions, avec un bémol pour mes_options), truffés de balises et attributs obsolètes, et dont la nécessaire évolution obéit à un directoire "pyramidal".
Où sont passés nos idéaux ?
A une heure où nombre de graphistes sont contraints d’abandonner leurs mauvaises habitudes (mise en page en tableaux imbriquées, javascripts lourdingues et images découpées dans le code) et où la séparation contenu, styles, comportements nous ouvre de nouveaux horizons, il serait grand temps de revenir à la simplicité et à la coopération plurilatérale, autant pour ce qui concerne l’organisation du noyau de SPIP que pour celle de son évolution.
Un pavé dans la marre ?
En cela, j’adhère complètement à ce projet et je suis disponible pour apporter mes petites briques à l’édifice (car je ne néglige pas la somme de travail et d’abnégation qu’il impose), en prenant en charge une partie de la réécriture des squelettes et des styles CSS, en privilégiant, sans trop rentrer dans les détails techniques, l’utilisation des balises adéquates (listes et listes de définitions à la place du surplus de calques, paragraphes et tableaux), en attribuant à chaque élément containeur un idendifiant propre et précis et à chaque élément contenu une class générale ou spécifique selon sa destination, pour que chacun puisse contribuer à la réalisation de modules unitaires simples et faciles à intégrer.
Une pierre à l’édifice ?
Imaginez maintenant le coeur de SPIP comme plusieurs pages complémentaires du JARDIN ZEN CSS, concevoir un habillage pour un code source propre et limpide de cette qualité, deviendrait non seulement un plaisir, mais surtout, un jeu d’enfant.
Lego ou Monopoly ?
Pour conclure, quand on joue au Lego à plusieurs, tout le monde s’amuse. Au monopoly, même le vainqueur à les boules, surtout si les dés sont "spippés".
Web services
Il faut bien admettre qu’avec déjà le serveur de doc, de maths et de correction d’orthographe, SPIP est devenu assez buzzword-compliant au niveau du web-service. On pourrait avoir un jour intérêt à regarder du côté de XML/RPC qui semble une version légère de SOAP. C’est un protocole pour faire parler deux scripts PHP entre eux...
[PiiF] c’est effectivement un moyen d’emballer proprement certaines communications, mais par exemple, le correcteur d’orthographe doit être son propre module avec une api définie, et il peut faire appel lui même à un module xml/rpc ou soap ou autre pour causer au serveur. Donc pour moi, un module xml/rpc peut effectivement avoir sa place dans spip, mais en temps que "sous module" d’une autre fonctionnalité.