[Partie 5] - Personnalisation de la vue : extensions Twig, barre latérale et Assetic¶

Le nuage de tags¶

Le nuage de tags montre les tags des articles, les plus populaires ayant plus d’importance visuelle à travers un affichage plus gros. Pour celà, il nous faut un moyen de récupérer tous les articles de tous les articles. Créons de nouvelles méthodes dans la classe BlogRepository pour cela. Mettez à jour la classe BlogRepository dans src/Blogger/BlogBundle/Repository/BlogRepository.php avec ce qui suit.

// src/Blogger/BlogBundle/Repository/BlogRepository.php

public function getTags()
{
    $blogTags = $this->createQueryBuilder('b')
                     ->select('b.tags')
                     ->getQuery()
                     ->getResult();

    $tags = array();
    foreach ($blogTags as $blogTag)
    {
        $tags = array_merge(explode(",", $blogTag['tags']), $tags);
    }

    foreach ($tags as &$tag)
    {
        $tag = trim($tag);
    }

    return $tags;
}

public function getTagWeights($tags)
{
    $tagWeights = array();
    if (empty($tags))
        return $tagWeights;

    foreach ($tags as $tag)
    {
        $tagWeights[$tag] = (isset($tagWeights[$tag])) ? $tagWeights[$tag] + 1 : 1;
    }
    // Shuffle the tags
    uksort($tagWeights, function() {
        return rand() > rand();
    });

    $max = max($tagWeights);

    // Max of 5 weights
    $multiplier = ($max > 5) ? 5 / $max : 1;
    foreach ($tagWeights as &$tag)
    {
        $tag = ceil($tag * $multiplier);
    }

    return $tagWeights;
}

Comme les tags sont stockés dans la base de donnée au format CSV (comma separated values, c’est à dire que chaque valeur est séparée de la précédente par une virgule), il nous faut un moyen de séparer et de renvoyer le résultat sous la forme d’un tableau. C’est le rôle de getTags(). La méthode getTagWeights() se sert ensuite du tableau de tafs pour calculer le poids (weight) de chaque tag à partir de son nombre d’occurences dans le tableau. Les tags sont également mélangés afin d’ajouter un peu d’aléatoire à leur affichage.

Maintenant que nous sommes capable de générer un nuage de tags, il faut l’afficher. Créez une nouvelle action dans le PageController dans le fichier src/Blogger/BlogBundle/Controller/PageController.php pour gérer la barre latérale.

// src/Blogger/BlogBundle/Controller/PageController.php

public function sidebarAction()
{
    $em = $this->getDoctrine()
               ->getEntityManager();

    $tags = $em->getRepository('BloggerBlogBundle:Blog')
               ->getTags();

    $tagWeights = $em->getRepository('BloggerBlogBundle:Blog')
                     ->getTagWeights($tags);

    return $this->render('BloggerBlogBundle:Page:sidebar.html.twig', array(
        'tags' => $tagWeights
    ));
}

Cette action est très simple, elle utilise les 2 nouvelles méthodes du BlogRepository pour générer le nuage de tags, qu’elle passe ensuite en paramètres à la vue. Il nous faut maintenant créer cette vue, dans src/Blogger/BlogBundle/Resources/views/Page/sidebar.html.twig.

