Blog Symfony2 - Lexik Montpellier » backend http://www.lexik.fr/blog/symfony Blog sur le développement Web PHP avec Symfony 2 Thu, 02 Feb 2012 14:00:26 +0000 en hourly 1 http://wordpress.org/?v=3.3 Utilisation de VHost pour l’accès au backend http://www.lexik.fr/blog/symfony/symfony/utilisation-de-vhost-pour-lacces-au-backend-1307 http://www.lexik.fr/blog/symfony/symfony/utilisation-de-vhost-pour-lacces-au-backend-1307#comments Wed, 27 Oct 2010 07:54:59 +0000 cedric http://www.lexik.fr/blog/symfony/?p=1307 ...

]]> L’idée est de ne plus accéder au backend de notre site web en utilisant backend.php dans l’url, mais de passer par un sous domaine.

  • http://www.super-website.com → frontend
  • http://admin.super-website.com → backend

Supposons que mon projet Symfony se trouve dans /home/public_html/.
Commençons par ajouter un vhost pour définir le sous domaine dans Apache. On précise au sous domaine que le fichier index pour ce sous domaine sera backend.php à l’aide de la directive DirectoryIndex.

?View Code CONSOLE
<VirtualHost *:80>
  ServerName admin.super-website.fr
  DocumentRoot "/home/public_html/web"
  DirectoryIndex backend.php
 
  <Directory "/home/public_html/web">
    AllowOverride All
    Allow from All
  </Directory>
 
  Alias /sf /home/public_html/lib/vendor/symfony/data/web/sf
  <Directory "/home/public_html/lib/vendor/symfony/data/web/sf">
    AllowOverride All
    Allow from All
  </Directory>
</VirtualHost>

Ensuite il faut modifier le .htaccess de Symfony afin qu’il redirige les requêtes http du sous domaine vers le fichier backend.php.

?View Code CONSOLE
Options +FollowSymLinks +ExecCGI
 
<IfModule mod_rewrite.c>
  RewriteEngine On
 
  # uncomment the following line, if you are having trouble
  # getting no_script_name to work
  #RewriteBase /
 
  # we skip all files with .something
  #RewriteCond %{REQUEST_URI} \..+$
  #RewriteCond %{REQUEST_URI} !\.html$
  #RewriteRule .* - [L]
 
  # we check if the .html version is here (caching)
  RewriteRule ^$ index.html [QSA]
  RewriteRule ^([^.]+)$ $1.html [QSA]
 
  # redirect to the backend web controller
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{HTTP_HOST}  ^admin.*
  RewriteRule ^(.*)$ backend.php [QSA,L]
 
  # no, so we redirect to our front web controller
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteRule ^(.*)$ index.php [QSA,L]
</IfModule>

Au niveau de la config Symfony, nous pouvons maintenant masquer le nom du script dans les urls du backend:

?View Code CONSOLE
# apps/backend/config/settings.yml
prod:
  .settings:
    no_script_name:    true
    ...

Et pour finir ne pas oublier de vider le cache =), le backend est maintenant accessible sur http://admin.super-website.com.

]]> http://www.lexik.fr/blog/symfony/symfony/utilisation-de-vhost-pour-lacces-au-backend-1307/feed 5 Retour sur le plugin Commentaires, partie administration http://www.lexik.fr/blog/symfony/non-classe/retour-sur-le-plugin-commentaires-partie-administration-1087 http://www.lexik.fr/blog/symfony/non-classe/retour-sur-le-plugin-commentaires-partie-administration-1087#comments Wed, 31 Mar 2010 08:39:13 +0000 Nikaw http://www.lexik.fr/blog/symfony/?p=1087 ...

]]> J’espère que vous vous souvenez du post concernant le plugin / behavior sfLexikDoctrineActAsCommentablePlugin.
Je vous avais promis une deuxième partie sur l’administration des commentaires, et bien après quelques mois d’absence me revoilà pour tenir ma promesse.

Tout d’abord un peu de configuration, puis nous verront quelles sont l’utilité et la problématique principales de cette partie.
Nous verrons l’administration des commentaires dans leur ensemble, puis la gestion des commentaires depuis l’objet porteur.

Configuration
Tout d’abord il ne faut pas oublier de charger le module dans les settings.
apps/backend/config/settings.yml :

