Jeremy Barthe

Speed-up your Vagrant environment for Symfony2

2015-02-02T00:00:00+00:00

This is my first post in english and probably not the last one for this new year. First of all, I’m really happy to say that I’ve joined the awesome KNP Labs team! I’ve just met all these cool guys during a hackathon in the north of France. It was a really nice experience.

On this post I want to share with you some tips about Symfony2 development on a Virtual Machine. I know that Docker is really trendy and cool nowadays and we used it a lot during the KNP hackathon but for project virtualization I’m still using Vagrant for now because it’s a stable solution, multi-platform and easy to provision.

There was a lot of articles about how to optimize your Vagrant environment, especially for Symfony2. Some of them date back to 2013:

And one more recent:

Running the Symfony application on Vagrant without NFS below 100ms

All these articles point the slow filesystem performance of shared folders in Virtual Machines, but the related techniques/tips to boost performance have a big drawback to me. You need to modify the source files of your project…

They advice to update the composer.json file, or even the autoload.php, AppKernel.php. And the idea is to move some directories, like vendor/ or app/{cache,logs}, outside of the shared folder to prevent too much I/O. I don’t really like this technique because it makes your code coupled to Vagrant, and in my opinion Vagrant is only a development platform for your project, it should not be required to adapt your code to this platform.

A better way should be to add some symbolic links of these folders to a destination inside of the Virtual Machine.

Hopefully there’s a Vagrant plugin that handle this kind of problem. His name is vagrant-cachier. This plugin creates some “cache buckets” that you can use in the Virtual Machine and they are also symlinked to the host machine. Initially this plugin was created to share some folders between Virtual Machines, especially for packages in common (like APT packages or Ruby, npm, etc.). But you can use it for any kind of packages or files, so it can be used for cache, logs and vendors files of Symfony2!

Finally, it speeds-up the Virtual Machine performance through symbolic links, and you can also access to these files from your host machine. It can be very useful for your text editor or your IDE to be able to access all the vendor files :-)

The plugin installation process is very easy (make sure you have Vagrant 1.4+):

$ vagrant plugin install vagrant-cachier

You can see below a configuration example for Vagrant and with the vagrant-cachier plugin configured for Symfony2 with vendor/ or app/{cache,logs} folders into cache buckets.

Vagrant.configure("2") do |config|
  # Configure the box
  config.vm.box = "your-box"

  # Example of shared folder
  config.vm.synced_folder ".", "/var/www", id: "application", :nfs => true

  # ...

  if Vagrant.has_plugin?("vagrant-cachier")
    config.cache.scope = :machine

    config.cache.synced_folder_opts = {
      type: :nfs,
      mount_options: ['rw', 'vers=3', 'tcp', 'nolock']
    }

    config.cache.enable :generic, {
      "cache"  => { cache_dir: "/var/www/app/cache" },
      "logs"   => { cache_dir: "/var/www/app/logs" },
      "vendor" => { cache_dir: "/var/www/vendor" },
    }
  end
end

I hope this Vagrant tip could help ;-)

Speed-up your Vagrant environment for Symfony2 was originally published by at Jeremy Barthe on February 02, 2015.

Exemple d'implémentation d'une API Symfony2 et d'un client AngularJS

2015-01-14T00:00:00+00:00

On parle souvent en ce moment de Single Page Applications (SPA), ces applications web riches et interactives à base de Javascript et d’API. Dans cet article, j’ai voulu présenter une application complète client / serveur. Cependant comme ces 2 aspects sont très différents et complexes, qu’ils pourraient faire l’objet d’articles dédiés, j’ai choisi d’utiliser des composants permettant de les mettre en place rapidement.

Je vais vous présenter 2 solutions :

ng-admin côté client, il s’agit d’une librairie AngularJS réalisée par la société Marmelab, elle permet de créer une interface d’administration (également appelé CRUD) basée sur les données d’une API REST ;
Lionframe côté serveur, et plus précisemment SyliusResourceBundle issu de la solution e-commerce Sylius, qui permet d’exposer sous la forme d’une API REST des entités Doctrine.

Dans cet article et dans le tutoriel associé (que vous trouverez sur Github), j’ai repris la version de démonstration de ng-admin mais avec une API dynamique en Symfony2 (à la place d’un mock). Il s’agit donc de gérer des posts, des commentaires et enfin des tags.

API REST en Symfony2

Je ne vais pas présenter la stack classique pour développer une API avec Symfony2, je pense bien sûr aux bundles FOSRestBundle, JMSSerializerBundle, Hateoas, NelmioApiDocBundle, etc. D’autres articles s’en chargent très bien et je vous recommande vivement leurs lecture :

Cela faisait quelques semaines que je voulais prendre un moment pour tester SyliusResourceBundle pour développer une API REST. Les développeurs de Lakion, également principaux développeurs de la solution e-commerce Sylius, l’ont fait avant moi. Leur article Rapid REST API Development with Lionframe présente comment développer rapidement une API avec SyliusResourceBundle et indirectement avec FOSRestBundle et les librairies JMSSerializerBundle et Hateoas.

SyliusResourceBundle est évidemment utilisé dans Sylius, et permet d’automatiser toutes les tâches “backend” autour d’une entité Doctrine, en d’autres termes le bundle automatise les actions, les formulaires, les listes, les filtres, etc. sans pour autant définir de présentation. C’est en ce sens là qu’il diffère des autres CRUD et admin generator qu’on peut voir habituellement dans Symfony2. Et surtout, une de ses fonctionnalités est d’exposer toutes les actions “backend” sous la forme d’une API REST.

La mise en place est très simple puisqu’elle se limite à l’installation de quelques bundles (voir ci-dessous) et à la définition d’entités Doctrine, des validations et la configuration du Serializer.

"require": {
    "sylius/resource-bundle": "0.13.*@dev",
    "sylius/resource": "0.13.*@dev",
    "sylius/storage": "0.13.*@dev",
    "friendsofsymfony/rest-bundle": "1.5.*@dev"
}

Dans le projet associé, j’ai créé les entités Post, Tag et Comment, et ajouté les validations ainsi que la configuration du Serializer.

Il ne reste plus qu’à demander à SyliusResourceBundle d’exposer nos ressources dans une API REST. Pour cela, 2 configurations sont nécessaires, au niveau de la configuration de Symfony2 et du routing :

app/config/api.yml (qu’il faudra penser à importer depuis le config.yml principal) :

sylius_resource:
    resources:
        app.post:
            driver:    doctrine/orm
            classes:
                model: AppBundle\Entity\Post
        app.comment:
            driver:    doctrine/orm
            classes:
                model: AppBundle\Entity\Comment
        app.tag:
            driver:    doctrine/orm
            classes:
                model: AppBundle\Entity\Tag

