Quand on s’intéresse aux systèmes de publication sur Internet, on a la forte impression que chacun réinvente la roue de son côté, refaisant pour chaque composant du logiciel sa propre implémentation.
Textwheel s’attaque à l’un de ces composants : la transformation d’un texte « brut » en texte présentable à l’écran.
Par exemple, sous SPIP, on transforme :{Hello} {{World}}
en :<i>Hello</i> <strong>World</strong>
Sous Textile, on transforme :_Hello_ *World*
en :<em>Hello</em> <strong>World</strong>
En BBCode, on aura :[i]Hello[/i] [b]World[/b]
L’ennui jusqu’ici c’est que chaque logiciel (gestion de contenu, gestion de forums) est livré avec ses propres raccourcis, dans sa propre implémentation. Il n’y a donc ni standard, ni possibilité d’échanger, ni possibilité de modifier ses raccourcis. Textwheel est une proposition visant à répondre à ces soucis d’interopérabilité.
Le principe : avec Textwheel, plutôt que de coder une fonction qui effectue ces règles de transformation, on les décrit dans un fichier de configuration (ex : spip.yaml
), au format très simple (YAML). Textwheel se chargera d’appliquer ces règles.
Ainsi, Textwheel sépare la création des « raccourcis d’édition » de leur implémentation technique.
Avec Textwheel, les raccourcis de SPIP se programment donc ainsi :
strong:
match: [ "{{", "}}" ]
replace: [ "<strong>", "</strong>" ]
italics:
match: [ "{", "}" ]
replace: [ "<i>", "</i>" ]
Ceux de Textile :
strong:
match: "/\*(\w*)\*/U"
replace: "<strong>\1</strong>"
italics:
match: "/_(\w*)_/U"
replace: "<em>\1</em>"
et le BBCode :
strong:
match: [ "[b]", "[/b]" ]
replace: [ "<strong>", "</strong>" ]
italics:
match: [ "[i]", "[/i]" ]
replace: [ "<i>", "</i>" ]
On voit qu’il est dès lors très facile d’ajouter les raccourcis BBCode ou Textile dans SPIP, ou l’inverse, en manipulant des fichiers de configuration. Bien entendu les cas plus complexes (callbacks, expressions rationnelles) sont prévus.
Avantages de Textwheel
L’interopérabilité entre logiciels n’est pas le seul avantage.
Extensibilité. Il est plus aisé pour un utilisateur de manipuler un fichier de configuration au format établi, que de se plonger dans des modifications de code qui peuvent sauter à chaque mise à jour.
Traitements. Dès lors que les raccourcis sont codés de manière descriptive, et non pas fonctionnelle, il est possible de leur faire subir des traitements qui ne se limitent pas à les appliquer à un texte. On peut par exemple les appliquer à la chaîne sur l’ensemble des textes d’une base de données, et voir lesquels sont utilisés, combien de fois, à quels textes... et à quelle vitesse.
Rapidité. Ce qui permet de détecter des règles mal programmées, inutiles, trop lentes ou pas efficaces. En appliquant cette méthodologie aux raccourcis de SPIP, nous avons pu en quelques jours diviser par deux le temps de calcul des textes (sur certaines bases de texte d’usage réel).
Compilation. Une autre sortie possible pour un fichier de raccourcis, c’est une compilation sous forme de code dans un langage arbitraire (par exemple : PHP, python, ruby, javascript, C...). Cette approche devrait permettre à terme de retrouver les mêmes raccourcis sous différents logiciels, quel que soit leur langage de programmation, et aussi bien côté serveur (PHP, python) que client (javascript).
Tests unitaires. Jusqu’ici les raccourcis avaient tendance à « casser » dès lors qu’on mettait les mains dans le code, et il était bien difficile, lorsqu’on constatait un bug, de voir à quel niveau des traitements le résultat devenait non conforme. Maintenant que notre moteur peut comparer, pour chaque règle, le résultat obtenu avec sa valeur attendue, un jeu de tests peut non seulement nous dire si quelque chose a changé, mais nous dire aussi précisément quoi.
Évolutivité. Cette approche devrait permettre de redynamiser le travail sur les raccourcis (introduction de nouveaux raccourcis, suppression de raccourcis obsolètes, amélioration de raccourcis mal foutus...). Car on peut imaginer construire un outil qui permettra de signaler le cas échéant au webmestre qui met à jour son site qu’il aura, par exemple, deux articles à vérifier (et lesquels) suite à une amélioration du code. Outil qui sera basé sur de simples fichiers YAML.
Télécharger
Le projet est développé, en ce moment, via git et sur github.com ; on avance en parallèle sur le moteur (http://github.com/Cerdic/textwheel/...) et sur le plugin SPIP (http://github.com/Cerdic/textwheel/).
Pour télécharger ce dernier par svn, utiliser la commande suivante :
svn checkout http://svn.github.com/Cerdic/textwheel.git/ plugins/textwheel/
Le plugin pour SPIP donne une page ?exec=tw
dans l’espace privé qui permet de voir ce qui change entre textwheel et la fonction propre()
classique de SPIP : les quelques textes où le rendu n’est pas exactement identique sont signalés, ainsi que le temps passé dans chaque rule, et le temps total des calculs.
Participer
Si cette rapide présentation vous a alléché, sachez que toutes les participations sont les bienvenues.
Le projet est, pour démarrer, codé en anglais et en PHP. Il offre d’ores et déjà des spécifications en version 0.1, une implémentation en PHP, et un plugin pour SPIP qui remplace le moteur historique de SPIP par cette nouvelle approche.
Nous n’en sommes qu’au début. Il y a beaucoup à faire sur ce projet, qu’il s’agisse d’améliorer les specs, de contribuer de la documentation, d’établir des cas tests, de coder des implémentations dans d’autres langages (ruby, javascript), etc.
Une communauté de développeurs se met en place sur la mailing-list textwheel@rezo.net ; URL : http://listes.rezo.net/mailman/listinfo/textwheel
A bientôt !
20 Messages de forum