?View Code YAML
all:
  .settings:
    enabled_modules: [..., comment]

Problématique

On veut ici pouvoir gérer facilement et rapidement les commentaires déposés par les utilisateurs.
Une des problématiques sera donc la façon de lister les commentaires sur l’index.
J’ai choisi par défaut de regrouper les commentaires par type d’objet, puis par objet, puis par date de modification.

Exemple : je liste tous les commentaires déposé sur les objets Message, je les regroupe par message, et je les classe par date de modification (la plupart du temps, un commentaire ne pouvant être modifié, on aura une concordance entre la date d’ajout et la date de modification).

Pour ceci, je spécifie dans le fichier de génération la méthode utilisée pour récupérer les commentaires :
plugins/sfLexikDoctrineActAsCommentablePlugin/module/comment/config/generator.yml :

?View Code YAML
generator:
  config:
    list:
      table_method: retrieveBackendCommentList

La méthode en question :
plugins/sfLexikDoctrineActAsCommentablePlugin/lib/model/doctrine/PluginCommentTable.class.php :

?View Code PHP
  public function retrieveBackendCommentList()
  {
    $query = $this->createQuery('c')
            ->orderBy('c.parent_class_name ASC')
            ->addOrderBy('c.parent_id ASC')
            ->addOrderBy('c.updated_at DESC');
 
    return $query;
  }

Nous allons maintenant nous pencher sur les différents traitements que je propose.
Il s’agit ici de publier / censurer, marquer comme spam / non spam, nettoyer les spams, et bien sûr supprimer des commentaires.

Tout d’abord je vous donne la configuration que j’ai choisie pour l’index, évidemment vous pouvez choisir de la changer, elle représente mes préférences rapportées au projet pour lequel j’ai créé ce plugin.
plugins/sfLexikDoctrineActAsCommentablePlugin/module/comment/config/generator.yml :

?View Code YAML
generator:
  class: sfDoctrineGenerator
  param:
    model_class:           Comment
    theme:                 admin
    non_verbose_templates: true
    with_show:             false
    singular:              ~
    plural:                ~
    route_prefix:          comment
    with_doctrine_route:     1
 
    config:
      actions: ~
      fields:
      list:
        table_method: retrieveBackendCommentList
        display: [author_name, author_mail, text, is_published, is_spam]
        fields:
          author_name: {label: 'Nom auteur'}
        actions:
          _delete: ~
          CleanSpam: {label: 'Nettoyer les spams'}
        object_actions:
          Publish: {label: 'Publier'}
          UnPublish: {label: 'Censurer'}
          MakeSpam: {label: 'Spam !'}
          UnmakeSpam: {label: 'Pas spam'}
          _delete: ~
        batch_actions:
          _delete: ~
          Publish: {label: 'Publier'}
          UnPublish: {label: 'Censurer'}
          MakeSpam: {label: 'Marquer comme spams'}
          UnmakeSpam: {label: 'Retirer des spams'}
      filter: ~
      form: ~
      edit: ~
      new:     ~

Laissez moi maintenant vous décrire rapidement chaque méthode :
Publish: {label: ‘Publier’}
permet d’afficher un commentaire

UnPublish: {label: ‘Censurer’}
permet de censurer un commentaire, c’est à dire de bloquer sa publication

MakeSpam: {label: ‘Spam !’}
permet de marquer un commentaire en tant que spam

UnmakeSpam: {label: ‘Pas spam’}
permet de marquer un commentaire en tant que non spam

Ces méthodes dans la « list » s’appliquent sur un seul commentaire, et dans le « batch » sur un groupe de commentaires sélectionnés.

La méthode CleanSpam: {label: ‘Nettoyer les spams’} quant à elle permet de supprimer d’un coup tous les commentaires notifiés comme étant des spams.

Voici le code des méthodes ci-dessus :
plugins/sfLexikDoctrineActAsCommentablePlugin/modules/comment/actions/actions.class.php :