La création de ressource dans SyliusResourceBundle engendre la création de services, et plus spécifiquement de controlleurs, dont le but est de gérer les tâches “backend” autour de l’entité Doctrine :

Service ID              Class name
app.controller.comment  Sylius\Bundle\ResourceBundle\Controller\ResourceController
app.controller.post     Sylius\Bundle\ResourceBundle\Controller\ResourceController
app.controller.tag      Sylius\Bundle\ResourceBundle\Controller\ResourceController

app/config/routing.yml :

app_post:
    resource: app.post
    type:     sylius.api
    prefix:   /api

app_comment:
    resource: app.comment
    type:     sylius.api
    prefix:   /api

app_tag:
    resource: app.tag
    type:     sylius.api
    prefix:   /api

Pour rentrer un peu plus dans les détails, le type de Route sylius.api permet de charger dynamiquement les différentes routes de notre API REST permettant de gérer la ressource sous la forme d’un CRUD (liste, lecture, création, édition, suppression). Ci-dessous la liste des routes générées par la 1ère ligne du routing app_post et associé à la ressource app.post (et donc associé à l’entité Doctrine AppBundle\Entity\Post) :

Name                Method    Scheme Host Path
app_api_post_index  GET       ANY    ANY  /api/posts/
app_api_post_show   GET       ANY    ANY  /api/posts/{id}
app_api_post_create POST      ANY    ANY  /api/posts/
app_api_post_update PUT|PATCH ANY    ANY  /api/posts/{id}
app_api_post_delete DELETE    ANY    ANY  /api/posts/{id}

Il aurait été possible de définir ces routes manuellement, mais également d’en rajouter, comme par exemple une route permettant de lister les commentaires associés à un post (cf. routing.yml sur Github) :

app_api_post_comments:
    path: /api/posts/{id}/comments/
    defaults:
        _controller: app.controller.comment:indexAction
        _sylius:
            filterable: true
            criteria:
                post: $id

Et voilà ! Nous avons maintenant une API REST fonctionnelle et qui respecte les spécifications d’HAL pour l’exposition de ressources dans une API. HAL nous permet d’obtenir une réelle API REST puisque le niveau 3 du Richardson Maturity Model nous impose d’exposer des liens hypermedias entre les ressources, souvent appelé HATEOAS. Vous pouvez d’ailleurs lire mes slides d’introduction à HATEOAS.

Client en AngularJS

Toujours dans l’idée d’avoir un résultat fonctionnel et rapidement, pour la partie client, je vais utiliser ng-admin pour gérer les posts, commentaires et tags. Je vous recommande la lecture de Add an AngularJS admin GUI to any RESTful API pour mieux comprendre le fonctionnement de ng-admin. Comme la version de démonstration de ce dernier est basée sur les mêmes données, il va être intéressant de voir les modifications à apporter pour rendre notre administration fonctionnelle.

Grâce à Bower, l’équivalent de Composer pour gérer la dépendance vers des assets (projets CSS ou Javascript), il est très simple d’installer ng-admin :

{
  "name": "api-ng-admin-tutorial",
  "dependencies": {
    "ng-admin": "~0.4.0"
  },
  "resolutions": {
    "angular": "~1.3.8"
  }
}

L’initialisation de ng-admin dans le fichier index.html (voir sur Github) est également simpliste.

Une fois ng-admin initialisé :

var app = new Application('ng-admin backend demo')
    .baseApiUrl('http://localhost:8000/api/');

var post    = new Entity('posts');
var comment = new Entity('comments');
var tag     = new Entity('tags').readOnly();

app
    .addEntity(post)
    .addEntity(tag)
    .addEntity(comment);

Il devient possible d’implémenter une liste des Posts :

post.listView()
    .title('All posts')
    .addField(new Field('id').label('ID'))
    .addField(new Field('title'))
    .addField(new ReferenceMany('tags')
        .targetEntity(tag)
        .targetField(new Field('name'))
    )
    .listActions(['show', 'edit', 'delete']);

Et c’est là que les premiers problèmes se posent :

notre API expose les données en JSON selon les spécifications HAL donc les posts se trouvent dans _embedded (et non à la racine comme les attends ng-admin) ;
comment gérer la pagination et le nombre total d’éléments ? ;
la liste des tags attendue est une liste d’identifiants là où nous exposons pour l’instant une collection d’objet, il faudra voir comment adapter cela ;
toutes les requêtes sont faites sur l’URL /posts, là où notre API nécessite l’ajout du “trailing slash” (notamment pour la requête POST sur /posts/) ;
SyliusResourceBundle utilise les formulaires Symfony2 pour la création et la modification d’un élément via l’API, il est donc interdit d’envoyer dans la requête des champs additionnels.

Les 2 premiers problèmes se solutionnent en partie, par exemple pour les données dans _embedded la solution est d’utiliser l’option interceptor qui permet de transformer le résultat d’une requête :

function interceptor(data, operation, what, url, response, deferred) {
    if (operation === 'getList' && angular.isDefined(response.data._embedded)) {
        return response.data._embedded.items;
    }

    return response.data;
}

Pour la pagination il est également possible de personnaliser les paramètres envoyés à l’API. Quant au nombre total d’éléments, je n’ai pas trouvé de solution satisfaisante (la variable globale proposée dans l’exemple de l’API de Marvel ne fonctionne pas à 100%).

Toutes ces raisons m’ont poussé à utiliser la version master de ng-admin qui propose beaucoup plus de flexibilité, notamment dans les interactions avec l’API REST. En effet ng-admin utilise en interne la librairie Restangular pour réaliser les requêtes à l’API. Avec la version master, les fonctionnalités natives de Restangular sont beaucoup plus facilement accessibles, il est ainsi possible de personnaliser les requêtes, les réponses, transformer les résultats, etc.

Par exemple pour gérer la récupération des données dans _embedded et le nombre total de résultat retourné par l’API, il suffit de faire :

RestangularProvider.addResponseInterceptor(function(data, operation, what, url, response, deferred) {
    if (operation === 'getList' && angular.isDefined(response.data._embedded)) {
        response.totalCount = response.data.total;

        return response.data._embedded.items;
    }

    return response.data;
});

Les mêmes fonctionnalités existent pour personnaliser la requête à l’API, et par exemple supprimer des champs supplémentaires ou gérer la pagination :

RestangularProvider.addFullRequestInterceptor(function(element, operation, what, url, headers, params) {
    // ignore id element on update
    if (operation === 'put') {
        delete element.id;
    }

    // custom pagination params
    if (operation == "getList") {
        params.page = params._page;
        delete params._page;
        delete params._perPage;
    }

    return { params: params };
});

