Categorie code > Les frameworks php c'est bien, ou comment j'en suis venu a creer le mkframework

Les frameworks php c'est bien, ou comment j'en suis venu a creer le mkframework

2012-06-06

Grâce à l'arrivée de Ruby on Rails on a vu arriver un bon nombre de frameworks php tous plus prometteurs les uns que les autres.

Le contexte

Il y a 5-6 ans, dans ma société de l'époque, mon chef de projet souhaitait que l'on choisisse un framework php.

A l'époque il y avait beaucoup de projets interne php, chacun était développé par des développeurs différents. Utiliser un framework c'était le gage de pouvoir plus facilement maintenir les nouvelles applications peu importe par qui elles étaient développées.

Au début des frameworks php , il nous avait fallu choisir entre Jelix, Symfony Zend Framework et Prado, Symfony avait été retenu pour plusieurs raisons

  • framework et documentation française
  • un ORM, un MVC, gestion de langue avec i18n...
  • bien documenté

C'était les débuts de symfony, leur idée de base était de regrouper/d'assembler de bon projets pour chaque brique du framework : propel pour l'ORM, mojavi pour le MVC...

Découvrant les frameworks par symfony, et une fois l'apprentissage entamé, je fut vite séduit par le principe, à l'époque j'avais écrit un article dessus (article sur mac4ever.com)

Mais à l'usage je fut decu des performance de l'ORM (propel) : bien que pratique et rapide pour coder la partie modèle, on souffrait de la lourdeur de sa structure à l'utilisation, une autre chose aussi qui avait tendance à m'embeter était la verbosité de l'ensemble: pour récupérer une simple valeur get il fallait invoquer une methode pour recuperer un objet pour récupérer la dite valeur...

Les prémices d'un framework

A cette époque je me suis dit que ce serait sympa/intéressant de créer mon propre framework en essayant d'éviter les "erreurs" de symfony: un framework simple, sans ligne de commande, avec un niveau de verbosité faible

Plus facile à dire qu'a faire: il m'aura fallu m'y reprendre à quatre fois: chaque fois je partait de zéro: des schémas sur feuille de papier avec en tête les erreurs à ne pas commettre (celles des précédentes versions ajouté à celles de symfony). Je restai dans l'idée de symfony en essayant de m'en différencier: j'avais un orm puissant mais qui comme propel devenait de plus en plus lourd à l'usage: on pouvait facilement faire des jointures d'objets en s'appuyant sur des configurations de liaisons externe...

La v4 : on pose les crayons et on se recentre sur l'essentiel

Sur cette version, je me suis posé les questions suivantes avant de plancher sur le projet:

  • Qu'est-ce qui est vraiment nécessaire au framework
  • Comment avoir un ORM à la fois léger et pratique
  • Comment implémenter à la fois une gestion simple et puissante du cache et de l'authentification

Et à partir de la les bases de la version actuelle été posées

  • Ce sera un framework léger
  • Facile à apprendre, à comprendre
  • Un builder permettra de générer une application de départ contenant des exemples (afin de faciliter sa prise en main)
  • Il devra être paramétrable au possible et ceci facilement (fichiers ini dans un répertoire conf)
  • Sa couche modèle devra être flexible et efficace

Depuis un site a été créé mkdevs.com et j'ai la chance d'être hébergé sur le site de developpez.com avec comme bonus un svn public facilitant l'installation et la mise à jour du framework pour ses utilisateurs

Un framework articulé autour d'une racine commune

Inspiré de l'action script (langage du flash) j'ai nommé la classe principale "_root", sorte de colonne vertébrale du framework, elle se comporte comme un chef d'orchestre du framework:

  • Elle lit les fichiers de configuration et initialise les variables d'environnement du site
  • Elle charge et nettoie les variables GET/POST, accessible par un simple _root::getParam()
  • Elle parse l'url pour instancier le bon module et appeler la méthode demandée

Une gestion des vues / layout orienté objet

Ici on manipule des objets vues, caches et layout:

  • Dans la méthode appelée en amont "_before" de chaque module, on créé un objet layout en indiquant l'adresse du fichier layout présent dans site/layout/
  • Dans la méthode de l'action de la page demandée "_list" (par exple) on créé un objet template en précisant l'adresse du template, on y assigne les variables que l'on souhaite
  • On ajoute l'objet template à l'objet layout
  • Dans la méthode appelée en aval "_after", on affiche ce layout

L'objet template est un objet visible et facilement manipulable (contrairement à d'autres frameworks on il est induit) , on peut se le "passer" entre méthodes du module, par exemple on peut avoir une methode qui construit et enrichit le template puis le retourne.

Ainsi deux actions différentes peuvent récupérer ce template puis l'afficher dans deux layout différent l'un optimisé mobile et l'autre optimisé site web par exemple.

Une gestion de cache également objet

On choisit de manière globale une politique de cache.

Puis, on gère manuellement son cache, on choisit d'assigner son cache comme on le veut, de le recuperer...

Un builder, ou générateur de code web, ou comment simplifier la vie du développeur

A force d'utiliser la ligne de commande avec symfony, je m'étais dit que ce serait sympa d'avoir une interface pour simplifier tout ça.

Quand j'ai commencé cette aventure, je me suis attelé à cette tache pour simplifier un max l'adoption de ce framework ;)

En 2 clic on créé une nouvelle application, une fois le paramétrage de connexion à la base de donnée fait, on peut facilement générer sa couche modèle puis le CRUD* pour gagner du temps

C'est bien sympa de ne pas partir de zéro, on a le choix de générer une application vierge ou avec des exemples, ce qui facilite grandement la compréhension et l'apprentissage.

*CRUD: Create Read Update Delete, page de listage, visualisation et d'édition.

Bref, j'ai créé un framework php

Voila comment j'en suis venu a créé ce framework il y a quelques années, je continue à le maintenir, le sécuriser (csrf,xss,nullbyte...) il évolue avec son temps avec un soucis d'éviter la non régression (comme sur d'autre framework que j'utilise...)

Maintenant il me reste plus qu'a écrire des articles pour le faire adopter, avoir des retours constructifs pour le faire évoluer, bref : créer une réel communauté :)

Commentaires

comments powered by Disqus