?View Code PHP
public function executeListCleanSpam(sfWebRequest $request)
  {
    $nb = Doctrine::getTable('Comment')->cleanSpam();
 
    if ($nb)
    {
      $this->getUser()->setFlash('notice', sprintf('%d spam'.($nb > 1 ? 's' : '').' supprimé'.($nb > 1 ? 's' : ''), $nb));
    }
    else
    {
      $this->getUser()->setFlash('notice', 'Pas de spams.');
    }
 
    $this->redirect('@comment');
  }
 
  public function executeListPublish(sfWebRequest $request)
  {
    $page = $request->getParameter('page', 1);
 
    $this->comment = $this->getRoute()->getObject();
    $this->comment->setIsPublished(true);
    $this->comment->save();
 
    $this->redirect('@comment?page='.$page);
  }
 
  public function executeListUnPublish(sfWebRequest $request)
  {
    $page = $request->getParameter('page', 1);
 
    $this->comment = $this->getRoute()->getObject();
    $this->comment->setIsPublished(false);
    $this->comment->save();
 
    $this->redirect('@comment?page='.$page);
  }
 
  public function executeListMakeSpam(sfWebRequest $request)
  {
    $page = $request->getParameter('page', 1);
 
    $this->comment = $this->getRoute()->getObject();
    $this->comment->setIsSpam(true);
    $this->comment->save();
 
    $this->redirect('@comment?page='.$page);
  }
 
  public function executeListUnmakeSpam(sfWebRequest $request)
  {
    $page = $request->getParameter('page', 1);
 
    $this->comment = $this->getRoute()->getObject();
    $this->comment->setIsSpam(false);
    $this->comment->save();
 
    $this->redirect('@comment?page='.$page);
  }
 
  public function executeBatchPublish(sfWebRequest $request)
  {
    $page = $request->getParameter('page', 1);
 
    $ids = $request->getParameter('ids');
    foreach($ids as $id)
    {
      $this->comment = Doctrine::getTable('Comment')->find($id);
      $this->comment->setIsPublished(true);
      $this->comment->save();
    }
 
    $this->redirect('@comment?page='.$page);
  }
 
  public function executeBatchUnPublish(sfWebRequest $request)
  {
    $page = $request->getParameter('page', 1);
 
    $ids = $request->getParameter('ids');
    foreach($ids as $id)
    {
      $this->comment = Doctrine::getTable('Comment')->find($id);
      $this->comment->setIsPublished(false);
      $this->comment->save();
    }
 
    $this->redirect('@comment?page='.$page);
  }
 
  public function executeBatchMakeSpam(sfWebRequest $request)
  {
    $page = $request->getParameter('page', 1);
 
    $ids = $request->getParameter('ids');
    foreach($ids as $id)
    {
      $this->comment = Doctrine::getTable('Comment')->find($id);
      $this->comment->setIsSpam(true);
      $this->comment->save();
    }
 
    $this->redirect('@comment?page='.$page);
  }
 
  public function executeBatchUnmakeSpam(sfWebRequest $request)
  {
    $page = $request->getParameter('page', 1);
 
    $ids = $request->getParameter('ids');
    foreach($ids as $id)
    {
      $this->comment = Doctrine::getTable('Comment')->find($id);
      $this->comment->setIsSpam(false);
      $this->comment->save();
    }
 
    $this->redirect('@comment?page='.$page);
  }

et la méthode cleanSpam() dans le modèle :
plugins/sfLexikDoctrineActAsCommentablePlugin/lib/model/doctrine/PluginCommentTable.class.php :

?View Code PHP
  /**
   * supprime tous les commentaires classifiés comme spam et retourne le nombre d'enregistrements supprimés
   *
   * @return int
   */
  public function cleanSpam()
  {
    $q = $this->createQuery('c')->delete()->where('c.is_spam = ?', true);
 
    return $q->execute();
  }

Je n’ai pas touché au filtre, mais chacun peut décider que tel ou tel champ sera utile ou pas, ça dépendra très souvent du projet.

Donc voilà pour la première étape. Jusque là on peut afficher et traiter les commentaires un par un ou par lots, directement depuis leur index.

Voyons maintenant comment ajouter la gestion des commentaires depuis les objets porteurs.
Attention, cette partie est une nouveauté par rapport au premier post, voici les nouvelles sources : plugin.

Tout d’abord il faut ajouter dans l’édition de l’objet porteur le partial qui permettra de gérer les commentaires.
Pour éviter de devoir dupliquer le même template pour chaque type d’objet, on va créer un partial dans le module comment du plugin puis l’appeler dans le partial de l’objet porteur :
/home/lexik/sfprojects/kelsms/plugins/sfLexikDoctrineActAsCommentablePlugin/modules/comment/templates/_backend_comments_list.php :