Et enfin une fonctionnalité a été ajouté dans ng-admin pour personnaliser l’URL d’une ressource, notamment pour gérer le “trailing slash” :

// customize Post URL with trailing slash
post.url(function(view, entityId) {
    return 'posts/' + (angular.isDefined(entityId) ? entityId : '');
});

Le fichier app.js complet est disponible sur Github.

Cet article avait pour but de vous présenter comment réaliser une Single Page Application (SPA) avec Symfony2 sur la partie serveur et AngularJS en client. Mais surtout comment développer un prototype rapidement grâce à SyliusResourceBundle qui automatise toutes les opérations “backend” possibles sur une entité Doctrine. Et sur la partie AngularJS, comment développer rapidement une interface de gestion aux données de l’API. Comme je pouvais m’y attendre c’est cette partie qui a été la plus complexe et la plus chronophage mais c’est évidemment lié à la jeunesse des outils.

J’espère que ça vous donnera envie de vous lancer dans la création de Single Page Applications, d’en apprendre plus sur l’architecture REST, ou encore sur le framework AngularJS.

Exemple d'implémentation d'une API Symfony2 et d'un client AngularJS was originally published by at Jeremy Barthe on January 14, 2015.

Hierarchical facets avec Elasticsearch

2014-11-13T00:00:00+00:00

Cet article a été intialement publié sur le blog de Lexik

Elasticsearch est devenu un outil incontournable pour l’indexation de documents et la recherche textuelle. Un des rares reproches qui pouvait lui être fait il y a quelques mois était son absence de support des facets hiérarchiques. Il s’agit en effet d’une fonctionnalité très utile et demandée dans les sites e-commerce.

Pour ceux qui ne seraient pas familiers avec le vocabulaire des moteurs de recherche, une « facet » (ou recherche à facette en français) permet de regrouper des données sur des résultats de recherche. Elles sont calculées en temps réel et on les retrouve très souvent sur les catégories d’un site e-commerce. Les facets permettent par exemple de retrouver toutes les catégories associées à des résultats de recherche, avec le nombre d’éléments correspondants.

Les facets hiérarchiques sont basées sur le même système mais avec une notion de hiérarchie (de profondeur) supplémentaire. On voit cette technique sur des sites e-commerce très connus, comme Amazon.fr comme vous pouvez voir sur la capture d’écran suivante :

Jusqu’à la version 1.0 d’Elasticsearch il était impossible de faire ce style de requête tandis que Solr les proposait via ses « Pivot Facets». En réponse à ce manque et aux limitations des facets, l’équipe d’Elasticsearch a introduit le concept d’agrégations. Outre le fait que le nom est beaucoup plus explicite, les agrégations sont également beaucoup plus flexibles. Leurs 2 atouts majeurs sont de pouvoir être définies en cascade (autrement dit de façon hiérarchique, une agrégation peut avoir une ou plusieurs sous-agrégations), et de pouvoir combiner différents types de filtre / groupe (comme des facets ou des calculs de statistiques).

Nous allons maintenant voir comment utiliser ces agrégations, et notre cas pratique sera un site e-commerce avec des catégories à plusieurs niveaux. Par simplicité l’exemple ci-dessous sera illustré via le service en ligne Play de found.no qui permet de définir son schéma, ses données et ses recherches Elasticsearch sur une instance publique. (La communication avec Elasticsearch se fait normalement en JSON, là où found.no a choisi un format Yaml un peu plus lisible.)

Supposons que nous ayons 3 produits, rangés dans 3 niveaux de catégories :

_type: product
category_level0: Books
category_level1: Computers & Technology
category_level2: Network Programming
name: Pro AngularJS

---

_type: product
category_level0: Books
category_level1: Computers & Technology
category_level2: Online Searching
name: ElasticSearch Server Second Edition

---

_type: product
category_level0: Books
category_level1: Arts & Photography
category_level2: Photography & Video
name: Humans of New York

Source : https://www.found.no/play/gist/c6fc7c11b8a4b5967008#documents

Le schéma Elasticsearch associé est le suivant :

product:
    properties:
        category_level0:
            type: string
            index: not_analyzed
        category_level1:
            type: string
            index: not_analyzed
        category_level2:
            type: string
            index: not_analyzed
        name:
            type: string

Source : https://www.found.no/play/gist/c6fc7c11b8a4b5967008#mappings

On choisi de ne pas analyser les catégories pour qu’elles soient indexées strictement comme spécifié. Elles ne seront donc pas optimisées pour être retrouvées via un moteur de recherche mais le seront pour nos agrégations.

Nous avons vu que les agrégations peuvent être définies en cascade, nous allons donc définir une agrégation sur le terme de la catégorie de 1er niveau et ainsi de suite jusqu’au niveau 3 :

size: 0

aggregations:
    category:
        terms:
            field: category_level0
        aggs:
            level1:
                terms:
                    field: category_level1
                aggs:
                    level2:
                        terms:
                            field: category_level2

Source : https://www.found.no/play/gist/c6fc7c11b8a4b5967008#search

Avec cette recherche, Elasticsearch va être capable de nous agréger les résultats des 3 produits sur les 3 niveaux de catégories :

aggregations:
  category:
    buckets:
      -
        key: "Books"
        doc_count: 3
        level1:
          buckets:
            -
              key: "Computers & Technology"
              doc_count: 2
              level2:
                buckets:
                  -
                    key: "Network Programming"
                    doc_count: 1
                  -
                    key: "Online Searching"
                    doc_count: 1
            -
              key: "Arts & Photography"
              doc_count: 1
              level2:
                buckets:
                  -
                    key: "Photography & Video"
                    doc_count: 1

Avec ces données, nous allons facilement pouvoir afficher une liste de ce type :

- Books (3)
    - Computers & Technology (2)
        - Network Programming (1)
        - Online Searching (1)
    - Arts & Photography (1)
        - Photography & Video (1)

Pour aller plus loin avec les agrégations d’Elasticsearch je vous recommande les 2 lectures suivantes :

Hierarchical facets avec Elasticsearch was originally published by at Jeremy Barthe on November 13, 2014.

Mode maintenance avec nginx

2014-01-22T00:00:00+00:00

Je cherchais une méthode simple pour mettre un site en maintenance, par exemple pendant des mises à jour de code. Je voulais une solution la plus simple et la plus légère possible, inutile de charger autre chose que du HTML pour une page de maintenance.

Nginx propose dans ses fichiers de configuration, un langage de script qui permet entre autre de définir des variables ou encore des conditions, afin par exemple de tester la présence d’un fichier sur le filesystem. Le mode maintenance ci-dessous ne s’activera que sous la présence d’un fichier :

