CMS ou Framework? Le choix de Typolight
La question est vieille, même si les développeurs refusent de se la poser clairement. Autant le dire tout de suite, j’ai moi aussi été un développeur qui ne voulait pas entendre parler de CMS. Les CMS, c’est bons pour les intégrateurs qui n’ont pas de dév, ça ne permet que de répondre aux besoins les plus courants en rendant toute extension pénible et tortueuse, c’est souvent mal écrit, tout ça.
Premier contact avec Typolight
Lorsque j’ai commencé mes activités de freelance, j’ai rencontré Telly Delalande, avec lequel je travaille régulièrement aujourd’hui. Telly est passionné par un CMS qui s’appelle Typolight, et dont il m’a assuré que c’était le meilleur CMS du monde. Son article a provoqué de telles réactions que j’ai décidé de lancer un troll moi aussi :)
Plus sérieusement, quand Telly m’a parlé de Typolight, j’ai accepté d’y jeter un oeil sans trop y croire. Premier constat : la documentation pour développeur est franchement lacunaire. Ok, qu’à cela ne tienne, “use the source, Luke”. J’ouvre le code pour essayer de comprendre comment tout cela fonctionne. Et là survient la première surprise : c’est bien codé, très bien codé, même. Il y a bien quelques vieilleries PHP-iennes, comme l’absence d’une vraie classe modèle ( la classe Model est un singleton destiné à mapper l’user courant ) et donc la profusion de requêtes sql dans les contrôleurs, mais le tout est propre est agréable à lire (sauf quelques fichiers plus anciens que les autres).
Je décide donc de faire un essai, et de mettre l’extensibilité à l’épreuve.
Les modules
L’extension de Typolight se fait comme dans beaucoup de CMS par l’ajout de modules. C’est donc assez banal, mais ça m’a plu sur le coup comme je venais juste d’essayer Merb dont le concept de modulabilité m’avait beaucoup intéressé ( oui, ca se fait très bien par l’intermédiaire des plugins dans Rails ou Symfony, mais permettre quelque chose et encourager son utilisation dans le design même d’une application sont deux choses aux résultats totalement différents ).
Les modules de Typolight sont donc des répertoires, placés dans system/modules/, et dans lesquels on peut mettre tous les fichiers nécessaires à une fonctionalité : modèles, contrôleurs, vues, css, js, fichier de migration db, fichier de configuration, etc.
Tout de suite, les limitations apparaissent. Un contrôleur dans un module ne gère qu’une seule action. Cependant, l’application étant entièrement orientée objet et pensée pour la surcharge, il m’a été facile de rajouter un classe de contrôleur permettant de gérer plusieurs actions. Tout comme il m’a été possible de rajouter une gestion de routes complètement arbitraire. Tout comme il m’a été possible de rajouter un classe que j’ai nommée EModel, et qui reprend les fonctionnalités classiques d’un modèle dans les frameworks : associations, validations, recherches selon paramètres, etc. Les bases étaient posées.
Utiliser Typolight comme un framework
Au fur et à mesure que mes besoins se précisaient, je rajoutais des fonctionnalités dans mon module “framework” qui me permettait de développer d’autres modules sans sentir de contraites CMS-iennes. Chaque fois, j’étais surpris d’avec quelle facilité c’était faisable. Bien sûr, il faut parcourir le code et le connaître un minimum dans son ensemble pour se permettre des modifications aussi conséquentes, mais c’est chaque fois la même surprise : c’est possible, et proprement en plus.
Aujourd’hui, j’utilise Typolight d’une manière très similaire à mon utilisation de Ruby on Rails. J’ai intégré cucumber et phpspec par l’intermédiaire d’un module “testing“, je fais donc du bdd, à base de user stories suivant lesquelles je déroule mes vues, contrôleurs, modèles et routes dans un soucis de réutilisabilité.
Je me retrouve donc dans la situation où l’argument de manque d’extensibilité est brisé.
Focus!
Dans le même mouvement, je me retrouve avec une pluvalue d’avantages qui relève de tous les inconvénients du framework quand on le compare au CMS : pas de perte de temps à coder des fonctionnalités banales que je ferai de toutes façons moins complètes que celles présentes dans un CMS, développées depuis des années.
C’est là qu’apparaît le point vraiment intéressant : le fait de pouvoir se permettre de se focaliser entièrement et uniquement sur les fonctionnalités spécifiques dont a besoin le client. Cela rend le développement rapide, beaucoup plus rapide. Recoupé avec la possibilité de faire du bdd, cela permet de produire des applications complètes, stables et peu coûteuses.
CMS ou framework? Les deux mon capitaine.
Cela m’amène à me poser la question : en quoi les CMS et les frameworks sont incompatibles? Les développeurs condamnent régulièrement les CMS pour leur manque d’extensibilité, mais il ne s’agit pas là d’une fatalité. C’est simplement un fait courant. Pour ma part, je dirais que le problème est surtout que beaucoup de CMS ont une base largement impérative, avec des require partout, l’OO n’apparaissant que dans la couche intermédiaire de l’application.
Un CMS pensé proprement (la notion de propreté voulant surtout dénoter la conformité aux bonnes pratiques du jour) peut très bien être extensible et peut même être pensé comme un framework.
Je n’irai pas dire que Typolight est ce CMS de rêve, mais il s’en rapproche incroyablement plus que les CMS dont nous avons l’habitude. Il rend en tous cas concrètement possible la fusion entre CMS et framework.
Peut-être est-ce à nous, développeurs, de proposer aujourd’hui des solutions CMS/Framework qui garantissent à la fois la possibilité d’être utilisées par des non-développeurs, de mettre en place en quelques minutes les fonctionnalités courantes, et d’offrir une extensibilité complète.
19 août, 2009 à 17:29
J’attends avec impatience de la documentation ou une petite application d’exemple utilisant ton framework :D, car je ne suis pas un Jedi du code ;) en tout cas, ton projet m’intéresse énormément. Merci de l’intérêt que tu portes à TYPOlight
19 août, 2009 à 17:41
Merci Cyril :)
Je suis en train de finir deux contrats où je l’ai utilisé, dont un qui sera visible (l’autre relevant d’un accès payant à un webservice). Dès que c’est fini, promis j’écris la doc et je reprend les tutos :)
Évidemment, c’est sûr qu’une démonstration serait plus efficace si on pouvait voir le code… J’avais commencé à faire un moteur de blog pour remplacer mon wordpress, j’espère pouvoir le terminer avant de reprendre le prochain contrat :s
Tiens au fait, on discutait pas plus tard qu’aujourd’hui avec Olivier (Beining) de faire un canal irc #typolight-fr, qu’est-ce que tu en penserais?
20 août, 2009 à 15:36
Kmel, un utilisateur du forum a déjà créé un canal IRC : http://www.typolight.fr/forums/viewtopic.php?id=295
23 août, 2009 à 14:55
Ah ok, ça marche. J’avais regardé sur freenode, je vais aller jeter un oeil, merci.