Encore un autre Framework PHP

J’analyse l’API de Ruby on Rails en ce moment. Je cherche à comprendre comment il fonctionne, et pourquoi tel ou tel choix a été fait par les développeurs. J’essaye aussi de déterminer où il est particulièrement lié à Ruby, et ce qu’il n’est pas possible de transposer directement à un autre langage.

Je commence à mieux saisir Rails et son API. Le concept de module m’a dérouté un moment, surtout dans la lecture de l’API Rails. Venant d’un monde où cette notion n’existe pas et où les classes ne se mélangent que par héritage, pouvoir inclure des fonctions dans plein de classes, sans notion d’héritage ou de devoir instancier des objets dans l’objet… c’est déroutant. Pourtant c’est génial : cela distingue encore mieux les logiques et permet de partager beaucoup plus facilement du code.

Pendant le même temps je travaille sur un framework taillé pour PHP 5.2 (en attendant la version 5.3).

Mais pourquoi réinventer la roue ? Franchement, je me suis posé la question depuis Noël dernier ; et puis j’ai lu un article sur le blog de Jeff Atwood : Don’t Reinvent The Wheel, Unless You Plan on Learning More About Wheels. Cela m’a rappelé les raisons premières à l’écriture de mon propre framework : la facilité d’utilisation de CakePHP, mon envie de plonger un peu dans le code, pour comprendre certains aspects… et ma réticence face à sa complexité interne : je ne pigeais pas pourquoi tout y était si complexe et pourquoi continuer à supporter PHP 4.

Sur un coup de tête je me suis lancé dans un brouillon. En une nuit j’avais un truc qui tournait correctement. J’ai beaucoup apprécié cette expérience : j’avais quelque chose de plus simple, léger et rapide (à mes yeux) et j’y ai beaucoup appris ; alors j’ai continué. Voilà pourquoi je réinvente encore la roue : pour apprendre, pour fournir encore un autre framework à la communauté, et pour moi pouvoir utiliser un framework que je maîtrise sur mes projets.

Aujourd’hui je m’y relance : un framework full objet en PHP. La version de développement (alpha) est d’ailleurs disponible. Le code y est relativement stable, le développement étant test-driven, et l’API reprend grosso-modo l’API publique de Rails, minus les appels statiques (eg: Product::find()), qui devront attendre PHP 5.3 et son Late Static Binding pour être faisable.

Si cela vous intéresse, il s’appelle misago, et il est disponible sur github : http://github.com/ysbaddaden/misago/.

À propos des Frameworks

Je pratique les frameworks depuis quelques années, car je trouve les principes type Domain, MVC, etc. extrèmement pratiques. Je n’arrive cependant pas à en trouver un qui me plaise. Je fais régulièrement le tour des frameworks PHP principaux, mais je trouve généralement qu’ils sont beaucoup trop compliqués, et qu’ils ne résolvent pas mes problèmes. Le principal étant de me simplifier au maximum la vie sur les tâches répétitives et d’être opérant immédiatement, sans avoir à coder 5 classes juste pour un modèle.

Je n’ai par exemple toujours pas compris comment créer un modèle avec le Zend Framework. À part qu’il faut apparemment générer 3 classes, juste pour un modèle.

J’ai donc fini par me coder un framework perso, que j’ai réécrit deux fois. Mais :

  • il n’y a aucun test unitaire ;
  • je suis le seul à bosser dessus ;
  • je n’ai donc aucun retours d’utilisateurs ou d’autres programmeurs ;
  • la plupart des idées de la dernière version viennent directement de Rails.

Pourquoi m’embêter à coder en PHP ce qui existe déjà pour Ruby ? En plus, Rails est plein d’idées que je trouve excellentes, qui me plaisent et que je copie sans vergogne. Quel intérêt alors de maintenir un tel framework ? Ça me semble idiot, surtout depuis que j’ai lu Practices of an Agile Developer.

Certes, développer un bon framework, simple, accessible et reprenant les bonnées idées de Rails mais basé sur PHP et non pas Ruby est intéressant. PHP est plus courant chez les hébergeurs par exemple, donc plus facile à déployer. Cependant coder tout seul dans son coin, et voir ses projets (Webcomics.fr par ex.) traîner du pied parce qu’il faut maintenir et faire évoluer son framework… c’est juste idiot.

Je ne rejette pas l’idée de coder un framework PHP5 tel que définit au paragraphe précédent, mais pas tout seul, et surtout : développé Test Driven, c’est-à-dire que les tests doivent conduire la programmation (et pas l’inverse). Si ça vous êtes intéresse et que vous maîtrisez le modèle objet PHP5, contactez-moi, car ça m’intéresse !

Pour le moment j’étudie Ruby, Rails, et j’apprends des trucs. Je ne sais pas ce qu’il en ressortira : un framework calqué sur Rails mais pour PHP5 ? Ou peut-être finirai-je par switcher et passer à Ruby ?

Créez un site Web ou un blog gratuitement sur WordPress.com.

Retour en haut ↑