server {
    listen 80;
    server_name mysite.com;
    root /home/project/web;
    # etc.

    if (-f /home/project/maintenance.lock) {
        set $maintenance 1;
    }

    # Remplacez ici par votre IP locale
    if ($remote_addr = "127.0.0.1") {
        set $maintenance 0;
    }

    if ($maintenance = 1) {
        return 503;
    }

    error_page 503 @maintenance;

    location @maintenance {
        rewrite ^(.*)$ /maintenance.html break;
    }
}

Concrêtement la présence du fichier maintenance.lock va activer le mode maintenance, sauf si l’IP du client est une IP autorisée. Cela vous permettra de tester votre site alors que les autres internautes auront un accès coupé au site.

Il ne vous reste plus qu’à créer une simple page maintenance.html pour avertir vos visiteurs.

Mode maintenance avec nginx was originally published by at Jeremy Barthe on January 22, 2014.

Introduction à HATEOAS aux Human Talks

2013-05-13T00:00:00+00:00

Human Talks, c’est un événement mensuel pour les développeurs. L’idée est de présenter en 10 minutes un sujet technique, que ce soit sur un langage, une méthodo, un projet, etc. J’ai eu l’occasion de présenter le fonctionnement d’une API REST HATEOAS lors des Human Talks de mai 2013.

Sous cet acronyme étrange et quasi imprononçable se cache un élément fondamental dans la mise en place d’une API REST, les liens hypermedias.

Dans les slides nous verrons le cas d’une API sans hateoas, puis son intégration et les avantages et les questions que cela soulève.

Voir les slides en plein écran

Introduction à HATEOAS aux Human Talks was originally published by at Jeremy Barthe on May 13, 2013.

Convertir une Exception en Response dans Symfony2

2013-02-04T00:00:00+00:00

La méthode traditionnelle pour retourner une page avec le framework Symfony2 est de retourner un objet Response. Toutefois on peut remarquer que les pages d’erreurs (notamment les 404) ne suivent pas ce principe. En effet pour déclencher un code d’erreur 404 et afficher la page correspondante, il suffit de lever une Exception comme ceci :

throw new NotFoundHttpException();

Il peut parfois s’avérer intéressant de reproduire ce système pour des Exceptions métiers dans son projet. Supposons par exemple que nous devons gérer des verrous sur l’édition d’un objet. C’est une demande fréquente sur des applications web (intranet par exemple) où lorsqu’un utilisateur se trouve sur le formulaire d’édition d’un objet, les autres utilisateurs, qui tentent d’accéder à ce même formulaire, doivent être bloqués et notifiés de l’édition en cours d’un utilisateur. Chez Lexik, nous avons récemment eu cette demande et nous l’avons traité via une Exception.

L’article suivant ne donnera pas une implémentation complète du bundle de gestion des verrous d’édition, que nous appellerons LockBundle tout au long de l’article, mais servira d’exemple pour montrer comment transformer une Exception dans Symfony2 en Response. Si vous êtes intéressés pour avoir une version Open Source du LockBundle, il suffit de le demander ;-)

Supposons que nous avons un service lock_manager capable d’ajouter et supprimer un verrou, ainsi que savoir si un objet est verrouillé ou non. La seule contrainte est que l’objet passé en paramètre doit implémenter l’interface LockableInterface.

<?php

namespace Acme\LockBundle\Model;

use Acme\LockBundle\Exception\LockedException;

class LockManager
{
    public function lock(LockableInterface $object)
    {
        // ...
    }

    public function unlock(LockableInterface $object)
    {
        // ...
    }

    public function verify(LockableInterface $object)
    {
        if (/* some condition */) {
            throw new LockedException();
        }
    }
}

Dans un contexte classique, depuis un Controller Symfony2, il faudrait retourner une Response avec une vue attachée, comme ceci :

<?php

namespace Acme\DemoBundle\Controller;

use Acme\LockBundle\Exception\LockedException;

class ArticleController extends Controller
{
    public function editAction(Request $request, Article $article)
    {
        try {
            $this->get('lock_manager')->verify($article)
        } catch (LockedException $e) {
            return $this->render('::locked.html.twig');
        }
        
        // ...
    }
}

Si cette action doit être réalisée à plusieurs reprises, depuis plusieurs Controller, ce code peut s’avérer rébarbatif et verbeux. Le plus simple serait d’appeler seulement la méthode verify de notre service et lever l’Exception si un verrou est présent. Par contre, dans ce contexte, c’est une page 500 qui s’affichera ce qui n’est pas acceptable.

Heureusement, Symfony2 et son composant HttpKernel nous offre beaucoup de souplesse et dispose d’un évènement lorsqu’une Exception est levée et non catchée. Il s’agit de l’évènement kernel.exception comme sa documentation l’indique this event allows you to create a response for a thrown exception. Il nous suffit de créer un listener :

<?php

namespace Acme\LockBundle\Listener;

use Symfony\Bundle\TwigBundle\TwigEngine;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\HttpKernel\Event\GetResponseForExceptionEvent;
use Acme\LockBundle\Exception\LockedException;

class LockedExceptionListener
{
    private $templating;

    public function __construct(TwigEngine $templating)
    {
        $this->templating = $templating;
    }

    public function onKernelException(GetResponseForExceptionEvent $event)
    {
        if ( ! $event->getException() instanceof LockedException) {
            return;
        }

        $response = $this->templating->renderResponse('::locked.html.twig');
        $event->setResponse($response);
    }
}

Il ne reste plus qu’à la définir en tant que service et l’associer à l’évènement kernel.exception :

services:
    listener.locked_exception:
        class: Acme\LockBundle\Listener\LockedExceptionListener
        arguments: [@templating]
        tags:
            - { name: kernel.event_listener, event: kernel.exception, method: onKernelException }

Avec ce listener, nous pouvons maintenant simplifier le code de notre Controller comme ceci :

public function editAction(Request $request, Article $article)
{
    $this->get('lock_manager')->verify($article);

    // ...
}

C’est très confortable car ce code peut être appelé depuis Controller ou même depuis classe modèle/service et le rendu pour l’utilisateur sera le même.

Nous pouvons même enrichir la Response du listener pour retourner un status code HTTP d’erreur (comme ce qui est fait pour les 404 par exemple). Pour cela il suffit d’éditer la classe LockedExceptionListener comme ceci :

$response = $this->templating->renderResponse(
    '::locked.html.twig',
    array(),
    // le 3ème paramètre permet de fournir un objet Response :
    new Response(null, 423)
);

Convertir une Exception en Response dans Symfony2 was originally published by at Jeremy Barthe on February 04, 2013.

Astuces de développement javascript avec symfony

2011-01-17T00:00:00+00:00

Cet article a été intialement publié sur le blog de Lexik

