Je suis développeur web freelance et propose des formations à Symfony2 ! Contactez-moi pour en discuter.

Cet article fait partie d’une série d’articles d’introduction à Backbone.js, largement inspirée du tutoriel (en anglais) Hello Backbone.js. Les bouts de code du tutoriel original ont été légèrement refactorés.

Backbone.js est une librairie très intéressante, mais un peu difficile à prendre en main. Des questions récurrentes sur le sujet amené à écrire cette petite série d’articles. Mon but, c’est de vous présenter cette librairie de manière plus simple que l’exemple « officiel » Backbone todos.js, qui est, disons, un peu raide.

Dans cette série donc, on va y aller de manière progressive, comme l’on pourrait procéder lors de la conception d’une application. Je ne toucherais pas au CSS et mettrais un minimum d’HTML, afin de nous concentrer sur Backbone. On va partir de quelque chose de très simple, et le faire évoluer, toujours de manière simple, vers une petite application, en essayant surtout de mettre en place des bonnes pratiques.

Lire la suite »

La console Symfony2. J’ai écrit un article sur comment écrire ses propres commandes, mais rien sur comment bien se servir de celles qui existent déjà ! Le but de cet article est donc remédier à cela, en faisant un tour d’horizon des commandes disponibles de base, et de ce qu’elles permettent de faire.

Commencez par lancer une terminal, et placez-vous à la racine d’un projet Symfony2.


php app/console

S’il y a une chose à retenir de cet article, c’est cette commande. Elle liste toutes les commandes consoles disponibles, ce qui permet de ne pas avoir à retenir la syntaxe de toutes celles dont je vais vous parler par la suite. Si vous retenez cette commande et que vous savez ce qu’il est possible de faire, vous pouvez ensuite retrouver la commande correspondante dans la liste.
Lire la suite »

J’ai récemment reçu un mail me demandant si je savais comment résoudre un problème assez intéressant: afficher un formulaire de contact sur toute les pages dans le footer, mais sans le code associé au formulaire dans tous les contrôleurs.

Dans le cas d’un formulaire où il y a une logique de traitement derrière pour utiliser les données et non pas seulement les afficher, le problème en contient en fait 2 :

  • Comment afficher dans une vue des éléments qui doivent être générés par un contrôleur mais qui sont toujours les mêmes, sans devoir les passer en argument de chaque méthode du contrôleur ?
  • Comment traiter un formulaire comme il se doit alors que le code du contrôleur principal de la page ne contient pas de code de gestion du formulaire en question ?

La solution ? Une bonne partie de la réponse se trouve dans la fonction render de Twig. Cette fonction nous permet d’exécuter le code d’un contrôleur directement depuis la vue. Dans notre cas, nous allons créer une méthode de contrôleur qui se charge de créer un formulaire de contact, et l’appeler depuis la vue.
Lire la suite »

Cet article est la traduction d’un article original de Fabien Potencier, à l’origine de Symfony2, disponible ici.

Si vous deviez utiliser notre framework dès maintenant, vous voudriez probablement permettre de personnaliser les pages d’erreur. Actuellement, nous gérons les erreurs 404 et les erreurs 500, mais les réponses sont codées en dur dans le framework lui-même. Les rendre personnalisables n’est pas très difficile : on déclenche un nouvel évènement, et quelqu’un l’écoute. Pour faire ça bien, il faut que l’écouteur appelle ensuite un contrôleur. Et si le contrôleur d’erreur lève une exception ? Boucle infinie. Il doit y avoir un moyen plus facile, hein ?

Pensez à la classe HttpKernel ! Au lieu de résoudre les mêmes problèmes encore et encore, et réinventer la roue à chaque fois, la classe HttpKernel est une implémentation générique, extensible et flexible de HttpKernelInterface.
Lire la suite »

Par défaut, les champs de formulaires de type « Date » de Symfony2 sont représentés par 3 listes déroulantes. C’est très pratique pour du prototypage, mais ce n’est pas forcément ce que l’on veut proposer à l’utilisateur. On peut avoir envie de plutôt utiliser un sélecteur de date de type calendrier, comme on peut le trouver sur n’importe quel site de réservation d’hôtel ou de billet d’avion par exemple.

Nous allons donc voir comment implémenter cette fonctionnalité dans Symfony2 avec jQuery UI. jQuery est une librairie JavaScript qu’on ne présente plus, jQuery UI en est une extension qui propose de nombreuses fonctionnalités pour créer des interfaces dynamiques très web 2.0.