{# src/Blogger/BlogBundle/Resources/views/Page/sidebar.html.twig #}

<section class="section">
    <header>
        <h3>Tag Cloud</h3>
    </header>
    <p class="tags">
        {% for tag, weight in tags %}
            <span class="weight-{{ weight }}">{{ tag }}</span>
        {% else %}
            <p>There are no tags</p>
        {% endfor %}
    </p>
</section>

Le template est également très simple. Il traverse les différents tags, en leur associant une classe CSS en fonction de leur poids. Dans cette boucle for un peu particulière, on accède aux couples clé/valeur du tableau avec tag pour la clé et weight comme valeur. Il existe plusieurs variations de comment utiliser une boucle `for avec Twig disponible dans la ``documentation <http://twig.sensiolabs.org/doc/templates.html#for>`_.

Si vous regardez le principal template du BloggerBlogBundle dans src/Blogger/BlogBundle/Resources/views/layout.html.twig, vous pourrez remarquer que nous avions placé un élément temporaire pour le bloc de la barre latérale. On peut maintenant le remplacer, en affichant la nouvelle action de la barre latérale. Souvenez vous que la fonction Twig render permet d’afficher le contenu d’une action d’un controlleur, dans le cas présent l’action sidebar du controlleur Page.

{# src/Blogger/BlogBundle/Resources/views/layout.html.twig #}

{# .. #}

{% block sidebar %}
    {% render "BloggerBlogBundle:Page:sidebar" %}
{% endblock %}

Enfin, ajoutons de la CSS au nuage de tags. Créez la nouvelle feuille de style dans src/Blogger/BlogBundle/Resources/public/css/sidebar.css.

.sidebar .section { margin-bottom: 20px; }
.sidebar h3 { line-height: 1.2em; font-size: 20px; margin-bottom: 10px; font-weight: normal; background: #eee; padding: 5px;  }
.sidebar p { line-height: 1.5em; margin-bottom: 20px; }
.sidebar ul { list-style: none }
.sidebar ul li { line-height: 1.5em }
.sidebar .small { font-size: 12px; }
.sidebar .comment p { margin-bottom: 5px; }
.sidebar .comment { margin-bottom: 10px; padding-bottom: 10px; }
.sidebar .tags { font-weight: bold; }
.sidebar .tags span { color: #000; font-size: 12px; }
.sidebar .tags .weight-1 { font-size: 12px; }
.sidebar .tags .weight-2 { font-size: 15px; }
.sidebar .tags .weight-3 { font-size: 18px; }
.sidebar .tags .weight-4 { font-size: 21px; }
.sidebar .tags .weight-5 { font-size: 24px; }

Comme nous avons ajouté une nouvelle feuille de style, il faut l’inclure. Mettez à jour le template principale du BloggerBlogBundle dans src/Blogger/BlogBundle/Resources/views/layout.html.twig avec ce qui suit.

{# src/Blogger/BlogBundle/Resources/views/layout.html.twig #}

{# .. #}

{% block stylesheets %}
    {{ parent() }}
    <link href="{{ asset('bundles/bloggerblog/css/blog.css') }}" type="text/css" rel="stylesheet" />
    <link href="{{ asset('bundles/bloggerblog/css/sidebar.css') }}" type="text/css" rel="stylesheet" />
{% endblock %}

{# .. #}

$ php app/console assets:install web

Si vous mettez maintenant à jour la page d’accueil de Symblog, vous verrez que le nuage de tags est affiché dans la barre latérale. Afin que les tags soient affichés avec différents poids, vous devrez modifier les tags factices afin que certains soient plus utilisés que d’autres.

Commentaires récents.¶

Maintenant que le nuage de tags est en place, ajoutons un composant pour les derniers commentaires à la barre latérale.

Il nous faut tout d’abord un moyen de récupérer les derniers commentaires des articles. Nous allons pour cela ajouter une méthode dans le CommentRepository situé dans src/Blogger/BlogBundle/Repository/CommentRepository.php.

<?php
// src/Blogger/BlogBundle/Repository/CommentRepository.php

public function getLatestComments($limit = 10)
{
    $qb = $this->createQueryBuilder('c')
                ->select('c')
                ->addOrderBy('c.id', 'DESC');

    if (false === is_null($limit))
        $qb->setMaxResults($limit);

    return $qb->getQuery()
              ->getResult();
}

Maintenant, mettez à jour l’action de la barre latérale dans src/Blogger/BlogBundle/Controller/PageController.php afin de récupérer les derniers commentaires et les fournir à la vue.

// src/Blogger/BlogBundle/Controller/PageController.php

public function sidebarAction()
{
    // ..

    $commentLimit   = $this->container
                           ->getParameter('blogger_blog.comments.latest_comment_limit');
    $latestComments = $em->getRepository('BloggerBlogBundle:Comment')
                         ->getLatestComments($commentLimit);

    return $this->render('BloggerBlogBundle:Page:sidebar.html.twig', array(
        'latestComments'    => $latestComments,
        'tags'              => $tagWeights
    ));
}

Vous remarquerez également que nous avons utilisé un nouveau paramètre appelé blogger_blog.comments.latest_comment_limit afin de limiter le nombre de commentaires à afficher. Pour créer ce paramètre, mettez à jour le fichier de configuration dans src/Blogger/BlogBundle/Resources/config/config.yml avec ce qui suit.

# src/Blogger/BlogBundle/Resources/config/config.yml

parameters:
    # ..

    # Blogger max latest comments
    blogger_blog.comments.latest_comment_limit: 10

Il faut enfin afficher les derniers commentaires dans le template de la barre latérale. Mettez à jour le template dans src/Blogger/BlogBundle/Resources/views/Page/sidebar.html.twig en y ajoutant ce qui suit.

{# src/Blogger/BlogBundle/Resources/views/Page/sidebar.html.twig #}

{# .. #}

<section class="section">
    <header>
        <h3>Latest Comments</h3>
    </header>
    {% for comment in latestComments %}
        <article class="comment">
            <header>
                <p class="small"><span class="highlight">{{ comment.user }}</span> commented on
                    <a href="{{ path('BloggerBlogBundle_blog_show', { 'id': comment.blog.id }) }}#comment-{{ comment.id }}">
                        {{ comment.blog.title }}
                    </a>
                    [<em><time datetime="{{ comment.created|date('c') }}">{{ comment.created|date('Y-m-d h:iA') }}</time></em>]
                </p>
            </header>
            <p>{{ comment.comment }}</p>
            </p>
        </article>
    {% else %}
        <p>There are no recent comments</p>
    {% endfor %}
</section>

Si vous mettez maintenant à jour le site, vous verrez que les derniers commentaires sont affichés dans la barre latérale, juste en dessous du nuage de tags.

L’extension¶

Créez un fichier pour l’extension Twig dans src/Blogger/BlogBundle/Twig/Extensions/BloggerBlogExtension.php et mettez le à jour avec le contenu suivant.

<?php
// src/Blogger/BlogBundle/Twig/Extensions/BloggerBlogExtension.php

namespace Blogger\BlogBundle\Twig\Extensions;

class BloggerBlogExtension extends \Twig_Extension
{
    public function getFilters()
    {
        return array(
            'created_ago' => new \Twig_Filter_Method($this, 'createdAgo'),
        );
    }

    public function createdAgo(\DateTime $dateTime)
    {
        $delta = time() - $dateTime->getTimestamp();
        if ($delta < 0)
            throw new \Exception("createdAgo is unable to handle dates in the future");

        $duration = "";
        if ($delta < 60)
        {
            // Seconds
            $time = $delta;
            $duration = $time . " second" . (($time > 1) ? "s" : "") . " ago";
        }
        else if ($delta <= 3600)
        {
            // Mins
            $time = floor($delta / 60);
            $duration = $time . " minute" . (($time > 1) ? "s" : "") . " ago";
        }
        else if ($delta <= 86400)
        {
            // Hours
            $time = floor($delta / 3600);
            $duration = $time . " hour" . (($time > 1) ? "s" : "") . " ago";
        }
        else
        {
            // Days
            $time = floor($delta / 86400);
            $duration = $time . " day" . (($time > 1) ? "s" : "") . " ago";
        }

        return $duration;
    }

    public function getName()
    {
        return 'blogger_blog_extension';
    }
}

Créer l’extension est assez simple. On surcharge la méthode getFilters() pour renvoyer autant de filtres que l’on souhaite. Dans le cas présent, on a créé le filtre created_ago. Ce filtre est ensuite enregistré de manière à appeler la méthode createdAgo, qui se charge simplement de transformer un objet DateTime en une chaine de caractères qui représente la durée écoulée depuis la valeur stockée dans l’objet DateTime.

Enregistrer l’extension¶

Pour rendre l’extension Twig disponible, il faut mettre à jour le fichier de services dans src/Blogger/BlogBundle/Resources/config/services.yml avec ce qui suit.

services:
    blogger_blog.twig.extension:
        class: Blogger\BlogBundle\Twig\Extensions\BloggerBlogExtension
        tags:
            - { name: twig.extension }

Vous pouvez voir que celà enregistre un nouveau service en utilisant la classe d’extension BloggerBlogExtension que nous venons de créer.

Mettre à jour la vue¶

Le nouveau filtre Twig est désormais prêt à être utilisé. Mettons à jour la section des derniers commentaires de la barre latérale pour nous en servir. Mettez à jour le contenu du template de la barre latérale dans src/Blogger/BlogBundle/Resources/views/Page/sidebar.html.twig avec ce qui suit :

{# src/Blogger/BlogBundle/Resources/views/Page/sidebar.html.twig #}

{# .. #}

<section class="section">
    <header>
        <h3>Latest Comments</h3>
    </header>
    {% for comment in latestComments %}
        {# .. #}
        <em><time datetime="{{ comment.created|date('c') }}">{{ comment.created|created_ago }}</time></em>
        {# .. #}
    {% endfor %}
</section>

Si vous vous rendez maintenant sur la page d’accueil http://symblog.dev/app_dev.php/, vous allez voir que les dates des derniers commentaires utilisent le filtre Twig pour afficher les durées depuis lesquelles ils ont été postés.

Nous allons également mettre à jour les commentaires de la page d’affichage des articles afin d’utiliser là aussi le nouveau filtre. Remplacez le contenu du template dans src/Blogger/BlogBundle/Resources/views/Comment/index.html.twig avec ce qui suit.

{# src/Blogger/BlogBundle/Resources/views/Comment/index.html.twig #}

{% for comment in comments %}
    <article class="comment {{ cycle(['odd', 'even'], loop.index0) }}" id="comment-{{ comment.id }}">
        <header>
            <p><span class="highlight">{{ comment.user }}</span> commented <time datetime="{{ comment.created|date('c') }}">{{ comment.created|created_ago }}</time></p>
        </header>
        <p>{{ comment.comment }}</p>
    </article>
{% else %}
    <p>There are no comments for this post. Be the first to comment...</p>
{% endfor %}

Mise à jour de la route¶

Pour commencer, modifions les règles de routage pour la page d’affichage des articles afin d’ajouter sa nouvelle composante slug. Mettez à jour les règles de rouatge dans src/Blogger/BlogBundle/Resources/config/routing.yml

# src/Blogger/BlogBundle/Resources/config/routing.yml

BloggerBlogBundle_blog_show:
    pattern:  /{id}/{slug}
    defaults: { _controller: BloggerBlogBundle:Blog:show }
    requirements:
        _method:  GET
        id: \d+

Le controlleur¶

Comme avec le composant déjà existant id, le nouvel élément slug va être passé à l’action du controlleur en argument. Il faut donc mettre à jour le controlleur dans src/Blogger/BlogBundle/Controller/BlogController.php afin de répercuter ce changement.

// src/Blogger/BlogBundle/Controller/BlogController.php

public function showAction($id, $slug)
{
    // ..
}

BloggerBlogBundle_blog_show:
    pattern:  /{id}/{slug}/{comments}
    defaults: { _controller: BloggerBlogBundle:Blog:show, comments: true }
    requirements:
        _method:  GET
        id: \d+

public function showAction($id, $slug, $comments)
{
    // ..
}

Slugification du titre¶

Comme on veut générer le slug à partir du titre de l’article, nous allons générer automatiquement cette valeur. Nous pourrions réaliser celà automatiquement à l’exécution sur le titre de l’article, mais à la place nous allons plutôt stocker le slug dans l’entité Blog et le stocker dans la base de données.

Mise à jour de l’entité Blog¶

Ajoutons un nouveau membre à l’entité Blog pour stocker le slug. Mettez à jour l’entité Blog dans src/Blogger/BlogBundle/Entity/Blog.php

// src/Blogger/BlogBundle/Entity/Blog.php

class Blog
{
    // ..

    /**
     * @ORM\Column(type="string")
     */
    protected $slug;

    // ..
}

Générez maintenant les accesseurs pour le nouveau membre $slug. Comme avant, lancez la tâche :

$ php app/console doctrine:generate:entities Blogger

Il est ensuite temps de mettre à jour le schéma de base de donnée :

$ php app/console doctrine:migrations:diff
$ php app/console doctrine:migrations:migrate

Pour générer la valeur du slug, nous allons utiliser la méthode slugify du Tutorial Symfony 1 Jobeet. Ajoutez la méthode slugify dans l’entité Blog situé dans src/Blogger/BlogBundle/Entity/Blog.php

// src/Blogger/BlogBundle/Entity/Blog.php

public function slugify($text)
{
    // replace non letter or digits by -
    $text = preg_replace('#[^\\pL\d]+#u', '-', $text);

    // trim
    $text = trim($text, '-');

    // transliterate
    if (function_exists('iconv'))
    {
        $text = iconv('utf-8', 'us-ascii//TRANSLIT', $text);
    }

    // lowercase
    $text = strtolower($text);

    // remove unwanted characters
    $text = preg_replace('#[^-\w]+#', '', $text);

    if (empty($text))
    {
        return 'n-a';
    }

    return $text;
}

Comme nous voulons générer automatiquement le slug à partir du titre, on peut générer le slug lorsque la valeur du titre est affectée. Pour celà, on peut mettre à jour l’accesseur setTitle pour mettre également à jour la valeur du slug. Mettez à jour l’entité Blog dans src/Blogger/BlogBundle/Entity/Blog.php avec ce qui suit.

// src/Blogger/BlogBundle/Entity/Blog.php

public function setTitle($title)
{
    $this->title = $title;

    $this->setSlug($this->title);
}

Maintenant mettez à jour la méthode setSlug afin d’affecter une valeur slugifiée à l’attribut slug.

// src/Blogger/BlogBundle/Entity/Blog.php

public function setSlug($slug)
{
    $this->slug = $this->slugify($slug);
}

Maintenant rechargez les données factices pour générer les slugs des articles.

$ php app/console doctrine:fixtures:load

Mise à jour des routes générées¶

Il faut enfin mettre à jour les appels déjà existants à la génération de route vers la page d’affichage des articles. Il y a plusieurs endroits où celà doit être mis à jour.

Ouvrez le template de la page d’accueil dans src/Blogger/BlogBundle/Resources/views/Page/index.html.twig et remplacez son contenu avec ce qui suit. Il y a 3 modifications de la route BloggerBlogBundle_blog_show dans ce template. Les modifications ajoutent simplement le slug des titres des articles en paramètre de la fonction path.

{# src/Blogger/BlogBundle/Resources/views/Page/index.html.twig #}

{% extends 'BloggerBlogBundle::layout.html.twig' %}

{% block body %}
    {% for blog in blogs %}
        <article class="blog">
            <div class="date"><time datetime="{{ blog.created|date('c') }}">{{ blog.created|date('l, F j, Y') }}</time></div>
            <header>
                <h2><a href="{{ path('BloggerBlogBundle_blog_show', { 'id': blog.id, 'slug': blog.slug }) }}">{{ blog.title }}</a></h2>
            </header>

            <img src="{{ asset(['images/', blog.image]|join) }}" />
            <div class="snippet">
                <p>{{ blog.blog(500) }}</p>
                <p class="continue"><a href="{{ path('BloggerBlogBundle_blog_show', { 'id': blog.id, 'slug': blog.slug }) }}">Continue reading...</a></p>
            </div>

            <footer class="meta">
                <p>Comments: <a href="{{ path('BloggerBlogBundle_blog_show', { 'id': blog.id, 'slug': blog.slug }) }}#comments">{{ blog.comments|length }}</a></p>
                <p>Posted by <span class="highlight">{{ blog.author }}</span> at {{ blog.created|date('h:iA') }}</p>
                <p>Tags: <span class="highlight">{{ blog.tags }}</span></p>
            </footer>
        </article>
    {% else %}
        <p>There are no blog entries for symblog</p>
    {% endfor %}
{% endblock %}

De plus, une mise à jour doit être faite à la section Derniers commentaires de la barre latérale dans le template src/Blogger/BlogBundle/Resources/views/Page/sidebar.html.twig.

{# src/Blogger/BlogBundle/Resources/views/Page/sidebar.html.twig #}

{# .. #}

<a href="{{ path('BloggerBlogBundle_blog_show', { 'id': comment.blog.id, 'slug': comment.blog.slug }) }}#comment-{{ comment.id }}">
    {{ comment.blog.title }}
</a>

{# .. #}

Enfin, l’action createAction du CommentController doit être mise à jour lorsqu’elle redirige vers la page d’affichage d’un article lorsqu’un commentaire a été posté. Mettez à jour le CommentController situé dans src/Blogger/BlogBundle/Controller/CommentController.php avec ce qui suit.

// src/Blogger/BlogBundle/Controller/CommentController.php

public function createAction($blog_id)
{
    // ..

    if ($form->isValid()) {
        // ..

        return $this->redirect($this->generateUrl('BloggerBlogBundle_blog_show', array(
            'id'    => $comment->getBlog()->getId(),
            'slug'  => $comment->getBlog()->getSlug())) .
            '#comment-' . $comment->getId()
        );
    }

    // ..
}

Maintenant si vous allez sur la page d’accueil http://symblog.dev/app_dev.php/ et cliquez sur un des titres des articles, vous verrez que le slug des titres des articles est maintenant présent à la fin de l’URL.

Controlleur de facade¶

Pour le moment dans ce tutoriel, nous avons uniquement utilisé l’environnement de développement, ce qui nous avons précisé en utilisant le controlleur de facade app_dev.php lorsque nous avons fait des requêtes vers symblog, par exemple http://symblog.dev/app_dev.php/about. Si vous regardez le contenu du controlleur de facade de l’environnement de développement dans web/app_dev.php, vous y verrez la ligne suivante :

$kernel = new AppKernel('dev', true);

Cette ligne est celle qui fait démarrer Symfony2. Elle crée une nouvelle instance de l’AppKernel de Symfony2, et opte pour l’environnement dev.

En comparaison, si vous regardez le controlleur de façade de l’environnement de production dans web/app.php, vous y verrez :

$kernel = new AppKernel('prod', false);

Vous pouvez voir que l’environnement prod est fourni en paramètre à l’AppKernel dans cette instance.

L’environnement de test n’a pas de controlleur de façade, car il n’est pas censé être utilisé dans un navigateur. C’est pourquoi il n’y a pas de fichier app_test.php.

Paramètres de configuration¶

Nous avons vu plus haut comment les controlleurs de façade sont utilisés pour changer l’environnement dans lequel l’application tourne. Nous allons maintenant regarder comment les différents paramètres sont modifiés lorsque l’on utilise tel ou tel environnement. Si vous regardez les fichiers dans app/config, vous y verrez plusieurs fichiers config.yml. Plus précisémment, il y a un fichier de configuration principal, config.yml, et 3 autres qui sont suffixés du nom de l’environnement; config_dev.yml, config_test.yml et config_prod.yml. Chacun de ces fichiers est chargé selon l’environnement courant. Si nous ouvrons le fichier config_dev.yml, nous y verrons les lignes suivantes en entête :

imports:
    - { resource: config.yml }

La directive imports va permettre d’importer le contenu du fichier config.yml à l’intérieur de celui là. La même directive import peut être trouvée au début des 2 autres fichiers de configuration config_test.yml et config_prod.yml. L’inclusion d’un ensemble commun de paramètres de configuration définis dans config.yml permet d’avoir des valeurs spécifiques pour ces paramètres selon les environnements. On peut voir dans le fichier de configuration de l’environnement de développement app/config/config_dev.yml les lignes suivantes, qui configurent l’utilisation de la barre de débug :

# app/config/config_dev.yml

web_profiler:
    toolbar: true

Ce paramètre est absent dans le fichier de configuration de l’environnement de production car nous ne voulons pas que la barre d’outils soit affichée.

Fonctionner en production¶

Nous allons maintenant voir notre site tourner dans l’environnement de production. Pour cela, il faut tout d’abord vider le cache, à l’aide d’une commande Symfony2 :

$ php app/console cache:clear --env=prod

Maintenant rendez vous à l’adresse http://symblog.dev/. Remarquez qu’il manque le controlleur de façade app_dev.php.

<IfModule mod_rewrite.c>
    RewriteBase /
    # ..
</IfModule>

Vous allez remarquer que le site est presque identique, mais un certain nombre d’éléments sont différents. La barre de débug a disparue et les messages d’erreur détaillés ne sont plus affichés : essayez de vous rendre à l’adresse http://symblog.dev/999 pour vous en assurer.

Les messages d’exceptions détaillés ont été remplaces par un message plus simple, qui informe l’utilisateur qu’un problème a eu lieu. Ces écrans d’exceptions peuvent être configurés pour s’accorder avec le thème visuel de votre application. Nous reviendrons sur ce sujet dans un futur chapitre.

Vous pouvez également remarquer que le fichier app/logs/prod.log se remplit avec des informations sur l’exécution de l’application. C’est un aspect intéressant lorsque vous aurez des problèmes en production mais qu’il n’y aura plus les erreurs et exceptions de l’environnement de développement.

RewriteRule ^(.*)$ app.php [QSA,L]

Bien que nous ayions couvert les bases de l’environnement de production, nous n’avons pas parlé de plusieurs éléments liés à l’environnement de production, tel que la personnalisation des pages d’erreurs et le déploiement vers un serveur de production à l’aide d’outils tel que capifony. Nous reviendrons plus tard sur ces sujets dans un chapitre ultérieur.

Création de nouveaux environnements¶

Il est enfin intéressant de savoir que vous pouvez créer vos propres environnements facilement dans Symfony2. Par exemple, vous pouvez avoir envie d’avoir un environnement qui tourne sur le serveur de production mais affiche certaines informations de débug tel que les exceptions. Cela permettrait à la plateforme d’être testée manuellement sur le serveur de production, car les configurations des serveurs de développement et de production peuvent (et c’est souvent le cas) être différentes.

Bien que la création d’un nouvel environnement soit une tâche simple, elle va au delà du cadre de ce tutoriel. Il y a un excellent article article dans le livre de recettes de Symfony2 qui couvre ce sujet.

Assets¶

La librairie Assetic décrit un asset de la manière suivante :

Un asset Assetic est quelquechose avec un contenu filtrable qui peut être chargé et déchargé. Cela inclus également les métadonnées, certaines pouvant être manipulées et certaines étant fixées.

Plus simplement, les assets sont des ressources que l’application utilise tel que les feuilles de style et les images.

{# src/Blogger/BlogBundle/Resources/views/layout.html.twig #}

{# .. #}

{% block stylesheets %}
    {{ parent () }}

    {% stylesheets
        '@BloggerBlogBundle/Resources/public/css/*'
    %}
        <link href="{{ asset_url }}" rel="stylesheet" media="screen" />
    {% endstylesheets %}
{% endblock %}

{# .. #}

{# src/Blogger/BlogBundle/Resources/views/layout.html.twig #}

{# .. #}

{% block stylesheets %}
    {{ parent () }}

    {% stylesheets
        '@BloggerBlogBundle/Resources/public/css/blog.css'
        '@BloggerBlogBundle/Resources/public/css/sidebar.css'
    %}
        <link href="{{ asset_url }}" rel="stylesheet" media="screen" />
    {% endstylesheets %}
{% endblock %}

{# .. #}

<link href="/app_dev.php/css/d8f44a4_part_1_blog_1.css" rel="stylesheet" media="screen" />
<link href="/app_dev.php/css/d8f44a4_part_1_sidebar_2.css" rel="stylesheet" media="screen" />

{# src/Blogger/BlogBundle/Resources/views/layout.html.twig #}

{# .. #}

{% stylesheets
    '@BloggerBlogBundle/Resources/public/css/*'
    debug=false
%}
    <link href="{{ asset_url }}" rel="stylesheet" media="screen" />
{% endstylesheets %}

{# .. #}

<link href="/app_dev.php/css/3c7da45.css" rel="stylesheet" media="screen" />

{% stylesheets
    '@BloggerBlogBundle/Resources/public/css/*'
    output='css/blogger.css'
%}
    <link href="{{ asset_url }}" rel="stylesheet" media="screen" />
{% endstylesheets %}

{# app/Resources/views/base.html.twig #}

{# .. #}

{% block stylesheets %}
    <link href='http://fonts.googleapis.com/css?family=Irish+Grover' rel='stylesheet' type='text/css'>
    <link href='http://fonts.googleapis.com/css?family=La+Belle+Aurore' rel='stylesheet' type='text/css'>
    {% stylesheets
        'css/*'
    %}
        <link href="{{ asset_url }}" rel="stylesheet" media="screen" />
    {% endstylesheets %}
{% endblock %}

{# .. #}

{% javascripts
    '@BloggerBlogBundle/Resources/public/js/*'
%}
    <script type="text/javascript" src="{{ asset_url }}"></script>
{% endjavascripts %}

Filtres¶

La vrai puissance d’Assetic vient de ses filtres. Les filtres peuvent être appliqués à des assets ou à un ensemble d’assets. Il y a un grand nombre de filtres à l’intérieur de la librairie de base, qui réalisent les taches courantes suivantes :

1. CssMinFilter: minifaction de la CSS
2. JpegoptimFilter: optimisation des fichiers JPEGs
3. Yui\CssCompressorFilter: compression de fichiers CSS à l’aide de l’outil YUI compressor
4. Yui\JsCompressorFilter: compression de fichiers JavaScript à l’aide de l’outil YUI compressor
5. CoffeeScriptFilter: compile CoffeeScript en JavaScript

Une liste complète des filtres disponible se trouve dans le Readme Assetic.

Plusieurs de ces filtres passent en fait la main à un autre programme ou à une autre librairie, tel que YUI Compressor, donc il est possible que vous ayiez à installer ou configurer les librairies nécessaires pour utiliser certains filtres.

Téléchargez YUI Compressor, décompressez l’archive et copiez les fichiers du répertoire build dans app/Resources/java/yuicompressor-2.4.6.jar. Cela suppose que vous ayiez téléchargé la version 2.4.6, sinon changez le numéro de version en conséquences.

Nous allons ensuite configurer un filtre Assetic pour minifier la CSS à l’aide de YUI Compressor. Mettez à jour la configuration de l’application dans app/config/config.yml avec le contenu suivant :

# app/config/config.yml

# ..

assetic:
    filters:
        yui_css:
            jar: %kernel.root_dir%/Resources/java/yuicompressor-2.4.6.jar

# ..

Nous venons de configurer un filtre yui_css qui va utiliser l’exécutable Java de l’outil YUI Compressor, que nous allons placer dans le répertoire des ressources de l’application. Afin d’utiliser ce filtre, il faut lui préciser avec quels assets s’en servir. Mettez à jour le template dans src/Blogger/BlogBundle/Resources/views/layout.html.twig pour utiliser le filtre yui_css.

{# src/Blogger/BlogBundle/Resources/views/layout.html.twig #}

{# .. #}

{% stylesheets
    '@BloggerBlogBundle/Resources/public/css/*'
    output='css/blogger.css'
    filter='yui_css'
%}
    <link href="{{ asset_url }}" rel="stylesheet" media="screen" />
{% endstylesheets %}

{# .. #}

Si vous rafraichissez la page d’accueil du site Symblog et regardez les fichiers générés par Assetic, vous verrez qu’ils ont été minifiés. Bien que la minification soit une bonne idée sur un serveur de production, elle peut rendre le débuggage difficile, en particulier lorsque le Javascript est minifié. On peut la désactiver pour l’environnement development en préfixant le filtre avec un ? de la manière suivante.

{% stylesheets
    '@BloggerBlogBundle/Resources/public/css/*'
    output='css/blogger.css'
    filter='?yui_css'
%}
    <link href="{{ asset_url }}" rel="stylesheet" media="screen" />
{% endstylesheets %}

Génération des assets pour la production¶

En production, on peut générer les fichiers d’assets grâce à Assetic afin qu’ils deviennent de vrais fichiers prêts à être utilisés sur le serveur web. Le processus de création des assets avec Assetic pour chaque adresse peut être assez long, en particulier si des filtres sont appliqués aux assets. Le sauvegarder de manière définitive pour la production assure qu’Assetic ne sera pas utilisé pour manipuler les assets, mais seulement pour fournir les assets pré-traités. Lancez la commande suivante pour conserver les fichiers assets traités sur le disque :

$ app/console --env=prod assetic:dump

Vous pouvez remarquer que plusieurs fichiers CSS ont été générés dans le répertoire web/css. Si vous lancez Symblog dans l’environnement de production, vous verrez que les fichiers proviennent directement de ce répertoire.

Lecture additionnelle¶

Nous avons seulement abordé une fraction des possibilités offertes par Assetic. Il y a plus de ressources en ligne, en particulier dans le livre de recettes de Symfony2, en particulier (mais en anglais) :

How to Use Assetic for Asset Management

How to Minify JavaScripts and Stylesheets with YUI Compressor

How to Use Assetic For Image Optimization with Twig Functions

How to Apply an Assetic Filter to a Specific File Extension

Il y a également plusieurs bons articles de Richard Miller tel que :

Symfony2: Using CoffeeScript with Assetic

Symfony2: A Few Assetic Notes

Symfony2: Assetic Twig Functions