Attention : cet article a été rédigé en 2011, le contenu ou les éléments abordées peuvent être obsolète.

Dans cet article nous allons voir quelques astuces et bonnes pratiques, non pas directement de développement symfony mais de développement javascript au sein d’un projet symfony.

Si l’on reprend quelques bases de bonnes pratiques de développement javascript, on constate :

que vos javascripts doivent être non-intrusifs, autrement dit là pour améliorer l’expérience utilisateur et en aucun cas être indispensable au fonctionnement d’une page ;
que les javascript doivent être combinés en 1 seul fichier et minifié (ceci afin de limiter le nombre de requête HTTP et car le chargement de la page est arrêté à chaque balise script, notamment à cause d’un éventuel document.write(); ;
que l’appel au javascript doit être en bas de page ;

Cette liste est bien entendu non exhaustive, vous trouverez une liste plus détaillée par ici.

Toutes ces bonnes pratiques de développement Javascript n’ont pas toujours été facilitées dans symfony, notamment à la grande époque des helpers link_to_remote() & co. qui en ont ravi certains et fait cauchemarder d’autres. Et aujourd’hui encore bon nombre de widgets de formulaire retournent directement du code javascript (dépendant de jQuery ou autre) et qui ne fonctionneront évidemment plus dès lors que vos javascripts se trouveront en bas de page.

1. Où placer les javascripts dans le document

Idéalement et selon les recommandations de Yslow, en bas de page, donc juste avant la balise fermante <body> de votre layout.php. Ceci afin de ne pas ralentir inutilement le début du chargement de votre page, puisque chaque balise script bloque le chargement de la page (notamment pour gérer le document.write();).

Source : http://developer.yahoo.com/performance/rules.html#js_bottom

Si cette méthode ne vous gênera pas pour les librairies tierces telles que jQuery, qu’en est-il par contre de vos codes javascript ? Ils doivent également se trouver dans des fichiers séparés, dissociés de votre document HTML. Néanmoins comme je vois souvent le besoin pour les développeurs d’avoir le code javascript au sein du template symfony, voici une technique pour qu’il soit tout de même placé en fin de page : via un slot.

Un petit exemple de code :

// indexSuccess.php :
<?php slot('javascript') ?>
<script type="text/javascript">
  console.log('javascript @ bottom');
</script>
<?php end_slot() ?>

// layout.php :
<?php include_javascripts() ?>
<?php include_slot('javascript') ?>

Vous pourrez ainsi éditer votre code javascript depuis votre template PHP, bénéficier par exemple de valeurs dynamiques de PHP et pour autant que le code soit bien inclus en bas de page. Toutefois je vous recommande d’écrire du javascript là où il doit se trouver, à savoir dans un fichier JS…

De plus l’inconvénient majeur du slot est qu’il ne peut contenir qu’une valeur, il est écrasé à chaque utilisation. La technique fonctionne mais est très limitée. Pour ces besoins nous avons écrit chez Lexik un petit plugin “lxJavascript”, très similaire à l’utilisation d’un slot mais optimisé pour l’inclusion de javascripts. Il gère donc le multiple ajout, supprime les éventuelles multiples balises script pour en conserver qu’une seule, etc. Vous en saurez plus demain, le plugin sort en OpenSource sur le Github de Lexik.

2. Compression

La compression des javascripts (c’est valable aussi pour les CSS) est une des tâches d’optimisations les plus importantes et également une des plus simples, du moins via les plugins symfony. Cette technique consiste à compresser tous vos fichiers javascript en 1 seul et surtout d’y appliquer un numéro de version (un timestamp le plus souvent) afin de prévenir des problèmes de cache dans vos mises à jour.

Les principaux plugins :

Chez Lexik, nous utilisons npAssetsOptimizerPlugin, un plugin de Nicolas Perriault, extrêmement simple à installer et paramétrer. Sur votre environnement de production, vous obtiendrez ainsi un fichier javascript compressé /js/optimized.js?1294759429 qui contient un timestamp permettant à chaque modifications des fichiers d’être prises en compte sans problème de cache.

Nous n’appliquons pas la compression pour les librairies externes telles que jQuery que nous déléguons aux serveurs CDN de Google, cela apporte ces avantages notables :

l’avantage du CDN, à savoir de proposer des données statiques via un réseau de multiples serveurs dans de multiples points géographiques, afin de permettre un accès très court ;
les navigateurs sont limités sur le nombre de connexions HTTP simultanées sur un même domaine, le téléchargement d’un javascript sur les serveurs de Google se fera en parallèle ;
les librairies du CDN ont les bonnes en-têtes de cache, par exemple la version 1.4.4 de jQuery restera en cache pendant 1 an sur le client, cela signifie également qu’un internaute peut bénéficier du cache téléchargé depuis un autre site, pas forcément sur le votre.

3. Accéder à certaines données dynamiques depuis javascript

Il peut parfois être très utile depuis javascript d’accéder à certaines données dynamiques telles que la culture de l’utilisateur, du routing pour des appels Ajax ou encore de l’i18n. Il suffit de s’appuyer sur un simple fichier de configuration via un tableau de données JSON généré depuis une action symfony. J’ai écrit sur mon blog personnel un article détaillé sur le sujet Configurations Javascript dynamiques en Symfony.

Maintenant que vos inclusions de javascripts se trouvent en bas de page, jQuery par exemple, que faire de nos chers widgets jQuery Autocompleter sfWidgetFormJQueryAutocompleter et autre Datepicker sfWidgetFormJQueryDate qui retournent des champs de formulaire et le javascript d’initialisation du composant ? Eh bien, ne plus les utiliser… Simplement car ils seront inclus avant jQuery et vous aurez donc droit à l’erreur “jQuery is not defined”. Sans être aussi extrême, vous pouvez charger jQuery en haut de page (via les CDN de Google) et votre script compressé en bas de page, les widgets de formulaire seront alors à nouveau fonctionnels.

Cela fait déjà quelques temps que chez Lexik nous avons fait le choix d’enlever tous ces widgets pour les ré-écrire et les adapter à nos besoins. Les javascripts des widgets passent par notre plugin lxJavascript ce qui permet de les inclure là où on le souhaite. Egalement, le javascript retourné par ces widgets correspond à une utilisation basique du composant, dans un cas concrêt il est souvent nécessaire d’en ré-écrire une bonne part. Il peut être pratique par contre que le widget retourne seulement la sémantique HTML adaptée, par exemple dans le cas d’un Autocomplete un champ hidden pour stocker la valeur et un champ texte pour l’autocomplete, aussi nos widgets ont une option pour retourner ou non le code javascript.

5. Optimisation frontend

Presque aussi important que la compression, la configuration d’apache pour mettre en cache certains de vos fichiers statiques. Typiquement, maintenant que vos fichiers javascripts et CSS sont compressés en 1 seul et possèdent un timestamp unique par version, il serait dommage de les recharger à chaque chargement de page… Vous devez donc configurer le module Expires d’apache via le fichier de config du vhost ou via le .htaccess, en voici un exemple :

<IfModule mod_expires.c>
  ExpiresActive on
  ExpiresByType text/css "access plus 1 year"
  ExpiresByType text/javascript "access plus 1 year"
</IfModule>

Vos fichiers javascript et CSS seront ainsi en cache pendant 1 an, attention du coup à ne pas avoir de fichier sans numéro de version, car ils resteraient en cache et vos internautes ne bénéficieraient pas de vos mises à jour…

Dernière chose, si ce n’est pas encore fait, installez et testez Yslow pour trouver des pistes d’optimisations de performance de vos sites.

Astuces de développement javascript avec symfony was originally published by at Jeremy Barthe on January 17, 2011.

Valider simplement ses formulaires Symfony en JS

2010-11-11T00:00:00+00:00

Attention : cet article a été rédigé en 2010, le contenu ou les éléments abordées peuvent être obsolète.

Dans cet article nous allons voir comment facilement valider un formulaire Symfony via les sfEvent.

Il existe de nombreuses méthodes pour valider ses formulaires en Javascript, mais celle que j’apprécie consiste à passer des données à la sémantique HTML des éléments de formulaire pour indiquer au javascript qu’elles sont les conditions à valider. En d’autres termes cela revient par exemple à renseigner un attribut class avec des valeurs telles que required ou encore email, etc. ou encore via un JSON toujours placé dans l’attribut class, récupéré ensuite grâce à jquery.metadata.

VanadiumJS, une librairie jQuery, est basée sur ce principe, elle ajoute une couche de validation javascript via des classes CSS de type :required, etc. Malheureusement elle souffre de quelques défauts, notamment l’I18N. Le jQuery plugin validation permet également de valider sous cette forme, il permet aussi une écriture des règles en javascript, hors de la sémantique HTML.

Le code ci-dessous a été testé avec ces 2 librairies Javascript. J’ai choisi de vous présenter le code correspondant à la librairie jQuery plugin validation car je la considère plus pérenne et elle gère l’I18N.

Prenons un formulaire d’exemple, avec différents widgets mais surtout un panel variés de validators :

class ExampleDataForm extends BaseForm
{
  public function configure()
  {
    $this->setWidgets(array(
      'name'        => new sfWidgetFormInputText(),
      'email'       => new sfWidgetFormInputText(),
      'number'      => new sfWidgetFormInputText(),
      'price'       => new sfWidgetFormInputText(),
      'description' => new sfWidgetFormTextarea(),
      'url'         => new sfWidgetFormInputText(),
      'cgu'         => new sfWidgetFormInputCheckbox(),
    ));

    $this->setValidators(array(
      'name'        => new sfValidatorString(array('min_length' => 5, 'max_length' => 255)),
      'email'       => new sfValidatorEmail(array('required' => true)),
      'number'      => new sfValidatorInteger(array('required' => false)),
      'price'       => new sfValidatorNumber(array('required' => true)),
      'description' => new sfValidatorString(array('max_length' => 4000)),
      'url'         => new sfValidatorUrl(array('required' => true)),
      'cgu'         => new sfValidatorBoolean(array('required' => true)),
    ));

    $this->widgetSchema->setNameFormat('example_data[%s]');
  }
}

L’événement form.post_configure est notifié lorsque le formulaire est configuré, autrement dit après que les widgets et les validators soient initialisés. A ce moment là, il sera très simple de modifier les attributs des widgets pour leur ajouter quelques classes en fonction du validator et de ses options.

Il faut donc se connecter à l’événement, je vous laisse libre d’implémenter ceci dans votre ProjectConfiguration ou encore dans la configuration d’une de vos applications :

$this->dispatcher->connect('form.post_configure', array($this, 'listenToFormPostConfigureEvent'));

Ci-dessous un exemple d’implémentation de la méthode listenToFormPostConfigureEvent pour gérer quelques validators :

public function listenToFormPostConfigureEvent(sfEvent $event)
{
  $validatorSchema = $event->getSubject()->getValidatorSchema();

  // iterates over the widgets:
  foreach ($event->getSubject() as $formField)
  {
    $widget = $formField->getWidget();

    // retrieve validator associated to widget:
    $validator = $validatorSchema[$formField->getName()];

    // required
    if ($validator->getOption('required'))
    {
      $this->mergeClass($widget, 'required');
    }

    // min length
    if ($validator->getOption('min_length'))
    {
      $widget->setAttribute('minlength', $validator->getOption('min_length'));
    }

    // max length
    if ($validator->getOption('max_length'))
    {
      $widget->setAttribute('maxlength', $validator->getOption('max_length'));
    }

    // number
    if ($validator instanceof sfValidatorInteger || $validator instanceof sfValidatorNumber)
    {
      $this->mergeClass($widget, 'number');
    }

    // email
    if ($validator instanceof sfValidatorEmail)
    {
      $this->mergeClass($widget, 'email');
    }

    // url
    if ($validator instanceof sfValidatorUrl)
    {
      $this->mergeClass($widget, 'url');
    }
  }
}

/**
 * Merge CSS classes to the given widget.
 *
 * @param $widget
 * @param $className
 */
public function mergeClass($widget, $className)
{
  return $widget->setAttribute('class', (null !== $widget->getAttribute('class')) ? sprintf('%s %s', $widget->getAttribute('class'), $className) : $className);
}

Pour résumer, la méthode listenToFormPostConfigureEvent va itérer sur les différents widgets du formulaire, et pour chacun d’eux va récupérer son validator. Elle va alors modifier les attributs du widget (le plus souvent l’attribut class) pour y indiquer quel type de validation devra opérer la partie Javascript.

Libre à vous d’implémenter d’autres validators. Il serait même possible de passer par un JSON (technique metadata) pour ainsi gérer plus de cas, plus d’options liés à la documentation de jQuery plugin validation.

N’oubliez pas de charger les différents javascripts, à savoir jQuery et ceux du plugin de validation (vous pouvez en option ajouter un JS localisé proposé par le plugin ou encore un fichier contenant vos propres traductions pour les messages d’erreurs, c’est très pratique) :

default:
  javascripts:
    - //ajax.googleapis.com/ajax/libs/jquery/1.4.3/jquery.min.js
    - jquery-validation/jquery.validate.js
    - jquery-validation/localization/messages_fr.js # optional

Et maintenant dans votre vue (considérons que vous avez correctement affiché votre formulaire) il ne reste plus qu’à initialiser le javascript du plugin de validation, via :

<script type="text/javascript" charset="utf-8">
  $(function(){
    $("form").validate();
  });
</script>

Voici le résultat que j’obtiens :

Si vous souhaitez adapter ce code à VanadiumJS, ce ne sera pas très compliqué, il suffira de faire quelques adaptations au niveau des classes, par exemple : required devient :required, min_length et max_length ne sont plus des attributs du widget mais des classes, etc. Il suffit de se référer à la documentation de VanadiumJS.

Conclusion :

Pour conclure, on constate qu’il a été très simple d’étendre les fonctionnalités de sfForm mais surtout de généraliser ce comportement à tous les formulaires. Evidemment n’utilisez pas forcément ce code là en production, car il va s’exécuter pour tous vos formulaires, ce qui n’est pas forcément souhaitable. Il serait toutefois assez simple de définir via un app.yml une collection de noms de formulaires pour lesquels on souhaite appliquer des validations côté client.

Sachez qu’il existe également un plugin Symfony de validation javascript : sfJqueryFormValidationPlugin (qui au passage se base sur le même plugin jQuery que cet article). Par contre ce dernier ne se base pas sur les events Symfony, il fonctionne via un filter qui ajoute des fichiers javascripts dynamiques qui précise les règles de validation des formulaires.

Valider simplement ses formulaires Symfony en JS was originally published by at Jeremy Barthe on November 11, 2010.

Halte aux hacks CSS IE

2010-11-06T00:00:00+00:00

Attention : cet article a été rédigé en 2010, le contenu ou les éléments abordées peuvent être obsolète.

Autant pendant un temps ils n’avaient plus la côte, autant ces derniers mois je trouve qu’on lit trop d’articles sur les hacks CSS pour IE…

Que ce soit ici ou là ou encore là, on lit les louanges des * html et autres *+html, _ ou encore pire avec l’utilisation de \9… mais wtf?!

Le principal problème lié à l’utilisation d’un hack CSS, c’est que son périmètre d’application n’est pas maîtrisé, étant donné qu’il exploite une faille, son comportement futur ne peut pas être contrôlé…

Imaginons un instant qu’IE corrige son interprétation des CSS, même si ce n’est pas leur genre… Ou encore que gecko ou webkit se retrouve impacté par l’une de ses failles, il récoltera alors les propriétés initialement prévue pour IE, pas sûr qu’il apprécie… En plus bien souvent les hacks rendent vos CSS invalides au validateur W3C.

Pour résumer ces hacks ne sont pas une solution pérenne. D’autant plus lorsqu’on peut exploiter une réelle feature pour cibler différentes versions d’IE via les commentaires conditionnels (article en français). Et si comme moi, créer une CSS avec les règles spécifiques pour une version d’IE vous rebute, il existe depuis déjà longtemps la technique du <body> conditionnel, un exemple :

<!--[if lt IE 7]> <body id="ie6"><![endif]-->
<!--[if IE 7]>    <body id="ie7"><![endif]-->
<!--[if IE 8]>    <body id="ie8"><![endif]-->
<!--[if IE 9]>    <body id="ie9"><![endif]-->
<!--[if gt IE 9]> <body><![endif]-->
<!--[if !IE]><!--><body><!--<![endif]-->

J’utilise cette technique sur la plupart de mes sites depuis 2 ans et j’en suis ravi. Je l’ai découverte via ce post et ensuite via un article bien plus complet de Paul Irish.

L’inconvénient majeur que je trouvais aux commentaires conditionnels, c’était de devoir créer différentes CSS et de devoir dupliquer certains sélecteurs pour compenser certaines défaillances d’IE. Ca peut vite devenir compliqué à maintenir dans le temps.

Avec un <body> conditionnel, j’édite mes conditions directement dans ma CSS :

#test { min-height: 100px; }
#ie6 #test { height: 100px; }

Et comme dans l’absolu votre CSS ne devrait pas nécessiter de hacks, nous pourrions simplifier l’identifiant conditionnel à :

<!--[if lt IE 7]> <body id="ie6"><![endif]-->
<!--[if IE 7]>    <body id="ie7"><![endif]-->
<!--[if gt IE 7]> <body><![endif]-->
<!--[if !IE]><!--><body><!--<![endif]-->

Ca vous laisse la possibilité de spécifier pour IE 6 et 7, ce qui est largement suffisant.

Voyons maintenant un petit exemple appliqué à Symfony :

<!--[if lt IE 7]> <body id="ie6" class="ie lang-<?php echo $sf_user->getCulture() ?> env-<?php echo sfConfig::get('sf_environment') ?>"><![endif]-->
<!--[if IE 7]>    <body id="ie7" class="ie lang-<?php echo $sf_user->getCulture() ?> env-<?php echo sfConfig::get('sf_environment') ?>"><![endif]-->
<!--[if gt IE 7]> <body class="ie lang-<?php echo $sf_user->getCulture() ?> env-<?php echo sfConfig::get('sf_environment') ?>"><![endif]-->
<!--[if !IE]><!--><body class="lang-<?php echo $sf_user->getCulture() ?> env-<?php echo sfConfig::get('sf_environment') ?>"><!--<![endif]-->

Comme vous voyez, en plus des attributs liés à IE, je fais passer la culture et l’environnement de l’utilisateur. Cela permet de gérer d’éventuels background liés à la langue d’affichage. Et pour l’environnement, je m’en sers pour modifier le background du body d’un site pour son environnement de pré-production, cela permet au client de bien différencier les 2 sites.

Pour finir, c’est ok pour tout le monde ? Fini les hacks CSS, hein ? ;)

