SpipLab:LegoSolution

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.

{{{utiliser des classes}}}

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é <code>xyz</code>, qui nécessite de définir les actions <code>machin</code> et <code>truc</code>, il suffit d'inclure un fichier qui défini une classe <code>xyz</code> avec les méthodes <code>machin</code> et <code>truc</code> pour pouvoir appeler <code>xyz::machin</code>.
_ 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 <code>machin</code> fait partie du module <code>xyz</code> 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é
<code>xyz</code> et le fichier <code>xyz_toto.php</code> qui est la version <code>toto</code> de l'implémentation de <code>xyz</code>.
_ Il suffit de changer cette entrée pour mettre une autre implémentation de <code>xyz</code> à la place, par exemple pour profiter d'un module php spécifique.

Quand un code utilise la fonctionnalité <code>xyz</code>, il suffit qu'il appelle <code>include_module("xyz")</code>qui va lire la config pour faire le <code>require_once</code> 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 <code>require_once</code>.

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 <code>cache_squelette</code>, <code>cache_page</code> et <code>cache_meta</code>, 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 :
<code>$cache_squelette= new cache_fichier("répertoire");
$cache_page= new cache_fichier("répertoire");
$cache_meta= new cache_bdd("table");
...
$cache_meta->lire("...");
</code>

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 <code>$nomDeLaClasse::méthode(..)</code>, mais il me semble que c'est interdit en php5 (quelqu'un peut-il confirmer ?).

{{{types de modules}}}

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)

{{{l'installeur}}}

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->http://pear.php.net/manual/en/introduction.php]. 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]
_ [[PiiF Je]] creuse la piste sur la page LegoPear ...

{{{contenu d'un package}}}

Une brique doit donc contenir :
-* de quoi faire des choses avant sa première installation, après son installation, avant son installation par dessus un autre package remplissant les mêmes fonctions : des fonctions <code>avantMontage</code> et <code>apresMontage</code>. <code>avantMontage</code> doit pouvoir demander à l'installeur ce qu'il y a comme briques installées, notamment pour vérifier qu'il n'est pas en train de mettre à jour une brique, ou d'en remplacer une autre.
-* de quoi se désinstaller : une fonction <code>demontage</code>
-* des "méta données" comme un nom unique, un numéro de version, une description (en plusieurs langues si possible)
-* une liste des fonctionnalités qu'il fournit (est-ce qu'une brique peut fournir plusieurs fonctionnalités ? j'aurais tendance à dire non sinon, comment fait-on pour en remplacer une sans remplacer l'autre !)
-* une liste des fonctionnalités dont il dépend, avec éventuellement le numéro de version minimale de chacun

{{{le point de vue du designer}}}

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}} .

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".

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.

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.}}

Imaginez maintenant le coeur de SPIP comme plusieurs pages complémentaires du [JARDIN ZEN CSS->http://www.csszengarden.com/tr/francais/ ],
concevoir un habillage pour {{un code source propre et limpide}} de cette qualité, deviendrait non seulement un plaisir, mais surtout, un jeu d'enfant.

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".

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->http://www.xmlrpc.com/] 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é.