Accueil du site > SPIP > Présentation de Textwheel

Présentation de Textwheel

dimanche 15 août 2010, par Cerdic, Fil

Textwheel — littéralement, « la roue du texte » — est un projet visant à simplifier l’écriture de règles de transformation d’un texte d’un format vers un autre.

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

  • Bravo ! Continuez ! Le 15 août 2010 à 17:36 , par Beurt

    Votre travail en amont de cette annonce est vraiment impressionnant !

    Bravo à tous les deux.

    Cette implémentation a l’air prometteuse... Je ne suis pas sûr de tout comprendre (je vais essayer pour implémenter des intertitres hiérarchisés, mais j’ai l’impression que ça va être très très compliqué...), mais je vais essayer ! :-)

  • Présentation de Textwheel Le 15 août 2010 à 18:12 , par RealET

    Je tente un CheckOut depuis Windows avec Tortoise, et j’ai :
    L'URL 'http://svn.github.com/Cerdic/textwheel.git/plugins/textwheel' n'existe pas

  • Présentation de Textwheel Le 15 août 2010 à 18:17 , par RealET

    Avec Tortoise, c’était http://svn.github.com/Cerdic/textwheel.git qu’il fallait utiliser.

  • Présentation de Textwheel Le 15 août 2010 à 20:29 , par squirrel

    Hello,

    Les résultats d’optimiZZZations sont incroyable :) C’est sympa de voir que certain Framework on YAML en Écureuil :) Çà veut dire que le développement de plug In futur avec Spip tournerait avec YAML ?

    Vive la modularité de Spip !

    Squirrel

  • Présentation de Textwheel Le 20 septembre 2010 à 21:58 , par Ben.

    La distinction Tewtwheel en lui même et le plugin pour spip n’est pas évidente . Il est où le plugin SPIP ?

  • Présentation de Textwheel Le 20 septembre 2010 à 22:20 , par Cédric

    Dans le repo git, c’est le plugin SPIP pret a l’emploi, qui inclue le moteur. Celui-ci sera extrait sous forme de librairie un peu plus tard.

  • Présentation de Textwheel Le 28 septembre 2010 à 14:30 , par noé de naama

    Je note une idée je ne suis pas sûr qu’elle soit bonne.

    En lisant l’article l’idée qui m’est venue serait de permettre à spip de de charger un dépot de dev par exemple en php et d’avoir un "traducteur" par exemple en javascript.

    L’objectif étant de pouvoir travailler dans un langage de programation qui ne soit pas necessairemment le langage utilisé par le serveur. par exemple node.js

  • Présentation de Textwheel Le 8 octobre 2010 à 23:35 , par noé de naama

    A nouveau je ne suis pas sur que ce que je vais proposer soit une excelente idée.

    Personnelement ce qui me déplait dans les différentes syntaxe de SPIP c’est le manque d’homogénéité formelle.

    Dans les textes :
    - une syntaxe en accollade dérivée de Latex pour les titres
    - une syntaxe "wiki" avec des raccourcis adhoc et specifique pour chaque cas
    - une syntaxe pour les modeles
    - une syntaxe pour les plugin jeu pour la serilaisation de données.

    Une syntaxe encore différente pour les squelettes

    Un langage de programmation pour historique (PHP)

    Indépendamment de SPIP un langage de programation client (javascript), un langage de style (css) du balisage (xml)

    En entrée cela demande donc un apprentissage certain.

    La proposition que je fais serait d’unifier tout cela dans un langage commun. La proposition précise que je fais serait d’utiliser la syntaxe du langage de programmation curl (ne pas confondre avec cURL)
    http://en.wikipedia.org/wiki/Curl_%28programming_language%29

    Ou un autre langage présentant de l’homoiconicité http://en.wikipedia.org/wiki/Homoiconicity

    Mais je suppose que cela à déjà été disuté entre devs.

    • Présentation de Textwheel Le 8 octobre 2010 à 23:40 , par Fil

      Ce que tu proposes est alléchant, mais ce n’est pas la problématique de textwheel. Ici il s’agit de refaire l’existant, en plus rapide, et de manière plus "logique", mais pas de changer les raccourcis. En revanche avec ce moteur il pourrait devenir plus facile de proposer une meilleure portabilité des données, puisqu’on peut remplacer une syntaxe par une autre.

  • Présentation de Textwheel Le 10 octobre 2010 à 01:40 , par noé de naama

    Je ne proposais pas de "changer de raccourcis". Les raccourcis de SPIP ont leur raisons d’être comme ceux d’autres systeme de "rendu wiki". Le premier qui vient à l’esprit c’est de pouvoir ctrl+c ctl+v du texte en provenance d’un email avec des "*" "_" entourant du texte.

    Mais je pensais que par exemple on pouvais commencer par faire du SPIP vers curl (en entré de base de donnée), du curl vers SPIP (en sortie rédacteur) et du curl vers html (en rendu courant). De la même façon que l’on pourait décider de faire du SPIP vers YAML et YAML vers SPIP. Le choix du langage pivot n’a aucune importance pour le rédacteur qui ne voit pas ce qu’il y a en base de donnée. Il faudrait voir si certain formats présentent plus de risque en terme de sécurité que d’autres.

    Cela permetrait à terme de virer l’insertion de xml direct. Qui crée l’obligation de verifier la validité du balisage en entrée. Et comme SPIP utilise lui même des raccourcis qui ressemblent à du xml (modèles) ou surcharge du balisage d’un effet de parseur (insertion de code Latex), oblige à un traitement au cas par cas.

    Comme dit plus haut le parseur de SPIP devra toujours etre utilisé en partie quoi qu’il arrive.

    • typographie (fr,en, etc.) automatique
    • raccourcis de rendus wiki mainstream (les raccourcis de listes sont vraiement bien
    • La possibilité d’utiliser alternativement des raccourcis de mise en gras et d’italique de SPIP ou des equivalent en "*" "_" voire plus haut pourquoi (mais ils n’existe pas de consensus) http://en.wikipedia.org/wiki/Lightweight_markup_language. Personnelement je serais plutot Textile que Markdown pour ne pas avoir à faire apprendre à compter les rédacteurs. Pour la même raison les raccourcis "curly" de SPIP sont problemetique car il arrive toujours à un moment ou un autre ou un degres suffisant de fatigue soit atteint pour qu’un gras devienne un intertitre soit (ce qu’un relecteur peut eventuellement detecter) mais quand un gras est confondu avec l’italique cela peut troubler le parser perso d’un secretaire de rédaction.
    • le separateur de ligne et le tilde pour l’espace insécable.
      « 
      En revanche avec ce moteur il pourrait devenir plus facile de proposer une meilleure portabilité des données, puisqu’on peut remplacer une syntaxe par une autre. »

    Il me semble que c’est ce que je propose, à moins que je n’ai pas compris à quel niveau ce situe la "portabilité des données". Pour moi c’est ce qui est dans la base de donnée.

    Pour le "changement de raccourcis" non plutot permettre à un rédacteur de choisir ce qui lui correspond à son habitude ou à ces besoins pour "un jour". Je ne veux rien remplacer ou "revolutionner" les raccourcis SPIP on leur raisons d’etre (certain en ajoute comme Pyrat) et ci cela ne tenait qu’à moi je proposerai un parser minimal (on peut discuter de ce qui convient au minimal) avec :

    • paragraphage
    • correction typo
    • intertitre
    • liste à un niveau
    • tilde pour l’espace insécable.

    Le reste en plugin ou en couteau suisse.

    Pour un autre plugin sans doute offrir la possibilité de "piper" des parsers, éventuellement détecter des "cas" à renvoyer pour une corection humaine"
    Pouvoir faire des détection dans le texte et brancher en Y sur un autre parser.

    Mes deux cents

  • Présentation de Textwheel Le 30 octobre 2010 à 17:59 , par noé de naama

    En réponse à Fil et pour terminer de "poluer" ce forum.

    Début de doc du projet pour préciser le projet avant de se lancer :
    http://www.spip-contrib.net/free-hugs

  • Présentation de Textwheel Le 8 décembre 2010 à 20:08 , par noé

    Je signale je ne sais pas si cela peut interesser :

    http://www.framasoft.net/article4576.html

  • Présentation de Textwheel Le 15 janvier 2011 à 20:55 , par corrobori

    Je signale aussi , pour faire avancer le schmilblick

    http://www.pouleouoeuf.org/p-21.tic.

    On écrit une fois et on fait du epub, latex, html, text …

  • Présentation de Textwheel Le 25 janvier 2011 à 18:41 , par noé de naama

    Comme je code comme deux pieds j’ai du mal à comprendre comment fonctionne textwhell.

    Mais suite à l’idée de formaliser un langage de programation qui se disseminerai du langage de balise au typoscript je signale ces liens offert par un davduf en pleine forme.

    http://www.choiceofgames.com/blog/choicescript-intro/
    http://istoryweb.appspot.com/myStories

    Je donne ici un avis mais qui mélange peut être un peu tout.
    Ce serait bien un langage de script à la choicescript qui integrerai les besoins en fonctionalité du plugin jeu, permettrai des choix conditionnels, et ferai une conversion du texte pour le plugin forms & tables (definition des formulaires en mode script), integrerai les données dans les tables de forms & tables et créerai une serie d’articles en batch avec du texte et un formulaire. Et conserverai quelque par le script (c’est a dire alleurs que dans une table article amha).

  • Faire un autre plugin SPIP pour rajouter d’autres raccourcis Le 13 avril 2011 à 16:41 , par RealET

    Bonjour,

    Je sèche devant comment faire un plugin SPIP qui rajouterait d’autres raccourcis typo.

    Est-ce qu’il y aurait un exemple quelque part bon à hacker ?

  • Présentation de Textwheel Le 14 août 2012 à 09:15 , par farvardin

    alors ? Ça en est où de ce projet alléchant ?