Halte aux hacks CSS IE was originally published by at Jeremy Barthe on November 06, 2010.

Du routing depuis les tests fonctionnels

2010-11-02T00:00:00+00:00

Attention : cet article a été rédigé en 2010, le contenu ou les éléments abordées peuvent être obsolète.

Lorsque l’on développe des tests fonctionnels en symfony avec lime, on se rend compte du lien fort qu’il y à la fois entre la sémantique HTML et les tests mais également entre les URLs et les tests. Voici un exemple :

$browser->get('/category/index');

Utiliser des URL comme celle-ci dans les tests fonctionnels peut être handicapant si en fin de projet votre client demande une optimisation des URLs. Vous allez probablement retravailler votre routing en conséquence. Et dès lors une bonne part de vos tests fonctionnels risquent de ne plus fonctionner. Alors, pourquoi ne pas tout simplement utiliser des routes dans vos tests fonctionnels ? D’autant plus que le routing.yml référence l’intégralité des URLs de votre application, ce serait dommage de s’en priver !

Voici 2 méthodes pour utiliser le routing symfony depuis vos tests fonctionnels :

$app = 'frontend';
include(dirname(__FILE__).'/../../bootstrap/functional.php');

$browser = new sfTestFunctional(new sfBrowser());

$context = sfContext::getInstance();

