DebFlux a migré de version du BilboPlanet, mais...

DebFlux est mon outil principal pour lire les différents flux RSS auxquels je souscris. Il fonctionne pas trop mal et me permet, quelque soit la machine sur laquelle je me trouve, de suivre l'actualité des sites internet qui m'intéressent. Il s'appuie sur BilboPlanet, un logiciel libre que je hack pour le sortir (un peu) de son objectif initial : gérer un planet.

Il me sert énormément mais je dois dire que cette nouvelle version me surprend, surtout d'un point de vue technique. En effet, les développeurs ont choisi de faire un peu d'objet, un peu de procédural et de coller par dessus un moteur de template un peu dépassé. Peut-être voulaient-ils se passer de la gestion du cache et la déléguer à ce moteur ? Ou bien est-ce un choix pour rendre plus simple la modification du rendu et de gérer plusieurs thèmes ? Je ne sais pas, mais je reste sur ma faim.

Mon objectif au travers de ce billet n'est pas descendre le boulot abattu puisque j'apprécie le service qu'il me rend. Cependant, il me paraît nécessaire d'élever une critique qui pourrait aider à son développement, surtout d'un point de vue communautaire.

Dans un premier temps, je regrette qu'il ne repose pas sur un framework. Il aurait été vraiment intéressant que derrière ce CMS, un outil tels que Symfony, CakePHP, Zend Framework ou CodeIgniter ait été utilisé. La raison est simple : les méthodes de développement auraient été standardisées et ce travail aurait permis une intégration plus simple dans d'autres plateformes. Demain je souhaite intégrer le moteur de gestion des flux sur une application et je devrai me coltiner la réécriture du BilboPlanet.

Le choix du moteur de template me dérange. J'ai déjà utilisé un tel outil et ma conclusion est simple : quand on doit polluer son code PHP de méthodes ou fonctions propres au moteur de template, alors il faut changer d'outil. La couche de rendu doit être dissociée de la gestion des données et coller des $core->tpl-> partout dans son code, ça craint : je ne connais pas Hyla et ça me gonfle de devoir lire sa documentation alors que je dois simplement modifier la récupération des données. Il aurait été judicieux de travailler avec des méthodes proches de celles de Symfony : on a des données générées et stockées dans des tableaux simples (array) et le moteur de rendu pourra s'appuyer sur ce qu'il veut : PHP, Twig ou n'importe quoi d'autres. Qui plus est, ça facilite grandement l'intégration du code à l'intérieur d'autres projets.

D'un point de vue sécurité, j'aurais également apprécié d'avoir un grain de sel qui se paramètre à l'installation ou dans un fichier de conf. Avec la gestion de base, on peut brute forcer sans problème puisque qu'on connaît la clé définie en dure dans l'appel de la méthode de hash.

Enfin, pourquoi éparpiller les fonctions un peu partout dans le code ? C'est quand même intéressant de retrouver ses billes quand on connaît les répertoires où elles sont déclarées. Dans le code actuel, il y a un répertoire lib/ mais des fonctions sont écrites un peu partout ailleurs, typiquement l'index de l'administration. Heureusement que ctags est performant !

C'est le genre de projet qui mérite de recevoir des contributions et en ce qui me concerne, c'est le seul qui me convient pour gérer mes flux. Mais de mon point de vue, c'est une réécriture complète à faire.

Que faire ? Est-ce que je vais passer pour un élitiste après m'avoir lu, ou un gros con qui fait chier son monde car on ne fait pas comme il aime ? Faut-il forker ou bien contribuer en faisant un gros pull request avec moultes modifications ? No idea.