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

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 »

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

L’élève attentif aura remarqué que notre framework code en dur la manière dont le « code » spécifique (celui des templates) est lancé. Pour des pages simples comme celles que nous avons créées pour le moment, pas de problèmes, mais si vous voulez ajouter plus de logique, vous serez forcés de mettre la logique dans un template lui même, ce qui n’est probablement pas une bonne idée, en particulier si vous avez toujours en tête l’idée de séparation des responsabilités.

Séparons le code de template de la logique en ajoutant une nouvelle couche : le controleur. La mission du controleur est de générer une réponse à partir des informations fournies par la requête.

Changez la partie de rendu des templates du framework de la manière suivante :


< ?php // example.com/web/front.php // ... try { $request->attributes->add($matcher->match($request->getPathInfo()));
$response = call_user_func('render_template', $request);
} catch (Routing\Exception\ResourceNotFoundException $e) {
$response = new Response('Not Found', 404);
} catch (Exception $e) {
$response = new Response('An error occurred', 500);
}

Lire la suite »

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

Avant de commencer avec le sujet d’aujourd’hui, commençons par refactorer un peu notre framework actuel pour rendre les templates encore plus lisibles :

// example.com/web/front.php

require_once __DIR__.'/../src/autoload.php';

use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;

$request = Request::createFromGlobals();

$map = array(
'/hello' => 'hello',
'/bye' => 'bye',
);

$path = $request->getPathInfo();
if (isset($map[$path])) {
ob_start();
extract($request->query->all(), EXTR_SKIP);
include sprintf(__DIR__.'/../src/pages/%s.php', $map[$path]);
$response = new Response(ob_get_clean());
} else {
$response = new Response('Not Found', 404);
}

$response->send();

Lire la suite »

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

Jusqu’à présent, notre application était très simple car il n’y a qu’une seule page. Pour la rendre plus sympa, soyons fous et ajoutons une nouvelle page pour dire au revoir :


< ?php // framework/bye.php require_once __DIR__.'/autoload.php'; use Symfony\Component\HttpFoundation\Request; use Symfony\Component\HttpFoundation\Response; $request = Request::createFromGlobals(); $response = new Response('Au revoir!'); $response->send();

Comme vous pouvez le voir, la plupart du code est exactement le même que celui que nous avons écrit pour la première page. Commençons par extraire le code commun, partagé entre toutes les pages. Le partage de code semble une bonne idée pour créer notre premier « vrai » framework !
Lire la suite »

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

Avant de plonger dans le refactoring du code, je voudrais revenir en sur les raisons pour lesquels vous pourriez vouloir utiliser un framework plutôt qu’une bonne vieille application PHP. Pour parler de pourquoi l’utilisation d’un framework utilisant les composants Symfony2 est une meilleure idée que celle d’en créer un de zéro.

Je ne parlerais pas des bénéfices évidents de l’utilisation d’un framework lorsque l’on travaille sur de grosses applications avec beaucoup de développeurs; Internet propose déjà beaucoup de ressources à ce sujet.
Lire la suite »

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

Symfony2 propose un ensemble réutilisable, découplé et uni de composants PHP qui résolvent des problèmes courants de développement web.

Au lieu d’utiliser ces composants bas niveau, vous pouvez utiliser directement Symfony2, le framework complet, prêt à l’emploi, qui est basé sur ces composants… ou bien vous pouvez créer votre propre framework. Cette série va parler de la seconde option.

Si vous voulez uniquement utiliser le framework Symfony2 complet, vous devriez plutôt lire la documentation officielle
NDT: Vous pouvez également utiliser la série d’articles que j’ai écrit sur le sujet: http://keiruaprod.fr/symblog-fr Lire la suite »

Nouvel article sur Symblog, sur les tests dans Symfony2.

Ce chapitre couvre un aspect très important du développement, les tests. Plutôt que de vérifier « manuellement » que le programme se comporte comme on le souhaite, nous allons regarder dans cet article comment mettre en place une automatisation des tests.

Sont couverts les tests unitaires, c’est à dire le comportement des méthodes en isolation, et les fonctionnels, c’est à dire si les composantes fonctionnent bien comme attendu lorsqu’on les fait fonctionner ensemble. Dans le cadre d’un site web, cela revient à regarder si les pages générées se comportent bien comme attendu.

Ce 6ème chapitre est donc disponible à l’adresse suivante: http://keiruaprod.fr/symblog-fr/docs/tests-unitaires-et-fonctionels-phpunit.html

En attendant l’apparition (prochaine, selon les rumeurs) de nouveaux chapitres dans la version originale de Symblog, je vais continuer à publier des articles sur Symfony2.