$browser->
  info(sprintf('Context way: %s', $context->getRouting()->generate('example_route')));

$configuration->loadHelpers(array('Url'));

$browser->
  info(sprintf('Helper way: %s', url_for('@example_route')));

Dans ces 2 techniques, inutile de modifier quoi que ce soit dans votre bootstrap functional.php. A part si le sfContext::getInstance() vous pique les yeux, ce que je comprendrai allègrement, vous pouvez modifier functional.php, en remplaçant :

// replace:
sfContext::createInstance($configuration);
// by:
$context = sfContext::createInstance($configuration);

Vous pouvez maintenant utiliser $context.

Personnellement, j’utilise la méthode via le helper URL ;-)

Du routing depuis les tests fonctionnels was originally published by at Jeremy Barthe on November 02, 2010.

Configurations Javascript dynamiques en Symfony

2010-11-02T00:00:00+00:00

Attention : cet article a été rédigé en 2010, le contenu ou les éléments abordées peuvent être obsolète.

Dans cet article nous allons voir comment accéder à des données dynamiques provenant de symfony, en Javascript. Pour quelle raison ? Car il est parfois nécessaire depuis JS d’avoir à accéder à des données telles que : de l’i18n, des URLs générés à partir du routing, la culture de l’utilisateur, etc.