?View Code PHP
<div class="container_16">
  Commentaires :
<ul class="order">
    $comment): ?>
	<li id="<?php echo $comment->getId() ?>" class="row_<?php echo $key%2 ?>">
<div id="show_<?php echo $comment->getId() ?>" class="grid_10">
          $comment)) ?></div>
<div class="grid_4">
          $comment)) ?></div></li>
</ul>
</div>
<script type="text/javascript"><!--mce:0--></script>

Il sera appelé de la manière suivant dans le partial de notre objet, par exemple ici un Message, grâce à la configuration du generator.yml :

?View Code YAML
generator:
  config:
      edit:
        display: [..., _handle_comments]

apps/backend/modules/message/template/_handle_comments.php :

?View Code PHP
$form->getObject()->findComments())) ?>

Bref.
Dans le partial _backend_comments_list.php on remarque 3 choses :
1) l’appel du partial backend_show
2) l’appel du partial backend_comment_actions
3) les fonctions javascript

1) le partial backend_show affiche tout simplement le contenu du commentaire :
_backend_show.php

?View Code PHP
<div class="show_comment_class">
<div class="infos_class">
    <span class="author_name_class">
      getAuthorName() ?>
    </span>
 
    <span class="time_and_date_class">
      - le <span class="date_class">getCreatedAt(), 'd/MM/yyyy', 'fr') ?></span>
      à <span class="time_class">getCreatedAt(), 'hh:mm', 'fr') ?></span>
    </span></div>
<hr />
<div class="text_class">
    getText() ?></div>
</div>

2) le partial _backend_comment_actions.php contient les actions pouvant être effectuées sur un commentaire :

?View Code PHP
<a onclick="publishComment(<?php echo $comment->getId()?>)" href="#">publier</a> |
<a onclick="unPublishComment(<?php echo $comment->getId()?>)" href="#">censurer</a> |
<a onclick="makeSpamComment(<?php echo $comment->getId()?>)" href="#">spam</a> |
<a onclick="unMakeSpamComment(<?php echo $comment->getId()?>)" href="#">pas spam</a> |
<a onclick="deleteComment(<?php echo $comment->getId()?>)" href="#">supprimer</a> |
<a href="<?php echo url_for('@comment_edit?id='.$comment->getId()) ?>">editer</a>

3) les fonctions javascript : elles permettent d’appeler respectivement les méthodes permettant d’effectuer les actions correspondante, tout ça en AJAX.

Ces différentes actions vont effectuer le même travail que les ListAction, à la différence près qu’elle sont appelée en Ajax, et n’ont donc pas le même template de retour.

Voilà d’abord le routing, puis les actions :

?View Code YAML
comment_ajax_publish:
  url:   /comment_ajax_publish
  params: {module: comment, action: ajaxPublish}
comment_ajax_unpublish:
  url:   /comment_ajax_unpublish
  params: {module: comment, action: ajaxUnPublish}
comment_ajax_makespam:
  url:   /comment_ajax_markspam
  params: {module: comment, action: ajaxMakeSpam}
comment_ajax_unmakespam:
  url:   /comment_ajax_unmarkspam
  params: {module: comment, action: ajaxUnMakeSpam}
comment_ajax_delete:
  url:   /comment_ajax_delete
  params: {module: comment, action: ajaxDelete}

actions :

?View Code PHP
  public function executeAjaxPublish(sfWebRequest $request)
  {
    $this->comment = Doctrine::getTable('Comment')->find($request->getParameter('id'));
    $this->forward404Unless($this->comment);
    $this->publish($this->comment);
 
    $this->setTemplate('ajaxAction');
  }
 
  public function executeAjaxUnPublish(sfWebRequest $request)
  {
    $this->comment = Doctrine::getTable('Comment')->find($request->getParameter('id'));
    $this->forward404Unless($this->comment);
    $this->unpublish($this->comment);
 
    $this->setTemplate('ajaxAction');
  }
 
  public function executeAjaxMakeSpam(sfWebRequest $request)
  {
    $this->comment = Doctrine::getTable('Comment')->find($request->getParameter('id'));
    $this->forward404Unless($this->comment);
    $this->makespam($this->comment);
 
    $this->setTemplate('ajaxAction');
  }
 
  public function executeAjaxUnMakeSpam(sfWebRequest $request)
  {
    $this->comment = Doctrine::getTable('Comment')->find($request->getParameter('id'));
    $this->forward404Unless($this->comment);
    $this->unmakespam($this->comment);
 
    $this->setTemplate('ajaxAction');
  }
 
  public function executeAjaxDelete(sfWebRequest $request)
  {
    $this->comment = Doctrine::getTable('Comment')->find($request->getParameter('id'));
    $this->forward404Unless($this->comment);
 
    $this->comment->delete();
  }
 
  protected function publish($comment)
  {
    $comment->setIsPublished(true);
    $comment->save();
  }
  protected function unpublish($comment)
  {
    $comment->setIsPublished(false);
    $comment->save();
  }
  protected function makespam($comment)
  {
    $comment->setIsSpam(true);
    $comment->save();
  }
  protected function unmakespam($comment)
  {
    $comment->setIsSpam(false);
    $comment->save();
  }

