Ca fait un petit bout de temps déjà que je voulais me mettre à symfony. Voici mes impressions.

Installation

En fait, ce n’est pas la première fois que je teste symfony. J’avais déjà téléchargé le projet de démonstration. Mais j’étais pressé, je n’avais pas lu la doc et j’ai tout cassé.

Cette fois, je lis l’énorme doc de 19 grosses pages qui est dans les sources. Et c’est tout de suite plus facile, parce que ça explique comment sont rangés les dossiers et les fichiers (avant j’essayais de deviner).

Une fois qu’on a les définitions des project, application, module et action, ça va beaucoup mieux.

Je n’ai pas utilisé le projet de démonstration cette fois. J’ai simplement suivi la doc et créé un projet depuis zéro. Et ça marche très bien.

Structure et configuration

La chose qui m’a frappé au début, c’est les dossiers. Il y a les mêmes arborescences un peu partout. La raison est simple: symfony se base sur une configuration en cascade. On applique une configuration générale et on peut la modifier localement pour un morceau du projet. On n’est pas obligé, mais c’est possible.

Les helpers et les filtres

Je vous épargne les détails de mon avancée dans la création du projet, je ne veux pas faire de billet, un didacticiel.

Je connaissais les Helpers, dans d’autres framework, ce sont des fonctions utiles qui servent à l’affichage, comme par exemple pour créer rapidement un <select>. Il y en a dans symfony, mais je suis tombé sur les filtres en essayant de comprendre comment des CSS peuvent être insérées ma page alors que je ne l’ai dit nulle part dans mon layout.

Un filtre peut modifier ce que va envoyer symfony à l’utilisateur. C’est comme ça que par défaut, les javascripts et CSS sont insérés en faisant un simple rechercher/remplacer sur </head>. symfony applique le pattern décorateur pour les filtres.

On peut utiliser un filtre pour ajouter le code de google analytic par exemple, sans toucher au layout du site.

Partial, component et slot

C’est à ce moment que j’ai dit woua.

Je n’ai pas encore vu de framework (faut dire que j’en ai pas vu beaucoup) qui allait aussi loin sur les différentes façon de factoriser un affichage. Je vous cite la doc en français:

Si la logique est limitée, vous inclurez simplement un gabarit qui accèdera aux paramètres que vous lui passerez. Vous utiliserez un partial.

Si la logique est plus lourde (vous avez par exemple besoin d’accèder au modèle de données et/ou de modifier le contenu selon la session), séparer la présentation de la logique sera préférable. Vous utiliserez dans ce cas un component.

Si l’objectif du gabarit est de remplacer une partie spécifique de la page, pour laquelle il peut exister un contenu par défaut, vous utiliserez un slot.

Et encore, je ne parle pas des component slot ! Une sorte de combo digne d’un street fighter :)

Conclusion

Il faut lire la documentation, c’est long et verbeux, mais ça aide.

Il y a tout un tas de mécanismes, de fallback, de cascades, de décorations, de cache etc. C’est marqué que les developpeurs débutant peuvent faire du symfony. Je trouve ça assez avancé quand même. Dès le départ on nous parle de MVC et qu’il faut lancer des commandes pour créer son projet … gné ? Le gars qui joue avec son dreamweaver doit être un peu perdu.

Même en fournissant un projet tout configuré. Le problème arrive dès qu’il faut faire des modifs, et là il faut de tout façon lire la doc pour savoir où il faut modifier, sous réserve de la comprendre. On n’entre pas dans l’orienté objet si facilement.

Mais bon, j’appécie pleinement le framework. C’est un beau travail. Et je commence un projet bidon pour mettre en pratique, parce qu’il n’y a rien de mieux que la pratique ! :)

Vous en saurez plus si je trouve quelque chose d’intéressant pendant la construction du projet.