I18n pour le titre d’une modalbox par exemple, dont le site serait internationalisé. URLs pour des appels Ajax, où il est déconseillé de recopier l’URL en dur dans le fichier JS… Et la culture pour bien configurer certains JS qui proposent des fichiers de traductions.

Pour cela, je vous propose de préparer un tableau JSON, en voici un exemple :

var globalConfigs = {
  env                     : '<?php echo sfConfig::get('sf_environment') ?>',
  userCulture             : '<?php echo $sf_user->getCulture() ?>',
  urls: {
    ajaxAutocomplete      : '<?php echo url_for('@homepage') ?>',
    ajaxModalBox          : '<?php echo url_for('@homepage') ?>'
  },
  i18n: {
    example               : "<?php echo esc_specialchars(__('example')) ?>",
    exampleModalboxTitle  : "<?php echo esc_specialchars(__('example_modalbox_title')) ?>"
  }
};

Nous pouvons ainsi accéder à l’environnement, la culture de l’utilisateur, des URLs et de l’I18n. Maintenant, où placer ce JS ? 2 solutions s’offrent à nous :

directement dans votre layout.php (via un partial ou component) ;
dans un module > action avec un routing spécifique.

Personnellement je trouve plus propre la deuxième méthode même si elle est plus complexe à mettre en place ;)

C’est parti, nous créons donc un simpliste module nommé js, associé à son action tout aussi simpliste configs dont nous imposons le sf_format à js, soit un template nommé configsSuccess.js.php.

Le routing correspondant :

javascript_configs:
  url:    /js/configs.:sf_format
  param:  { module: js, action: configs, sf_format: js }

Il ne reste plus qu’à inclure ce JS dans toutes nos pages. Pour cela nous pouvons utiliser le système d’événement de Symfony. Etant donné que j’ai besoin à la fois de la sfWebResponse et de sfRouting je vais passer par l’event context.load_factories. Même si j’aurai préféré proposer un event plus approprié, car on a tendance à overused cet event pour tout et n’importe quoi…

Vous pouvez placer ce code dans votre ProjectConfiguration ou plutôt dans la configuration de votre application :

public function configure()
{
  $this->dispatcher->connect('context.load_factories', array($this, 'listenToContextLoadFactoriesEvent'));
}

public function listenToContextLoadFactoriesEvent(sfEvent $event)
{
  $event->getSubject()->getResponse()->addJavascript($event->getSubject()->getRouting()->generate('javascript_configs'));
}

La configuration JS est dorénavant accessible, voici quelques exemples d’utilisation :

// env condition:
if (globalConfigs.env == 'dev') {}

// jQuery DOM manipulation:
$('#example').html(globalConfigs.i18n.example);

// jQuery ajax call:
$.get(globalConfigs.urls.ajaxAutocomplete, function(data) {});

// enjoy!

En allant plus loin, vous pouvez par exemple piloter les éditeurs wysiwygs de vos applications et cloisoner leurs configurations. Dans l’exemple ci-dessous, les boutons de l’éditeur sont configurés via le app.yml, vous pouvez ainsi offrir une configuration différente pour vos applications.

var globalConfigs = {
  // ...

  wysiwyg: {
    script_url: '/js/tiny_mce/tiny_mce.js',
    theme: "advanced",
    element_format : "xhtml",
    cleanup : true,
    theme_advanced_buttons1: "<?php echo sfConfig::get('app_tinymce_theme_advanced_buttons1') ?>",
    theme_advanced_buttons2: "<?php echo sfConfig::get('app_tinymce_theme_advanced_buttons2') ?>",
    theme_advanced_buttons3: "<?php echo sfConfig::get('app_tinymce_theme_advanced_buttons3') ?>",
    theme_advanced_buttons4: "<?php echo sfConfig::get('app_tinymce_theme_advanced_buttons4') ?>",
    theme_advanced_toolbar_location: "top",
    theme_advanced_toolbar_align: "left",
    width: "100%",
    paste_auto_cleanup_on_paste : true
  }
};

De plus cela permet de centraliser des configurations pour éviter de se répéter (DRY) :

// TinyMCE via jQuery plugin:
$('#wysiwyg').tinymce(globalConfigs.wysiwyg);

Voilà, qu’en pensez vous ? Utilisez vous des systèmes similaires ? Ou pas ? ;)

Configurations Javascript dynamiques en Symfony was originally published by at Jeremy Barthe on November 02, 2010.

Jeremy Barthe

Speed-up your Vagrant environment for Symfony2

Exemple d'implémentation d'une API Symfony2 et d'un client AngularJS

API REST en Symfony2

Client en AngularJS

Hierarchical facets avec Elasticsearch

Mode maintenance avec nginx

Introduction à HATEOAS aux Human Talks

Convertir une Exception en Response dans Symfony2

Astuces de développement javascript avec symfony

1. Où placer les javascripts dans le document

2. Compression

3. Accéder à certaines données dynamiques depuis javascript

4. Javascript depuis les widget

5. Optimisation frontend

Valider simplement ses formulaires Symfony en JS

Conclusion :

Halte aux hacks CSS IE

Du routing depuis les tests fonctionnels

Configurations Javascript dynamiques en Symfony