On remarque une certaine redondance de code dans le actions.class.php,c’est pour ça que j’ai factorisé. Pensez à corriger les autres actions (elles sont ok si vous récupérez les sources).

Et pour finir, dans les templates correspondant à ces actions, on reload la ligne du commentaire en cours, ce qui permettra de mette à jour ses état de publication et spam dans la liste des commentaires.

ajaxActionSuccess.php :

?View Code PHP
include_partial('comment/backend_show', array('comment'=>$comment))

Voilà, si vous avez des questions ou des incompréhensions, n’hésitez pas !

]]> http://www.lexik.fr/blog/symfony/non-classe/retour-sur-le-plugin-commentaires-partie-administration-1087/feed 3 Réflexions sur l’élaboration d’un bon backend http://www.lexik.fr/blog/symfony/symfony/12x/reflexions-sur-lelaboration-dun-bon-backend-958 http://www.lexik.fr/blog/symfony/symfony/12x/reflexions-sur-lelaboration-dun-bon-backend-958#comments Wed, 30 Sep 2009 08:00:20 +0000 Calu http://www.lexik.fr/sfblog/?p=958 ...

]]> Lors de la réalisation de vos projets, l’étape de la construction du backend est devenue un passage obligatoire. Que cela soit un souhait initial du client ou une envie de pouvoir proposer une prise en main du site via une interface, le backoffice justifie pleinement sa présence et son importance. Cette philosophie est très largement soutenue par Symfony avec son générateur CRUD d’admin, ses filters, l’extensibilité de ses templates, l’internationalisation…

Le but de cet article est de chercher plus loin dans les fonctionnalités de base proposées par Symfony pour l’élaboration de notre backend.

La Homepage

Proposer à l’administrateur l’affichage d’une page de listing d’un modèle, dès le login effectué, est bien sûr une mauvaise idée. Une page d’accueil doit être présente et peut présenter les différentes informations pertinentes et vitales pour l’administrateur :

Accueil du backoffice : Statistiques et accés

Accueil du backoffice : Statistiques et accés

Dans cette capture, l’accueil permet dès l’authentification, de connaitre les différentes statistiques du site et d’avoir un accés direct aux actions redondantes mais nécessaires : Utilisateurs en attente de validation, Visualisation de messages suspects etc…

Pour aller plus loin, vous pouvez afficher certaines indications propres à la fréquentation sur votre site. Si vous possédez un compte Google Analytics, c’est l’occasion d’en profiter ! En effet, une API pour accéder à ses statistiques est disponible depuis peu, et devinez quoi ? Il existe un plugin Symfony pour l’utiliser : sfGoogleAnalyticsPlugin. Alors plus d’excuses pour ne plus proposer une page d’accueil efficace à votre client.

Un listing précis et concis

Par défault, Symfony propose un listing complet des différents champs de votre modèle. Cela est souvent beaucoup trop confus et non adapté pour les besoins d’un client :

Mauvais listing

Il apparait comme essentiel de sélectionner et de renommer les différentes colonnes de votre modèle que vous souhaitez afficher. De même, selon la complexité de votre objet, il peut être intéressant de fournir des informations « associées » : Pour un objet Article de Blog, il est pertinent d’afficher le nombre de Commentaires associés. Dans mon cas, j’affiche le nombre d’utilisateurs associés à un projet :

listing

