Silex, un micro framework PHP

Cela fait en effet un moment que j’ai envie de réécrire ma page KeiruaProd, afin qu’elle soit conçue à partir d’une base de code bien propre. Il n’y a que quelques pages statiques à l’heure actuelle, mais j’ai 2-3 idées d’évolutions dans les cartons, ce qui est une bonne occasion de repartir sur une base saine sur tous les plans (back et front).

Mes besoins sont simples :
– du code propre, léger, maintenable, respectueux des standards
– séparation front/back
– apprendre, tester des outils
– évolutivité

Ma recherche d’outils adaptés s’est arrêtée sur 2 outils : Silex pour le PHP, et HTML5 Boilerplate pour le code front.

Ca va être l’occasion de vous en parler !

Je vous laisse regarder HTML5 Boilerplate si vous ne connaissez pas, mais comme ils le disent eux même « HTML5 Boilerplate est un template HTML/CSS/JS de tueurs pour développer des sites rapides, robustes et éprouvés pour le futur. » Il contient simplement une structure de code propre par dessus laquelle écrire du code multi-navigateurs devient plus simple. Aujourd’hui, je vais principalement parler du back.

Concernant le back, pourquoi un framework, même minimal ? A vrai dire, à l’heure actuelle, j’ai au mieux besoin (et encore) d’un moteur de templating pour être heureux. Mais je vais avoir besoin de coder 2-3 trucs, pour lesquels avoir un code un peu structuré et surtout testable est une bonne chose. A l’heure actuelle, c’est trop fouilli (les cordonniers sont les plus mal chaussés) pour que je puisse avancer sereinement. L’argument « pour apprendre » est par contre dangereux, faites attention à ce que vous mettez en production 🙂

Maintenant, pourquoi celui là ? Ses fonctionnalités sont très intéressantes : templating, validation, formulaire, cache, securité, logging, traduction, ORM… Bref de quoi saliver, surtout quand on sait que le code est largement testé, d’où une confiance accrue.

Voyons voir comment on s’en sert !

Installation

L’installation de Silex est triviale, il suffit de remplir un fichier composer.json avec ce qui suit :
<br /> {<br /> "minimum-stability": "dev",<br /> "require": {<br /> "silex/silex": "1.0.*",<br /> "twig/twig": ">=1.8,<2.0-dev", "symfony/twig-bridge": "2.1.*", "monolog/monolog": ">=1.0.0"<br /> }<br /> }<br />
On exécute composer via
<br /> php composer.phar install<br />
Et quelques secondes plus tard, c’est parti, on a un répertoire vendor avec tout ce dont on a besoin.

J’ai inclus Twig (templating) et Monolog (logging) dans cet exemple, mais vous pouvez vous en passer.

Par la suite, lorsqu’on ajoutera une extension, il suffira de lancer
<br /> php composer.phar update<br />
pour la récupérer.

Architecture

Niveau architecture, j’ai fait une architecture très proche de ce qui se fait chez Symfony, avec 3 répertoires à la racine : web, src, et app.

<br /> web/<br /> index.php<br /> app/<br /> bootstrap.php<br /> src/<br /> app.php<br />

Le répertoire web, c’est celui qui est exposé. Un fichier .htaccess va rediriger toutes les requêtes vers le fichier index.php, qui fait office de contrôleur de facade. C’est lui qui va rediriger les requêtes vers le bon contrôleur. Le fichier inclut bootstrap.php (qui référence a configuration de l’application) et app.php (qui référence les contrôleurs).

Voici le contenu de notre index.php :
<br /> <?php // On charge les librairies require_once __DIR__.'/../vendor/autoload.php';

// On crée l’application $app = require DIR.’/../app/bootstrap.php’; // On charge les contrôleurs require DIR.’/../src/app.php’;

$app->run();<br /> </code>

Pas bien lourd, hein ? C’est pourtant ces 4 lignes qui vont faire tourner notre application.

Par la suite, le répertoire app/ contiendra par exemple les logs et les fichiers de mise en cache, là où le répertoire src contiendra le code métier (php et template).

Configuration

Maintenant, la configuration de notre application, dans app/bootstrap.php :
<br /> <?php use Silex\Provider\MonologServiceProvider, Silex\Provider\TwigServiceProvider;

$app = new Silex\Application();

$app->register(new MonologServiceProvider(), array(<br /> ‘monolog.logfile’ => DIR.’/log/app.log’,<br /> ‘monolog.name’ => ‘kp_app’,<br /> ‘monolog.level’ => 300 // = Logger::WARNING<br /> ));</p> <p>$app->register(new TwigServiceProvider(), array(<br /> ‘twig.path’ => array(DIR . ‘/../src/views’)<br /> ));</p> <p>return $app;<br /> </code>

On crée une application Silex, on enregistre les fonctionnalités dont on a besoin, et les configure. Ici, les noms d’options parlent d’eux même, mais vous pouvez trouver plus d’informations sur les services disponibles et leurs options de configuration dans la documentation.

Code métier

Maintenant, il ne nous reste plus qu’à créer des contrôleurs :
<br /> // dans src/app.php<br /> <?php use Symfony\Component\HttpFoundation\Response;

$app->match(‘/’, function() use ($app) {<br /> return new Response (‘Yeah !’);<br /> })->bind(‘kp_homepage’);</p> <p>$app->match(‘/hello/{name}’, function($name) use ($app) {<br /> return $app[‘twig’]->render (‘hello.html.twig’, array(‘name’ => $name));<br /> })->bind(‘kp_hello’);<br /> </code>

On crée 2 contrôleurs, l’un pour la route /, l’autre pour /hello/clement par exemple. L’une génère une réponse directement, l’autre passe par un modèle twig très simple :
<br />

src/views/hello.html.twig<br />

Hello <br /> </code>

Il y a plein de manières de structurer ses contrôleurs : un fichier par contrôleur, une classe dédiée avec autoloading… Vu la taille de cet exemple, j’ai créé mes 2 routes dans un seul fichier.

Et voila, on est prêt à avancer. On peut d’ores et déjà se rendre sur les 2 routes qui ont été créées pour voir que tout marche comme il faut. Reste plus qu’à ajouter des routes, écrire des vues… à coder l’application quoi !

Si ça vous a plu et que vous voulez continuer avec Silex, après avoir regardé un peu la documentation, jetez un oeil à Silex Kitchen Edition. C’est une version prête à l’emploi du framework qui va vous permettre d’écrire directement vos fonctionnalités dans un environnement déjà bien configuré.