Lire la suite »

Cet article est la traduction d’un article original de Fabien Potencier, à l’origine de Symfony2, disponible ici.

Actuellement, il manque à notre framework une caractéristique essentielle à tout bon framework : l’extensibilité. Être extensible signifie que le développeur doit pouvoir facilement s’intégrer dans le cycle de vie du framework pour modifier la manière dont les requêtes sont gérées.

De quel genre d’intégration parlons nous ? D’authentification ou de système de cache par exemple. Pour être flexible, il faut que le développeur puise s’intégrer de manière plug-and-play. Beaucoup d’applications appliquent des concepts similaires, tel que WordPress ou Drupal. Dans certains langages, il y a même des standards tel que WSGI en Python ou Rack en Ruby.
Lire la suite »

Dans cet article, je vais parler de la génération de formulaires dynamiques avec Symfony2. Le but: pouvoir créer des formulaires dans lesquels on rajoute des champs sans recharger la page, et qui sont associés à des entités que l’on peut ensuite persister dans la base de données. C’est un sujet relativement mal documenté. J’ai utilisé en partie le travail de Khepin, qui s’était essayé au même exercice il y a quelque temps.

Pour réaliser cela, nous allons devoir mixer du PHP (via Symfony2) avec du JavaScript (avec jQuery). Nous allons faire au plus simple et utiliser seulement ces 2 librairies afin de faire marcher cette fonctionnalité. C’est loin des standards de développement modernes (et très loin des miens) où le but n’est pas simplement d’avoir un code qui fonctionne, mais qui soit maintenable. Si le sujet vous intéresse, sachez que côté JavaScript, des librairies comme Backbone.js ont de plus en plus la côte pour faire du code fonctionnel et maintenable côté client. Je reviendrais sur ce thème dans un autre article sous peu.

Pour vous éviter de souffrir, le code du pseudo bundle décrit dans cet article est disponible sur GitHub, avec les informations nécessaires pour le lancer : https://github.com/Keirua/KeiruaProdCustomerDemoBundle
Lire la suite »

Cet article est la traduction d’un article original de Fabien Potencier, à l’origine de Symfony2, disponible ici.

Des lecteurs vigilants ont fait remarquer des bugs subtils mais non moins importants dans le framework que nous avons construit hier. Lorsque l’on crée un framework, il faut être certain qu’il se comporte comme annoncé. Si ce n’est pas le cas, toutes les applications basées dessus souffriront des mêmes bugs. La bonne nouvelle, c’est que quand on corrige un bug, on le corrige dans plusieurs applications à la fois.

La mission du jour est d’écrire des tests unitaire pour le framework que nous avons créé en utilisant PHPUnit. Créez un fichier de configuration de PHPUnit dans example.com/phpunit.xml.dist :

< ?xml version="1.0" encoding="UTF-8"?>




./tests


Lire la suite »

Cet article est la traduction d’un article original de Fabien Potencier, à l’origine de Symfony2, disponible ici.

Un des inconvénients actuel de notre framework réside dans le fait qu’il faut copier le code de front.php à chaque fois que l’on veut créer un nouveau site web. 40 lignes de code ça n’est pas grand chose, mais ça pourrait être sympa de pouvoir mettre ce code dans une classe dédiée. Cela nous apporterait une meilleure réutilisabilité et faciliterait les tests, pour ne citer que quelques bénéfices.

Si vous regardez de plus près le code, front.php a une entrée la Request, et une sortie, la Response. Notre classe de framework va suivre ce principe simple : la logique consiste à créer la réponse associée à une requête.

Comme les composants nécessitent PHP 5.3, créons notre propre espace de nom pour notre framework : Simplex.
Lire la suite »

Cet article est la traduction d’un article original de Fabien Potencier, à l’origine de Symfony2, disponible ici.

Vous pensez peut être que notre framework est déjà plutôt solide et vous avez probablement raison. Mais regardons quand même comment nous pouvons l’améliorer.

Actuellement, tous nos exemples utilisent du code procédural, mais souvenez vous que les contrôleurs peuvent être n’importe quel callback PHP valide. Convertissons notre contrôleur pour utiliser une classe dédiée :


class LeapYearController
{
public function indexAction($request)
{
if (is_leap_year($request->attributes->get('year'))) {
return new Response('Yep, this is a leap year!');
}

return new Response('Nope, this is not a leap year.');
}
}

Lire la suite »