Concernant les valeurs, il est déconseillé d’utiliser des IDs. Ils apportent aucune information quantitative ou qualitative pour l’administrateur. De plus, il est préférable de créer une action pour les tâches répétitives. Cela simplifie grandement l’administration pour un client et on évite ainsi de l’envoyer directement sur les pages d’éditions.

La documentation de Symfony étant très complète sur ce sujet, nous allons continuer notre tour d’horizon avec les filters.

Les filtres au service de la navigation

Symfony permet à l’aide du générateur d’administration, de trier vos modèles en fonction de filtres spécifiques. Mais comme pour la partie précédente, les problèmes sont similaires : Trop de champs renseignables, souvent complexes et non traduits. Outre la documentation de Symfony qui vient encore une fois à notre aide, il faudra faire un tour sur cet article pour compléter la traduction des filtres sur le backend.

Mais la véritable force des filtres, c’est leur utilisation de manière transparente par le client. En effet, si on reprend l’exemple de notre page d’accueil, on propose un lien « 3 projets en attente » sensé rediriger sur les projets concernés.

Comment cela est-il possible ?

Tout simplement en créant le filtre qui nous permet de trier nos projets, dès le chargement de la page. La manière la plus simple est de passer nos filtres dans l’URL.

Mise en place

Il faut d’abord surcharger notre action index du module concerné :

?View Code PHP
    public function executeIndex(sfWebRequest $request) {
        if($request-&gt;getParameter('filter')) {
            $this-&gt;setFilters($request-&gt;getParameter('filter'));
        }
        parent::executeIndex($request);
    }

On vérifie si l’on passe un paramètre « filter » lors du chargement de la page. Le cas échéant, on applique les filtres renseignés.

Mon lien permettant de voir seulement les utilisateurs en attente de validation aura le routing :

?View Code PHP
@user_user?filter[is_active]=0

Pour mes projets en attente de validation, c’est la pratiquement la même chose, on indique en plus le type de l’argument.

?View Code PHP
@project_project?filter[state][text]=1

Pensez à bien regarder la structure de vos filtres en cas d’erreur.

Allez plus loin

Maintenant que vous savez filtrer directement à partir d’un lien, vous allez pouvoir vous servir de cette astuce autre part que sur la page d’accueil. Revenons sur nos listing. Nous avons vu qu’il était pratique pour le client d’afficher par exemple le nombre d’objet Commentaire associés à un objet Article. Nous sommes maintenant capables de rediriger directement vers les objets associés.

On ajoute une méthode d’affichage sur notre objet Article :

?View Code PHP
    public function getCountPositioning() {
        return link_to($this-&gt;getComments()-&gt;count(),'@comment_comment?filter[article_id]='.$this-&gt;Id());
    }

On retourne ainsi le lien contenant le filtre permettant de trier les commentaires en fonction de l’ID de l’article. Il suffit de modifer notre action index afin de correctement afficher notre entité HTML :

?View Code PHP
    public function executeIndex(sfWebRequest $request) {
        sfConfig::set('sf_escaping_strategy', false);
        if($request-&gt;getParameter('filter')) {
            $this-&gt;setFilters($request-&gt;getParameter('filter'));
        }
        parent::executeIndex($request);
    }

Voilà pour nos petites idées pour vous aider à parfaire votre back office. N’hésitez pas à parlez de vos astuces dans les commentaires.

Mise à jour

La désactivation de la stratégie d’échappement des caractères (sfConfig::set(‘sf_escaping_strategy’, false)) est utilisée pour éviter l’affichage des balises <a> obtenues depuis notre modèle. Cette méthode à deux limites : D’une part, elle est inhérente à certaines failles de sécurité provoquées par une injection de code malicieux (cf commentaire de @Niko) ; D’autre part, on perd l’avantage lié à notre MVC en faisant parvenir le lien directement depuis le modèle.

Il est alors conseillé de déclarer dans notre generator.yml l’utilisation des partials pour afficher nos liens filtrants :

?View Code PHP
display: [_countComments]

Il suffit alors de créer notre partial _countComments.php dans le dossier templates/ de notre module :

?View Code PHP
&lt;?php echo link_to($article-&gt;getComments()-&gt;count(), '@comments_comments?filter[article_id]='.$article-&gt;getId());?&gt;
]]> http://www.lexik.fr/blog/symfony/symfony/12x/reflexions-sur-lelaboration-dun-bon-backend-958/feed 7