Le cas de conflit le plus flagrant est certainement le app/console cache:clear qui renvoie une erreur car le cache a été généré par www-data lors du chargement du site par apache. Le bon gros sudo rm -rf app/cache/* n’est pas une solution acceptable, tout juste une rustine.

Il existe différents moyens d’éviter ces conflits, que ce soit via scripts personnalisés, configurations avancées, ou packages additionnels. SuPHP est un module pour Apache très facile à mettre en place pour un environnement de « dev », et il va répondre à notre problème d’une manière très simple: Apache ne va plus éxécuter les sites via ‘www-data’, mais via l’utilisateur propriétaire des fichiers éxécutés, c’est-à-dire le plus souvent le compte du développeur.

L’installation comprend deux packages dispos sur synaptic ou directement depuis la console:

sudo apt-get install suphp-common libapache2-mod-suphp

Pour une station de dev, une configuration fonctionnelle et simple est très bien décrite sur http://doc.ubuntu-fr.org/suphp#installation_de_suphp. Cette configuration empêche l’intervention de suphp dans les répertoires de /usr/share pour permettre entre autres à phpmyadmin (dans son emplacement par défaut) de continuer à fonctionner sans problèmes.

Il faudra éventuellement supprimer les fichiers de sessions en cours appartenent encore à www-data (dans /var/lib/php5 par défaut).

Si vos projets ne sont pas stockés dans les répertoires /var/www ou ~/public_html, il faut éditer la valeur de « docroot » dans /etc/suphp/suphp.conf pour y ajouter les répertoires supplémentaires. Par exemple, mes projets sont dans ~/www/ :

docroot=/var/www:${HOME}/public_html

devient alors:

docroot=/var/www:${HOME}/public_html:${HOME}/www

Pensez à nettoyer vos fichiers appartenant encore à www-data (cette fois avec des sudo rm par contre), comme les répertoires cache et logs, et redémarrez simplement Apache (sudo service apache2 restart). Après ça vous ne devriez plus voir de www-data dans vos projets, et vous pourrez oublier ce mauvais réflexe du sudo rm -rf à tout bout de champ !

La gestion des expéditions de mails dans les projets Web est souvent laborieuse. En effet, les serveurs ne sont pas toujours bien configurés pour ça. Il arrive que les emails partent en spam ou encore qu’ils soient bloqués avant même d’entrer dans la boite mails des utilisateurs… Bref, c’est jamais pratique et le suivi se fait très difficilement.

Quelques services d’envoi :

La solution réside bien souvent dans le fait de déporter l’expédition sur une plateforme spécialisée. Il en existe des dizaines :
Amazon a récemment sorti une plateforme Amazon SES qui permet d’expédier ses emails via un simple appel à une API. Cette solution est très pratique mais a pour inconvénient de changer un peu le processus d’envoi d’email, il faudra donc faire quelques adaptations dans le code de votre application.
Il existe également d’autres solutions :

• MailChimp : http://www.mailchimp.com/
• Campaign Monitor : http://www.campaignmonitor.com/
• AWeber : http://www.aweber.com/

pour en citer quelques uns…

Ces solutions sont idéales pour gérer des newsletters mais sont contraignantes pour les emails transactionnels. Eh oui, il faut souvent se rendre sur l’interface du site pour faire ses expéditions ou tout traiter via leur API.

Une solution intéressante : Mailjet

Les emails de vos projets Web sont souvent délivrés via un serveur SMTP, Mailjet est un service en ligne qui a eu la bonne idée de proposer d’exploiter un serveur SMTP authentifié et donc optimisé pour assurer la délivrabilité des emails. L’autre avantage indéniable de cette solution est qu’il suffit de changer les paramètres du SMTP de votre application et le tour est joué, vos emails sont délivrés par Mailjet. En prime Mailjet vous propose un système de statistiques sur les expéditions que vous pouvez consulter sur leur plateforme ou encore interroger à distance, via leur API.

Nous avons testé cette solution sur un projet pour envoyer des mails transactionnels tels que des mails d’inscriptions, de notifications ainsi qu’une newsletter hebdomadaire. Mailjet propose plusieurs offres dont une gratuite permettant d’envoyer jusqu’à 6000 mails par mois ce qui dans notre cas était suffisant.

Exemple de configuration du SMTP :

# apps/<app_name>/config/factories.yml
prod:
  mailer:
    param:
      transport:
        class: Swift_SmtpTransport
        param:
          host:       in.mailjet.com
          port:       465
          encryption: ssl
          username:   "your-username"
          password:   "your-pass"

Une fois cette petite configuration faite vos mails seront délivrés par le SMTP de Mailjet qui s’occupe d’envoyer vos mails et qui fera aussi en sorte de limiter les risques de non livraison des mails.

PS : Non, non, non ce billet n’est pas sponsorisé! C’est juste que cette solution est vraiment pratique et souhaitions la partager.

Voici les différents notifiers que nous proposons :

• stockage en base de données (celle par défaut, ou via un dsn personnalisé) ;
• stockage en fichier XML ;
• stockage en fichier de log classique (fichier texte) ;
• notification via un envoi de mail ;
• notification via Hoptoad, un webservice de log d’erreur.

Le plugin va par défaut logger toutes les exceptions levées, par contre pour les erreurs PHP il est évidement possible de configurer l’error_reporting, ce qui permet de remonter seulement les erreurs et non les notices par exemple. La configuration du plugin se fait tout simplement dans le fichier app.yml de votre application (ou du projet). Chaque « notifier » possède ses propres options, pour plus de détail je vous invite à regarder le README du plugin.

Voici par exemple une capture d’écran d’un email envoyé par lxErrorLoggerPlugin :

Comme il a été précisé en introduction, lxErrorLoggerPlugin permet de notifier les erreurs mais également de les stocker. Le stockage se fait via une base de données ou un fichier XML. Cela apporte 2 avantages indéniables :

• la possibilité de repérer des erreurs similaires à d’autres, il est alors possible de prévenir les notifiers tels que le notifier email pour ne pas envoyer un email doublon, tout ceci est configurable ;
• la possibilité de générer un flux RSS des erreurs, l’URL du flux sera protégé par un token paramètrable par vos soins.

Exemple d’utilisation :

Supposons que nous avons besoin de logger les erreurs qui se produisent sur notre application frontend.

1. Activer le plugin :

// config/ProjectConfiguration.class.php
  public function setup()
  {
    $this->enablePlugins(array(
      ...,
      'lxErrorLoggerPlugin',
    ));
  }

2. Configurer le plugin dans l’application souhaité, frontend dans cet exemple :
Ici nous allons utiliser la notification des erreurs en base de données et par email.

# apps/frontend/config/app.yml
all:
  lx_error_logger_plugin:
    enabled:              true # Enable error notification
    php_error_reporting:  <?php echo (E_ALL | E_STRICT)."\n" ?>
    rss:
      token:              264864156479631564841687 # token to access to the rss
      items:              10 # items in the rss
    notifier:
      db:
        enabled:          true
        options:
          similar_error:  true
      mail:
        enabled:          true
        options:
          to:             [bob@example.com, chuck@example.com]
          subject:        A new error occured on your website
          always_send:    true # always send an email even if db or xml notifiers detect the error as similar

3. Activer le flux RSS des dernières erreurs :
Dans cet exemple la notification des erreurs en base de données est activée donc le flux RSS peut récupérer des données.

# apps/frontend/config/settings.yml
all:
  .settings:
    enabled_modules: [..., lxErrorNotifierRss]

Le flux RSS est maintenant accessible avec l’url :

http://super-website.com/lx-error/rss.xml?token=264864156479631564841687

Et c’est tout

Note : le plugin ne fournit aucune interface permettant de lister les erreurs loggées, libre à chacun de créer son CRUD, module d’admin generator ou autre interface comme il le souhaite en fonction du besoin.

Dépôt du plugin sur Github : https://github.com/lexik/lxErrorLoggerPlugin.

L’installation du plugin est très rapide:

• téléchargez les sources sur Github dans le répertoire plugins de votre projet,
• éditez le fichier config/settings.yml pour y inclure le helper lxJavascript:
  ^?View Code YML

  all: .settings: standard_helpers: [ ... , lxJavascript ]

Et c’est tout! Voyons maintenant le fonctionnement.

Le premier but du plugin est de solutionner les problèmes de granularité du code Javascript dans un projet Symfony. Lorsque l’on utilise par exemple des widgets JQuery, des partials pour les réseaux sociaux, ou des composants pour des GoogleMap, on se retrouve vite avec du code Javascript éparpillé dans tout notre projet, et par conséquent tout autant éparpillé dans le code des pages générées.

Pour régler ce problème lxJavascriptPlugin propose un premier outil: le helper lxJavascriptHelper. Son utilisation est très similaire à celle du javascriptHelper de Symfony, mais avec la méthode lx_javascript:

• pour inclure un fichier source externe à la page:
  ^?View Code PHP

  <?php lx_javascript('http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js') ?>

• pour inclure directement du code javascript, par exemple le bout de code pour Google Analytics, le fonctionnement est similaire à celui d’un slot:
  ^?View Code PHP

  <?php lx_javascript() ?> var _gaq = _gaq || []; _gaq.push(['_setAccount', '*********']); _gaq.push(['_trackPageview']); (function() { var ga = document.createElement('script'); ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js'; ga.setAttribute('async', 'true'); document.documentElement.firstChild.appendChild(ga); })(); <?php lx_end_javascript() ?>

  Ici la balise <script> n’est pas nécessaire, mais vous pouvez l’utiliser si vous le souhaitez (par exemple pour garder la coloration syntaxique de votre IDE)

• pour insérer tout le code javascript déclaré via lx_javascript() à la fin de votre layout.php:
  ^?View Code HTML

  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> ... </head> <body> ... <?php lx_include_javascripts() ?> </body> </html>

Le soucis de javascript dans les templates est adressé. Reste maintenant le problème du code javascript inséré via d’autres moyens, comme par exemple un widget qui utilise JQuery. Pour cela lxJavascriptPlugin propose une classe statique lxJavascriptStorage qui offre les fonctionnalités du helper depuis n’importe où dans votre code:

• pour ajouter une source externe:
  ^?View Code PHP

  lxJavascriptStorage::addRemoteJavascript('http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js');

• pour ajouter du code javascript. Voyons par exemple la méthode render() du widget sfWidgetFormJQueryDate:
  ^?View Code PHP

  public function render($name, $value = null, $attributes = array(), $errors = array()) { //code return $this->getOption('date_widget')->render($name, $value, $attributes, $errors). $this->renderTag('input', array('type' => 'hidden', 'size' => 10, 'id' => $id = $this->generateId($name).'_jquery_control', 'disabled' => 'disabled')). sprintf(<<<EOF <script type="text/javascript">// <![CDATA[ [...] // ]]></script> EOF , //arguments du sprintf ); }

  Nous voyons bien le javascript retourné dans le code du widget, et donc en milieu de page. Cette fonction render() pourrait, avec lxJavascriptPlugin, ressembler à ça:

  ^?View Code PHP

  public function render($name, $value = null, $attributes = array(), $errors = array()) { //code </code>   $js = sprintf(<<<EOF <script type="text/javascript">// <![CDATA[ [...] // ]]></script> EOF , //arguments du sprintf ); lxJavascriptStorage::addJavascriptCode($js);   return $this->getOption('date_widget')->render($name, $value, $attributes, $errors). $this->renderTag('input', array('type' => 'hidden', 'size' => 10, 'id' => $id = $this->generateId($name).'_jquery_control', 'disabled' => 'disabled')); }

  Peu de changements, mais ici le javascript sera rendu avec tout le reste du javascript en pied de page.

Notez enfin que la méthode lx_include_javascripts() rendra en premier les sources externes, puis le code javascript concaténé dans une unique balise <script>. Si tous les exemples précédents sont utilisés dans une application, le javascript en pied de page donnera ceci:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js" type="text/javascript"></script>
<script type="text/javascript">// <![CDATA[
  //javascript du widget
 
  var _gaq = _gaq || [];
  _gaq.push(['_setAccount', '*********']);
  _gaq.push(['_trackPageview']);
  (function() {
    var ga = document.createElement('script');
    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
    ga.setAttribute('async', 'true');
    document.documentElement.firstChild.appendChild(ga);
})();
/* ]]> */</script>

Vous pouvez obtenir lxJavascriptPlugin sur Github.

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 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 :

• sfCombinePlugin
• npAssetsOptimizerPlugin
• swCombinePlugin

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.

4. Javascript depuis les widget

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 :

  ExpiresActive on
  ExpiresByType text/css "access plus 1 year"
  ExpiresByType text/javascript "access plus 1 year"

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.

Le but est juste de savoir comment faire pour avoir accès à l’event dispatcher depuis les classes du modèle, de manière à pouvoir lever des événements « métiers » qui permettent des traitements qui se rapprochent des trigger sql. L’avantage est de rester au sein de l’application symfony et ne pas disperser la logique. C’est une problèmatique que nous avons rencontré à plusieurs reprises dans les projets et nous avons pu trouver cette implementation grace à n1k0 de chez Akei.

(Pour la suite, je vais me servir d’une partie du modèle de Jobeet comme je l’avais fait dans mon post précédent)

A la base, l’event dispatcher se trouve dans le contexte, et donc accessible principalement depuis les actions des modules. L’idée est de le rendre accessible aux classes du modèle doctrine de manière à pouvoir notifier des événements « métier » directement depuis les méthodes. On va donc passer l’event dispatcher à la classe de base dont hérite toutes les classes du modèle. Ou plus exactement, on va rajouter une classe custom dans la pile d’héritage des classes du modèle.

On créé donc une classe CustomDoctrineRecord, que je place dans /lib/model/doctrine/record/CustomDoctrineRecord.class.php pour éviter qu’elle se retrouve noyée avec les classes du modèle. On va faire passer à cette classe l’event dispatcher par des méthodes statiques.
Les classes de base du modèle héritent de sfDoctrineRecord, il faut donc impérativement que la classe custom hérite elle aussi de sfDoctrineRecord.

Fichier : /lib/model/doctrine/record/CustomDoctrineRecord.class.php

<?php
 
abstract class CustomDoctrineRecord extends sfDoctrineRecord
{
  static protected $dispatcher = null;
 
  /**
   * Sets the EventDispatcher
   *
   * @param sfEventDispatcher $dispatcher 
   */
  static public function setEventDispatcher(sfEventDispatcher $dispatcher)
  {
    self::$dispatcher = $dispatcher;
  }
 
  /**
   * Returns the EventDispatcher
   *
   * @return sfEventDispatcher
   */
  static public function getEventDispatcher()
  {
    return self::$dispatcher;
  }
 
  /**
   * Returns if EventDispatcher is available
   *
   * @return boolean
   */
  static public function hasDispatcher()
  {
    return (self::getEventDispatcher() instanceOf sfEventDispatcher);
  }
}

Maintenant il faut spécifier à doctrine d’utiliser notre classe custom comme classe de référence des classes modèles, on utilise la méthode configureDoctrine() de sfProjectConfiguration. Aprés quoi on va avoir besoin de passer l’event dispatcher à notre classe. On va donc catcher l’événement « context.load_factories » qui est déclenché une fois que le contexte est initialisé pour aller initialiser la classe CustomDoctrineRecord.

Fichier : /config/ProjectConfiguration.class.php

<?php
 
require_once dirname(__FILE__).'/../lib/vendor/symfony/lib/autoload/sfCoreAutoload.class.php';
sfCoreAutoload::register();
 
class ProjectConfiguration extends sfProjectConfiguration
{
  public function setup()
  {
    parent::setup();
 
    $this->enablePlugins(array(
      'sfDoctrinePlugin',
    ));
 
    $this->dispatcher->connect('context.load_factories', array($this, 'listenToContextFactoriesLoaded'));
  }
 
  /**
   * Defines the base objects' classe
   */
  public function configureDoctrine(Doctrine_Manager $manager)
  {
    sfConfig::set('doctrine_model_builder_options', array(
      'baseClassName' => 'CustomDoctrineRecord'
    ));
  }
 
  /**
   * Objects can acces the EventDispatcher
   */
  public function listenToContextFactoriesLoaded(sfEvent $event)
  {
    CustomDoctrineRecord::setEventDispatcher($event->getSubject()->getEventDispatcher());
  }
}

Aprés ca, il nous reste à faire un petit

./symfony doctrine:build --all-classes

Et on peut vérifier l’inpact en ouvrant une classe de base, et on trouve bien que la classe hérite de notre classe CustomDoctrineRecord

Fichier : /lib/model/doctrine/base/BaseJobeetJob.class.php

<?php
...
abstract class BaseJobeetJob extends CustomDoctrineRecord
{
...

Il est donc maintenant possible de lever des événements depuis les classes du modèle. Pour exemple je vais lever un événement à l’insertion d’un nouveau Job. Cet événement pourra être utilisé par la suite pour faire ce que l’on veut, comme par exemple envoyer une email au modèrateur l’informant qu’un nouveau job a été saisi sur le site.

Fichier : /lib/model/doctrine/JobeetJob.class.php

<?php
 
class JobeetJob extends BaseJobeetJob
{
  /**
   * @param Doctrine_Event $event 
   */
  public function postInsert($event)
  {
    if (self::hasDispatcher())
    {
      if (self::getEventDispatcher()->hasListeners('JobeetJob.Inserted'))
      {
        self::getEventDispatcher()->notify(new sfEvent($this, 'JobeetJob.Inserted'));
      }
    }
  }
}

C’est un exemple tout simple, mais les possibilités sont immenses. Attention aux événements en cascades, ca peut très vite devenir un casse tête à debugger !

Dernier petit tips, pour pouvoir faire des tests de vos méthodes qui lèvent des événements : c’est à mis chemin entre les tests unitaires et les tests fonctionnels. J’ai voulu tester des enchainements de méthodes qui levaient des événements, et je voulais vérifier que les règles de gestion étaient respectées. Je suis donc parti du bootstap unitaire où j’ai initialisé un contexte que je passe à ma classe de base, de manière à ce que les événements soient diffusés.

Fichier : /test/bootstrap/unit_event.php

<?php
 
include(dirname(__FILE__).'/unit.php');
 
$configuration = ProjectConfiguration::getApplicationConfiguration('frontend', 'test', true);
$context = sfContext::createInstance($configuration);
CustomDoctrineRecord::setEventDispatcher($configuration->getEventDispatcher());

Quand on commence à utiliser les événements, il y a deux réactions possibles. Il y a les réfractaires qui disent « c’est null, ca sert a rien », soit on devient accro et on commence à en mettre de partout. Si vous faites parti du deuxième groupe, voici quelques conseils élémentaires mais important à respecter pour éviter que le debuggage se transforme en calvaire :

• mettre des noms d’événements explicites ;
• centraliser les écouteurs.

Bon codage à tous, et bonnes fêtes

• 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.

<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.

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:

# 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.

L’admin generator permet en une commande d’avoir un module complet et fonctionnel avec de nombreuses fonctionnalités, le tout relativement configurable. En contre partie, l’ajout de fonctionnalités spécifiques et la mise en forme peuvent rapidement s’avérer fastidieuses. Être obligé d’aller fouiller dans le cache pour aller faire des copier/coller afin de pouvoir surcharger une action, c’est comme qui dirait, bien mais pas top…

D’autre part le CRUD permet lui aussi de générer en une seule commade un module, mais ce module est plus que limité et on se retrouve systématiquement à ré-implémenter les mêmes fonctionnalités de base comme le pager, les filters, etc. Par contre travailler avec un CRUD permet de garder la main sur le code, ce qui n’est pas négligeable.

C’est pourquoi je vous propose de voir comment fabriquer un thème pour le CRUD de manière à l’enrichir de quelques fonctionnalités indispensables pour ne pas avoir à les ré-écrire systematiquement et ainsi ganger du temps. Je vais en profiter pour développer ce thème au sein d’un plugin de manière à pouvoir s’en resservir facilement.

Pour se faire je vais partir d’un projet vierge type sandbox auquel je rajoute le plugin sfTaskExtraPlugin qui facilite grandement la génération de plugins.
Pour me simplifier la vie, je vais reprendre le schema.yml et les fixtures (affiliates.yml, category.yml et jobs.yml) de Jobeet pour avoir un modèle sur lequel m’appuyer pour les exemples.

(Attention le fichier de fixture category.yml comporte les traductions, alors que le schema n’a pas le behavior I18n. Il faut au choix modifier le schema.yml pour rajouter le behavior ou modifier les categories pour supprimer les traductions)

Un petit ./symfony doctrine:build –all –and-load et nous voilà parti.

Let’s rock!

Pour fabriquer un module de type CRUD symfony se sert de template de code pour générer les actions et les vues. Ces fichiers sont bien cachés au fin fond du symfony ! On les trouve dans

/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/data/generator/sfDoctrineModule/default

On va donc utiliser le thème par défaut que l’on va enrichir.

Tout d’abord, on va générer l’arborescence du plugin grâce à la commande generate:plugin de sfTaskExtraPlugin.

./symfony generate:plugin myCrudThemePlugin

Puis on prépare l’arborescence qui va accueillir les fichiers du template à l’intérieur du plugin.

mkdir -p plugins/myCrudThemePlugin/data/generator/sfDoctrineModule/myCrudTheme

Et on y copie tous les fichiers du thème par défaut.

cp -r lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/data/generator/sfDoctrineModule/default/* plugins/myCrudThemePlugin/data/generator/sfDoctrineModule/myCrudTheme

Si vous avez fait un checkout de symfony, les fichiers que vous avez copiés contiennent les informations de svn. Il faut nettoyer tout ça. Je vous propose une petite ligne de commande qui permet de faire ca.

find plugins/myCrudThemePlugin/data/generator/sfDoctrineModule/myCrudTheme -name .svn -exec rm -rf {} \;

Les fichiers sont prêts. A ce stade, on pourrait déjà générer un thème en utilisant notre thème. Il sufirait d’activer le plugin dans

/config/ProjectConfiguration.class.php

<?php
 
class ProjectConfiguration extends sfProjectConfiguration
{
  public function setup()
  {
    $this->enablePlugins(array(
      ...
      'myCrudThemePlugin',
    ));
  }
}

Et de lancer la commande :

./symfony doctrine:generate-module --theme="myCrudTheme" frontend job JobeetJob

Mais ne le faites pas ! :p Ca n’aurait pas un grand intérêt étant donné que l’on a rien changé par rapport au thème par défaut.

Nous allons commencer par rajouter un pager sur la page de listing. Il faut modifier l’action dans

/plugins/myCrudThemePlugin/data/generator/sfDoctrineModule/myCrudTheme/parts/indexAction.php

 
  public function executeIndex(sfWebRequest $request)
  {
    $query = Doctrine_Core::getTable('<?php echo $this->getModelClass() ?>')->createQuery('<?php echo strtolower(substr($this->getModelClass(), 0, 1)) ?>');
 
    $this->pager = new sfDoctrinePager('<?php echo $this->getModelClass() ?>', sfConfig::get('app_myCrudThemePlugin_pagination', 20));
    $this->pager->setQuery($query);
    $this->pager->setPage($this->getRequestParameter('page', 1));
    $this->pager->init();
  }

Pour l’affichage du pager, je vous propose de créer un partial que l’on va inclure dans un module du plugin. Etant donné que le fonctionnement est générique, on a pas besoin qu’il soit recopié systèmatiquement dans les modules générés.

On va générer un module appelé shared qui va accueillir le partial du pager et éventuellement d’autres éléments que l’on voudra mutualiser.
La encore sfTaskExtraPlugin nous aide bien car il intégre une commande qui fais ca.

./symfony generate:plugin-module myCrudThemePlugin shared

Il nous reste à aller créer notre partial dans

/plugins/myCrudThemePlugin/modules/shared/templates/_pager.php

<?php if ($pager->haveToPaginate()): ?>
  <div class="pagination">
    <a title="First Page" href="<?php echo (isset($object)) ? url_for($route, $object) : url_for($route) ?>?page=<?php echo $pager->getFirstPage() ?>">« First</a>
    <a title="Previous Page" href="<?php echo (isset($object)) ? url_for($route, $object) : url_for($route) ?>?page=<?php echo $pager->getPreviousPage() ?>">« Previous</a>
<?php foreach ($pager->getLinks() as $page): ?>
    <a title="<?php echo $page ?>" class="number<?php echo ($page == $pager->getPage()) ? ' current' : '' ?>" href="<?php echo (isset($object)) ? url_for($route, $object) : url_for($route) ?>?page=<?php echo $page ?>"><?php echo $page ?></a>
<?php endforeach ?>
    <a title="Next Page" href="<?php echo (isset($object)) ? url_for($route, $object) : url_for($route) ?>?page=<?php echo $pager->getNextPage() ?>">Next »</a>
    <a title="Last Page" href="<?php echo (isset($object)) ? url_for($route, $object) : url_for($route) ?>?page=<?php echo $pager->getLastPage() ?>">Last »</a>
  </div>
  <div class="clear"></div>
<?php endif; ?>

Un pager générique qui fonctionne pour les sfDoctrineRoute et les sfRequestRoute. Il prends deux paramètres, route (obligatoire) et object (facultatif).

On modifie la vue indexSuccess.php pour la faire fonctionner avec le pager et ajouter le partial du pager.

Dans

/plugins/myCrudThemePlugin/data/generator/sfDoctrineModule/myCrudTheme/template/templates/indexSuccess.php

<h1><?php echo sfInflector::humanize($this->getPluralName()) ?> List</h1>
 
<table>
  <thead>
    <tr>
<?php foreach ($this->getColumns() as $column): ?>
      <th><?php echo sfInflector::humanize(sfInflector::underscore($column->getPhpName())) ?></th>
<?php endforeach; ?>
    </tr>
  </thead>
  <tbody>
    [?php foreach ($pager->getResults() as $<?php echo $this->getSingularName() ?>): ?]
    <tr>
<?php foreach ($this->getColumns() as $column): ?>
<?php if ($column->isPrimaryKey()): ?>
<?php if (isset($this->params['route_prefix']) && $this->params['route_prefix']): ?>
 
      <td><a href="[?php echo url_for('<?php echo $this->getUrlForAction(isset($this->params['with_show']) && $this->params['with_show'] ? 'show' : 'edit') ?>', $<?php echo $this->getSingularName() ?>) ?]">[?php echo $<?php echo $this->getSingularName() ?>->get<?php echo sfInflector::camelize($column->getPhpName()) ?>() ?]</a></td>
<?php else: ?>
      <td><a href="[?php echo url_for('<?php echo $this->getModuleName() ?>/<?php echo isset($this->params['with_show']) && $this->params['with_show'] ? 'show' : 'edit' ?>?<?php echo $this->getPrimaryKeyUrlParams() ?>) ?]">[?php echo $<?php echo $this->getSingularName() ?>->get<?php echo sfInflector::camelize($column->getPhpName()) ?>() ?]</a></td>
<?php endif; ?>
<?php else: ?>
      <td>[?php echo $<?php echo $this->getSingularName() ?>->get<?php echo sfInflector::camelize($column->getPhpName()) ?>() ?]</td>
<?php endif; ?>
<?php endforeach; ?>
    </tr>
    [?php endforeach; ?]
  </tbody>
</table>
 
[?php include_partial('shared/pager', array('pager' => $pager, 'route' => '<?php echo (isset($this->params['route_prefix']) && $this->params['route_prefix']) ? $this->getUrlForAction('index') : $this->getModuleName().'/index' ?>')) ?]
 
<?php if (isset($this->params['route_prefix']) && $this->params['route_prefix']): ?>
  <a href="[?php echo url_for('<?php echo $this->getUrlForAction('new') ?>') ?]">New</a>
<?php else: ?>
  <a href="[?php echo url_for('<?php echo $this->getModuleName() ?>/new') ?]">New</a>
<?php endif; ?>

On peut d’ores et déjà générer le crud pour tester,

./symfony doctrine:generate-module --theme="myCrudTheme" frontend job JobeetJob

Et vous voilà libéré de la tâche rébarbative des pagers ! :p

Ca faisait un petit moment que je voulais traiter ce sujet sur le blog, et je comptais continuer en intégrant les formFilter. Malheureusement, je manque de temps pour aller plus loin.
Mais vous avez désormais en votre possession les éléments pour pouvoir faire votre propre thème et l’enrichir à votre guise.

J’espére que ca vous aura été utile et si j’en ai le temps je ferais un prochain post pour voir cette intégration des formFilter

Bien sûr, il ne s’agit pas de permettre aux utilisateurs de télécharger votre dernier rush de photos nocturnes sous forme d’archive zip, ou encore les rapports de la dernière assemblée générale de votre association en PDF; car ceci ne nécessite en rien l’intervention de symfony.

Par contre, dès qu’une action doit être entreprise pour vérifier l’authenticité de l’utilisateur, ou ne serait-ce qu’une table de log pour savoir qui a téléchargé quel fichier, on va avoir besoin de symfony (à moins d’avoir envie de réinventer la roue).

Pour commencer, une action simple, qui affiche selon votre convenance une liste de fichiers ou le détail d’un fichier en particulier, mais surtout, un lien de téléchargement. Pour mon exemple, j’ai déjà fais l’installation du projet, et du plugin sfDoctrineGuardPlugin (avec les fixtures par défaut du plugin).

Mon schéma de base de données ressemble à ça:

Software:
  columns:
    name: string
    path: string
    size: integer
 
Download:
  options:
    symfony:          { form: false, filter: false }
  actAs:
    Timestampable:
      updated:        { disabled: true }
  columns:
    user_id:          { type: integer(4), notnull: true }
    software_id:      { type: integer(4), notnull: true }
  relations:
    Software:
      local:          software_id
      foreign:        id
      foreignAlias:   Downloads
    User:
      class:          sfGuardUser
      local:          user_id
      foreign:        id
      foreignAlias:   Downloads

Mes fixtures, à ça:

Software:
  test:
    name:     symfony latest
    path:     <?php echo sfConfig::get('sf_data_dir') ?>/symfony-1.4.6.tgz
    size:     3233168

Une fois ceci chargé en base de données, on va pouvoir se lancer dans le développement, et plus particulièrement le téléchargement. Pour me simplifier la tâche lors de cet exemple, un unique fichier pourra être télécharger, ainsi, la route pour lancer le « download » du fichier est aussi simple que:

download:
  class:      sfDoctrineRoute
  url:        /download/:id
  options:
    model:    Software
    type:     object
  param:
    module:   file
    action:   download

De ce fait, pour télécharger notre fichier d’exemple, il suffit sur n’importe quelle page, d’inclure un lien vers celui-ci, de cette façon:

<p><?php echo link_to('Télécharger', '@download') ?></p>

Tout le code sera centralisé dans l’action, mais je le répète, ce n’est qu’à titre d’exemple, il serait bien plus approprié de faire un lien de ce type:

<p><?php echo link_to('Télécharger '.$file, 'download', $file) ?></p>

Regardons maintenant plus en détail le contenu de notre action «download» du module «file» (cf. la route ci-dessus)

  public function executeDownload(sfWebRequest $request)
  {
    $this->forward404Unless($this->getUser()->isAuthenticated());
 
    $file = $this->getRoute()->getObject();
 
    $this->forward404Unless(file_exists($file->getPath()), 'Fichier introuvable');
 
    $this->getResponse()->clearHttpHeaders();
    $this->getResponse()->setContentType('application/force-download');
    $this->getResponse()->setHttpHeader('Content-Disposition', 'attachment; filename="' . basename($file->getPath()).'"');
    $this->getResponse()->setHttpHeader('Content-Transfer-Encoding', 'binary');
    $this->getResponse()->setHttpHeader('Content-Length', $file->getSize());
    $this->getResponse()->setHttpHeader('Connection', 'close');
 
    $this->getResponse()->setContent(file_get_contents($file->getPath()));
    $this->getResponse()->send();
  }

A ce niveau, deux problèmes majeurs se posent:

• file_get_contents est dépendant du paramètre memory_limit de php
• la web_debug_toolbar va venir s’immiscer dans chaque download

Le problème de la web_debug_toolbar peut vite être résolu en la désactivant dans l’action avec sfConfig::set(‘sf_web_debug_false’, false) mais il reste le problème du téléchargement de fichiers dont la taille dépasse notre memory_limit. Ce paramètre étant généralement bas en production (128 Mo par défaut), ça peut vite être génant. La solution est d’utiliser la fonction php readfile() qui elle, envoit directement des blocs de 8 Ko sur la sortie, et donc n’est pas soumis à la limite d’utilisation de mémoire PHP.

On remplace donc:

    $this->getResponse()->setContent(file_get_contents($file->getPath()));
    $this->getResponse()->send();

par

    $this->getResponse()->sendHttpHeaders();
    @readfile($file->getPath());
    throw new sfStopException();

L’exception sfStopException() est une manière un peu «crade» de mettre un terme à l’exécution du script, mais c’est moins pire qu’un « die » et du coup, ça permet dans un deuxième temps de ne pas être embêté par la web_debug_toolbar.
Il arrive souvent aussi que les headers ne soient pas envoyés, c’est dû au fait que la sortie est bufferisée, ce problème se résoud avec l’utilisation des fonctions flush() et/ou ob_end_clean() juste avant le readfile.

Maintenant, on avait pour but de passer par symfony pour enregistrer des logs sur les téléchargements. Rien de plus simple, un exemple pourrait être le code suivant à rajouter après la vérification de l’existence du fichier (file_exists()) :

    $dl = new Download();
    $dl->setSoftware($file);
    $dl->setUser($this->getUser()->getGuardUser());
    // other stuff
    $dl->save();

A ce stade, tout pourrait sembler correct. C’était sans compter une fourberie de PHP, qui va bloquer toute autre action sur votre site pendant un téléchargement. En effet, les sessions fonctionnent avec un « LOCK » et vu que les sessions sont en auto_start avec symfony, le téléchargement se fait pendant une session, et aucune autre action de la part de l’utilisateur ne sera accepté pendant un téléchargement, car sa session étant identifiée comme « en cours d’écriture » (le principe de lock).
Une personne ayant déjà rencontré ce problème pourrait se dire qu’en fermant la session à l’aide de

$this->getUser()->shutdown();

dans l’action résoudrait le problème, et ce n’est pas le cas, même si en effet, la fonction shutdown() va libérer la session grâce à la fonction session_write_close(), elle ne sera exécuté qu’à la fin du script, donc dans notre cas, ça n’a aucun intêret, il faut faire le session_write_close() directement dans notre action.

Pour finir, voici le code complet de notre action :

  public function executeDownload(sfWebRequest $request)
  {
    $this->forward404Unless($this->getUser()->isAuthenticated());
 
    $file = $this->getRoute()->getObject();
 
    $this->forward404Unless(file_exists($file->getPath()), 'Fichier introuvable');
 
    $dl = new Download();
    $dl->setSoftware($file);
    $dl->setUser($this->getUser()->getGuardUser());
    // other stuff
    $dl->save();
 
    session_write_close();
 
    $this->getResponse()->clearHttpHeaders();
    $this->getResponse()->setContentType('application/force-download');
    $this->getResponse()->setHttpHeader('Content-Disposition', 'attachment; filename="' . basename($file->getPath()).'"');
    $this->getResponse()->setHttpHeader('Content-Transfer-Encoding', 'binary');
    $this->getResponse()->setHttpHeader('Content-Length', $file->getSize());
    $this->getResponse()->setHttpHeader('Connection', 'close');
 
    $this->getResponse()->sendHttpHeaders();
 
//    @ob_end_clean();
//    flush();
 
    @readfile($file->getPath());
 
    throw new sfStopException();
  }

J’espère que ceci vous aidera dans vos développements actuels et futurs,
@ bientôt.

Pour commencer nous avons bien sûr besoin de créer notre application Facebook. Cela n’étant pas le but de cet article, je vous laisse trouver la marche à suivre sur le net; les sites couvrant le sujet sont légion (par exemple créer une application Facebook).

On paramètre correctement l’application et celle-ci s’occupera ensuite de charger nos pages dynamiques depuis l’url spécifiée:

L’application Symfony n’a ici qu’un seul module « demo » qui s’occupe des quelques actions nécessaires. Editons « app.yml » pour y ajouter l’ID et le SECRET obtenus lors de la création de notre application:

all:
  facebook:
    app_id: 116399618389033
    api_key: *******************************************
    secret: *****************************************
    base_url: http://facebook.prestataire-symfony.com
    app_url: http://apps.facebook.com/demolexik

Il nous faut ensuite récupérer l’api Facebook PHP sur Github, que nous allons coller dans /lib/facebook/facebook.php.
Afin de ne pas avoir à initialiser les appels à l’api depuis chaque action, un filter va grandement nous simplifier la tâche:

// lib/filter/FacebookFilter.class.php
class FacebookFilter extends sfFilter
{
 
  public function execute(sfFilterChain $filterChain)
  {
    $context = $this->getContext();
    $request = $context->getRequest();
    //initialisation de l'appel à l'api...
    $facebook = new Facebook(array(
          'appId'   => sfConfig::get('app_facebook_app_id'),
          'secret'  => sfConfig::get('app_facebook_secret'),
          'cookie'  => true,
      ));
 
    $context->getController()
            ->getActionStack()
            ->getLastEntry()
            ->getActionInstance()
            ->facebook = $facebook;
 
    $filterChain->execute();
  }
}

Pensez à éditer votre « filters.yml » en conséquence.

#apps/frontend/config/filters.yml
rendering: ~
security:  ~
# insert your own filters here
Facebook:
  class: FacebookFilter
cache:     ~
execution: ~

Pour l’api Javascript, nous allons éditer le layout de l’application:

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:fb="http://www.facebook.com/2008/fbml">
  <head>
    <?php include_http_metas() ?>
    <?php include_metas() ?>
    <title>Facebook App</title>
    <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.4/jquery.min.js" type="text/javascript"></script>
    <style>
      div.section {
        margin-bottom: 10px;
        background: #EEEEEE;
        padding: 5px 10px;
      }
      body {
        font-family: Arial;
        font-size: 12px;
      }
      pre {
        font-size: 10px;
        color: #333333;
        margin-left: 50px;
      }
    </style>
  </head>
  <body>
    <div id="fb-root"></div>
    <script src="http://connect.facebook.net/en_US/all.js" type="text/javascript"></script>
    <script type="text/javascript">
    FB.init({
       appId  : '<?php echo sfConfig::get('app_facebook_app_id') ?>',
       status : true, // vérifie le status de la connection
       cookie : true, // autorise les cookies pour permettre au serveur d'accéder à la session'
       xfbml  : true  // active le parsing de XFBML
      });
    </script>
    ...

Nous en profitons pour charger JQuery afin de faciliter l’ajax et le remaniement du Dom.

Voilà, nous sommes prêts à attaquer les actions.

La première action va être l’authentification de l’utilisateur Facebook, et la gestion des permissions que celui-ci devra accorder à notre application.
Le nouveau modèle de Facebook veut que nous demandions à l’utilisateur, dès le premier accès à l’application, qu’il accepte simultanément toutes les permissions nécessaires. Pour plus d’informations à ce sujet, consultez la liste des permissions sur le wiki Facebook Developer.
Voici l’action Login, qui sera appelée lorsque l’utilisateur n’a pas accordé ces permissions, ou lors d’une première visite de l’application:

//apps/frontend/modules/demo/actions/actions.class.php
public function executeLogin(sfWebRequest $request)
  {
    //on génère l'url qui permettra le login à l'application
    $this->loginUrl = $this->facebook->getLoginUrl(array(
            'canvas'    => 1,
            'fbconnect' => 0,
            //ici on demande les permissions email, publication sur le mur, et changement du status
            'req_perms' => 'email,publish_stream,status_update',
            'next'      => ''
        ));
  }

Comme nous sommes dans une application iframe, il faut charger l’url de login depuis la frame parente, et notre template va s’en charger:

<!--loginSuccess.php-->
<script type="text/javascript">
top.location.href = "<?php echo $sf_data->getRaw('loginUrl') ?>";
</script>

Il faut maintenant que notre index redirige vers ce login dans les cas précédemment cités:

//apps/frontend/modules/demo/actions/actions.class.php
public function executeIndex(sfWebRequest $request)
  {
    //on vérifie si l'utilisateur a une session facebook active
    $this->session = $this->facebook->getSession();
    if (!$this->session)
    {
      //sinon il doit s'identifier
      $this->redirect('demo/login');
    }
 
    //s'il a une session active, on vérifie si elle est valide pour notre application
    try
    {
      $this->uid = $this->facebook->getUser();
      $this->fbme = $this->facebook->api('/me');
    }
    catch (FacebookApiException $e)
    {
      //sinon il doit à nouveau s'identifier
      $this->redirect('demo/login');
    }
  }

On peut maintenant voir une demande de permissions s’afficher lorsque l’on se connecte à l’application:

En vérifiant la validité de la session, nous avons récupéré toutes les informations sur l’utilisateur auxquelles nos permissions nous donnent accès. Voyons l’étendue de ces informations en les affichant dans notre vue:

<!-- indexSuccess.php -->
<div class="section">
<h3>Informations utilisateur</h3>
<pre><?php print_r($fbme) ?> /pre>
</div>

Nous accédons bien à l’adresse email comme spécifié, ainsi qu’aux informations génériques et publiques sur l’utilisateur.

Il est maintenant temps d’interagir avec l’utilisateur. Il nous a également accordé l’accès à son status, nous allons donc lui proposer de l’éditer via notre application:

<!-- indexSuccess.php -->
...
<div class="section">
  <a onclick="updateStatus();return false;" href="#">Changer mon status via Ajax et l'API PHP</a>
  <textarea id="status_text" cols="40" rows="2">  </textarea>
</div>
...
<script type="text/javascript">
function updateStatus()
  {
    var status = document.getElementById('status_text').value;
 
    $.ajax({
      type: 'post',
      url: '<?php echo url_for('demo/statusUpdate') ?>',
      data: 'status=' + status,
      success: function(response) {
        alert(response);
      },
      error: function(response) {
        alert(response);
      }
    });
  }
</script>

La méthode js « updateStatus() » va faire un appel ajax à une nouvelle action updateStatus de notre application:

//apps/frontend/modules/demo/actions/actions.class.php
public function executeUpdateStatus(sfWebRequest $request)
  {
    $this->forward404Unless($request->isXmlHttpRequest());
    $status = $request->getParameter('status');
    try
    {
      //un simple appel a l'api suffit à poster un nouveau status sur le profile de l'utilisateur
      $this->facebook->api(
          '/me/feed',
          'post',
          array( 'message' => $status, 'cb' => '' )
        );
    }
    catch (FacebookApiException $e)
    {
      return $this->renderText('Erreur: '.$e);
    }
    return $this->renderText('Status mis-à-jour');
  }

L’api Javascript est toute aussi simple à utiliser. Proposons cette fois à l’utilisateur de parler de notre application sur son mur à l’aide de javascript:

<!-- indexSuccess.php -->
...
<div class="section">
  <a onclick="publishWall();return false;" href="#">Poster un article sur mon mur via l'API Javascript</a>
</div>
...
<script type="text/javascript">
function publishWall()
  {
    FB.ui(
    {
      method: 'stream.publish',
      message: '',
      attachment:
      {
        name: "Démo Symfony+Facebook",
        caption: '',
        description: "Une démo simple d'application Facebook avec Symfony et les dernières API Javascript et PHP de Facebook.",
        href: "http://www.lexik.fr/blog/symfony/non-classe/exemple-dapplication-utilisant-la-graph-api-de-facebook-1187"
      },
      user_prompt_message: "Application de démo Symfony+Facebook"
    },
    function (response) {}
    );
  }
</script>

Le résultat obtenu en cliquant sur le lien est le pseudo-popup bien connu de Facebook:

Nous venons de voir quelques méthodes simples d’accès ou de publication de données. Une liste plus complète des méthodes éxistantes est sur le wiki Facebook Developer.
Dans le cadre d’applications plus complexes, il sera souvent utile de pouvoir formuler précisément les informations que l’on souhaite récupérer, et celles-ci ne correspondront pas nécessairement à une méthode éxistante. Pour cela Facebook met à notre disposition FQL, un langage de requète similaire à SQL dans sa syntaxe, pour générer nos requètes spécifiques.

Par exemple, récupérons la liste des amis de l’utilisateur avec leur nom, leur uid, et leur photo. Voici la requète FQL pour cela, et son éxécution via l’api PHP:

//apps/frontend/modules/demo/actions/actions.class.php
public function executeIndex(sfWebRequest $request)
  {
    ...
    //récupération des amis via FQL
    $query = "SELECT name, uid, pic_square FROM user WHERE uid in (SELECT uid2 FROM friend WHERE uid1 = ".$this->uid.")";
    $this->amis = $this->facebook->api(array(
        'method'    => 'fql.query',
        'query'     => $query,
        'callback'  => ''
    ));
  }

Et l’affichage de la liste dans la vue:

<!-- indexSuccess.php -->
<div class="section">
<h3>Liste d'amis</h3>
<?php foreach ($amis as $ami): ?>
<ul>
	<li><img src="<?php echo $ami['pic_square'] ?>" alt="" /></li>
	<li><strong><?php echo $ami ['name'] ?></strong></li>
	<li>uid: <?php echo $ami['uid'] ?></li>
</ul>
<?php endforeach; ?>
</div>

Cet article n’était pas dédié à Symfony, mais l’utilisait plutôt pour proposer un environnement familier à notre application. Ce survol rapide de la nouvelle Graph Api permet surtout de donner un point de départ sur l’utilisation de la nouvelle librairie à un moment ou la documentation à son sujet n’est pas vraiment fournie, en particulier en français !
Vous pouvez voir l’application tourner sur http://apps.facebook.com/demoLexik.

comme vous avez pu le voir avec les récents posts, nous avons eu pas mal de gestion de facturation: conversion de devises, validation d’un numéro de tva intracommunautaire.

Pour continuer sur la lancée, nous allons faire un petit validator sur les numéros siret.

Un numéro siret correspond à un petit algorithme assez simple expliqué ici (algorithme de Luhn)
Le principe est le suivant : on multiplie les chiffres de rang impair à partir de la droite par 1, ceux de rang pair par 2 ; la somme des chiffres obtenus doit être congrue au modulo 10, c’est-à-dire qu’elle doit être multiple de 10.
Un numéro siret comporte 14 chiffre.

Voici le code du validator: sfValidatorSiret.class.php

class sfValidatorSiret extends sfValidatorBase 
{
  protected function doClean($values)
  {
    $siret = trim($values);
    if(empty($siret) || strlen($siret) != 14)
    {
      throw new sfValidatorError($this, 'Le numéro siret est invalide');
    }
    $sum = 0;
    for($i=0; $i<14; $i++)
    {
      if($i%2 == 0)
      {
        $tmp = $siret[$i]*2;
        $tmp = $tmp > 9 ? $tmp - 9 : $tmp;
      }
      else
      {
        $tmp= $siret[$i];
      }
      $sum += $tmp;
    }
    if($sum%10 !== 0)
    {
      throw new sfValidatorError($this, 'Le numéro siret est invalide');
    }
    return $siret;
  }
}

Pour expliquer rapidement:
1. si la valeur est vide ou de longueur différente de 14 on retourne une exception.
2. on parcours les 14 chiffres, si le chiffre est paire alors on le multiplie par 2 et si ce résultat est supérieur à  9 alors on retranche 9.
ex: 7 => 7×2 = 14 => 14 – 9 = 5.
faire 14 -9  reviens à additionner les 2 chiffres: 1 + 4 = 5.
3. On additionne tous les chiffres paires x2 et les chiffres impaires.
4. si le résultat est divisible par 10 alors c’est un numéro siret.

Attention ceci indique que le numéro fourni peut être un numéro siret, MAIS PAS que ce numéro est réellement un numéro siret inscrit à L’INSEE, actif et correspond à une société.

Vous pouvez télécharger le validator ici.

Le site de la banque centrale Européenne publie tous les jours un fichier XML contenant les taux de conversion à jour.

Il fournit également un morceau de code donnant un exemple de manipulation

http://www.ecb.europa.eu/stats/eurofxref/eurofxref-daily.xml

Voici le code fourni par le site lui-même pour les développeurs :

  <?php
//This is a PHP (4/5) script example on how eurofxref-daily.xml can be parsed 
 
//Read eurofxref-daily.xml file in memory 
$XMLContent= file("http://www.ecb.europa.eu/stats/eurofxref/eurofxref-daily.xml");
//the file is updated daily between 2.15 p.m. and 3.00 p.m. CET
 
foreach ($XMLContent as $line) {
        if (ereg("currency='([[:alpha:]]+)'",$line,$currencyCode)) {
            if (ereg("rate='([[:graph:]]+)'",$line,$rate)) {
                    //Output the value of 1 EUR for a currency code 
                    echo '1 &euro; = '.$rate[1].' '.$currencyCode[1].'<br />';
                    //--------------------------------------------------
                    // Here you can add your code for inserting
                    // $rate[1] and $currencyCode[1] into your database
                    //--------------------------------------------------
            }
        }
}
?>

Ce code permet d’afficher les taux de conversion Euro vers devise pour toutes les devises.
(source : http://www.ecb.europa.eu/stats/exchange/eurofxref/html/index.en.html)

Et voici un helper tout simple permettant de convertir directement de EUR vers une devise, en utilisant la librairie Dom.

function convertEuroToCurrency($value, $currency)
{
//ouverture du doc
  $dom_rates = new DOMDocument();
  $dom_rates->load("http://www.ecb.europa.eu/stats/eurofxref/eurofxref-daily.xml");
  //récupération de l'ensemble des éléments Cube
  $dom_cubes = $dom_rates->getElementsByTagName('Cube');
 
  $i = 0;
  $j = 0;
  $rate_found=false;
  //tant qu'on a pas trouvé le bon pays, on continue
  while (!$rate_found && $cube = $dom_cubes->item($i))
  {
    $j = 0;
    //tant qu'on a pas trouvé le bon pays, on continue
    while(!$rate_found && $attribute = $cube->attributes->item($j))
    {
    //si on est en train de lire le noeud "temps" on stocke la date
      if($attribute->name == 'time') $date = $attribute->value;
 
      //si l'attribut et "currency" on est en train de lire le code pays, on vérifie aussi que c'est le bon
      $rate_found = $attribute->name == 'currency' && $attribute->value == $currency;
      $j++;
    }
    $i++;
  }
 
  //si le pays a été trouvé, on affiche le résultat de la conversion
  if($rate_found)
  {
    return "le ".$date." ".$value." EUR = ".($cube->attributes->item($j)->value*$value).' '.$cube->attributes->item($j-1)->value;
  }else{
    return "cette devise n'existe pas";
  }
}

Pour tester :

use_helper('Converter');
echo convertEurToCurrency(125, 'USD');

Et voilà !

Or il se trouve que dans une situation pareille intervient la notion de TVA, où la responsabilité du développeur (ou de son employeur) peut être mise en jeu (ainsi que celle du client, mais ça…).

Lors du paiement, un client professionnel (une société, entreprise, personne morale quoi) devra saisir son numéro de TVA ainsi que son pays pour que le montant de la TVA correspondant soit calculé puisqu’il change d’un pays à l’autre.
Le site http://ec.europa.eu/ propose un webService permettant de vérifier cela.

Moi, je vous propose un validator personnalisé pour valider le numéro de TVA entré dès la validation du formulaire, basé sur ce webService.

Voici l’adresse du wsdl : http://ec.europa.eu/taxation_customs/vies/checkVatService.wsdl.

Le validator

Je pars du principe que l’utilisateur saisit son numéro de TVA et son code pays dans 2 champs différents. Le validator devra alors faire un contrôle en prenant en compte les 2 champs, à l’instar du validator Doctrine qui vérifie la concordance entre le username et le password au login. Donc il héritera de la classe sfValidatorSchema.

Commençons par voir la méthode __construct :

public function __construct($vat_number = 'vat_number', $country = 'country', $options = array(), $messages = array())
{
  $this->addOption('vat_number', $vat_number);
  $this->addOption('country', $country);
 
  $this->addOption('throw_global_error', false);
 
  $this->messages = array_merge(
    $this->messages,
    array(
      'invalid_syntax'=>'Your VAT Number syntax is not correct. You should have something like this: BE805670816B01',
      'invalid_country'=>'Your VAT Number is not valid for the selected country.',
      'invalid'=>sprintf('Invalid VAT Number. Check the validity on the customer VAT Number via <a href="%s">Europa VAT Number validation webservice</a>', 'http://ec.europa.eu/taxation_customs/vies/lang.do?fromWhichPage=vieshome'),
    )
  );
 
  parent::__construct(null, $options, $messages);
}

Ici on définit l’intitulé par défaut des champs contenant le numéro de TVA (vat_number) et le code du pays (country).
Puis on définit les messages des différentes erreurs pouvant être générées :
- mauvaise syntaxe
- pays qui ne correspond pas
- numéro invalide.

Voyons maintenant le doClean et la méthode appelant le webService :

public function doClean($values)
  {
    if (null === $values)
    {
      $values = array();
    }
 
    if (!is_array($values))
    {
      throw new InvalidArgumentException('You must pass an array parameter to the clean() method');
    }
 
    $vatnumber  = isset($values[$this->getOption('vat_number')]) ? $values[$this->getOption('vat_number')] : null;
    $country = isset($values[$this->getOption('country')]) ? $values[$this->getOption('country')] : null;
 
    //on récupère la validité du numéro de TVA via le webService
    $valid = $this->haleValidateVAT(array('vatnumber' => $vatnumber, 'country' => $country));
 
    //si le résultat n'est pas valide, on throw l'erreur correspondante
    if (!$valid['result'])
    {
      throw new sfValidatorError($this, $valid['error'], array('value' => $vatnumber));
 
      if ($this->getOption('throw_global_error'))
      {
        throw $error;
      }
 
      //l'erreur s'applique sur le champ vat_number
      throw new sfValidatorErrorSchema($this, array($this->getOption('vat_number') => $error));
    }
 
    //si valide, on retourne les valeurs
    return $values;
  }
 
  /**
   * vérifie la validité du numéro de TVA en prenant en compte le pays donné
   *
   * @param array $args
   * @return array
   */
  protected function haleValidateVAT($args = array()) {
    if ( '' != $args['vatnumber'] )
    {
      // on sérialize le numéro TVA
      $vat_number 	= str_replace(array(' ', '.', '-', ',', ', '), '', $args['vatnumber']);
      // on récupère le code pays
      $countryCode 	= substr($vat_number, 0, 2);
      //on récupère le numéro TVA
      $vatNumber 		= substr($vat_number, 2);
 
      //on vérifie la syntaxe du numéro
      if (strlen($countryCode) != 2 || is_numeric(substr($countryCode, 0, 1)) || is_numeric(substr($countryCode, 1, 2)))
      {
        $error = array('result' => false, 'error'=>'invalid_syntax');
        return $error;
      }
 
      //on vérifie que le pays correspond bien au pays indiqué dans le numéro de TVA
      if ( $args['country'] != $countryCode )
      {
        $error = array('result' => false, 'error'=>'invalid_country');
        return $error;
      }
 
      //appelle le webservice
      $client = new SoapClient("http://ec.europa.eu/taxation_customs/vies/checkVatService.wsdl");
      $params = array('countryCode' => $countryCode, 'vatNumber' => $vatNumber);
      $result = $client->checkVat($params);
 
      //vérifie la validité et renvoie l'erreyr correspondante
      if ( !$result->valid )
      {
        $error = array('result' => false, 'error'=>'invalid');
        return $error;
      }else{
        return array('result' => true);
      }
    }
    return array('result' => false, 'error'=>'required');
  }

Testons

Pour tester tout simplement, voici un petit formulaire contenant uniquement les champs pays et numéro de TVA :

class TestVATForm extends sfForm
{
  public function configure()
  {
    $this->widgetSchema['vat_number'] = new sfWidgetFormInput();
    $this->widgetSchema['country'] = new sfWidgetFormInput();
 
    $this->validatorSchema['vat_number'] = new sfValidatorString();
    $this->validatorSchema['country'] = new sfValidatorString();
 
    $this->validatorSchema->setPostValidator(new sfValidatorVAT());
 
    $this->widgetSchema->setNameFormat('tva_form[%s]');
  }
}

Voici l’action :

class defaultActions extends sfActions
{
  public function executeTestTVA(sfWebRequest $request)
  {
    $this->form = new TestVATForm();
 
    if($request->isMethod('post'))
    {
      $this->form->bind($request->getParameter($this->form->getName()));
 
      if($this->form->isValid())
      {
        $this->getUser()->setFlash('notice', 'TVA ok');
        $this->redirect('default/testTVA');
      }else{
        $this->getUser()->setFlash('error', 'TVA ko');
      }
    }
  }
}

Et pour finir, voici la vue (toute bête) :

<form action="<?php echo url_for('default/testTVA') ?>" method="post">
  <table>
    <?php echo $form ?>
    <tr>
      <td></td>
      <td>
        <input type="submit" value="Tester" />
      </td>
    </tr>
  </table>
</form>

Et voilà !

Pour le listing de ces zones j’ai donc choisi d’utiliser un plugin jQuery : treeTable. Comme son nom l’indique ce plugin va nous permettre une organisation d’un arbre dans une table HTML. Il faut indiquer en « id » de la balise
de notre tableau un identifiant de notre objet (ex: id= »node-1″) et à l’attribut « class » on signale de qui le noeud est l’enfant (ex: child-of-node-1 sera le fils du noeud 1).

  <div class="content-box-content">
    <table id="tree">
      <tbody>
        <?php foreach ($areas as $area) : ?>
        <?php $parent = $area->getNode()->getParent() ?>
        <tr id="node-<?php echo $area->getId() ?>" <?php echo $parent ? 'class="child-of-node-'.$parent->getId().'"' : '' ?>>
          <td><?php echo $area->getName() ?></td>
          <td>
            <?php echo link_to(__('module_area_list_action_add_children'), 'area_new', $area->getType(), array('query_string' => 'parent_id='.$area->getId())) ?>
          </td>
          <td>
            <?php echo link_to(__('text_action_delete'), '@area_delete?id='.$area->getId(), array('method' => 'delete', 'confirm' => __('text_action_delete_confirm'))) ?>
          </td>
        </tr>
        <?php endforeach ?>
      </tbody>
    </table>
  </div>

Voici le résultat :

Le rendu correspond à ce que souhaite mon client, lorsque l’on clique sur une branche, par exemple Afrique ou Europe les lignes suivantes se déplient et laissent apparaitre les enfants. Tout va pour le mieux dans le meilleur des mondes, simplement quand on regarde de plus près on s’aperçoit que pour un listing de simplement 12 zones je fais 29 requêtes, que va t’il se passer lorsque je vais avoir toutes mes zones renseignées, la réponse est : +700 requêtes. Le souci vient de la méthode getNode()->getParent() qui exécute une nouvelle requête à chaque appel. En effet pour lier une ligne à son parent j’ai besoin de connaître l’ID du père.

Pour remédier à cela je vais donc utiliser l’Hydratation hiérarchisée, que l’on peut créer à l’aide d’une Doctrine_Query qu’on exécutera comme suit :

Doctrine_Core::getTable('Area')->
   createQuery('a')
  execute(array(), Doctrine_Core::HYDRATE_RECORD_HIERARCHY);

Sinon on peut directement utiliser la méthode toHierarchy() sur notre collection, qui nous hydratera directement cette dernière. Chaque élément contenant alors des enfants aura une clé __children, qui n’est autre qu’un tableau des éléments enfants.

Je vais donc remplacer mon code et utiliser un helper pour le rendu d’une ligne ce qui permettra de faire de la récursivité plus facilement dans mon code.

Je crée donc l’helper suivant :

// apps/backend/lib/helper/AreaHierarchyHelper.php
 
<?php
 
/**
 * Permet l'affichage en arbre dans le listing des zones
 *
 * @param Area $area
 * @param int $parent
 * @return string
 */
function render_row($area, $parent = null)
{
 
  // Formatage du HTML
  $html = sprintf('
<tr id="node-%s"%s>
  <td>%s</td>
  <td>%s</td>
  <td>%s</td>
  <td>%s</td>
  <td>%s</td>
</tr>',
      $area->getid(), (null === $parent ? '' : sprintf(' class="child-of-node-%s"', $parent)),
      $area->getName(),
      'ID : '.$area->getId(),
      link_to(__('module_area_list_action_add_children'), 'area_new', $area->getType(), array('query_string' => 'parent_id='.$area->getId())),
      link_to(__('text_action_edit'), 'area_edit', $area, array('class' => 'area-edit')),
      link_to(__('text_action_delete'), '@area_delete?id='.$area->getId(), array('method' => 'delete', 'confirm' => __('text_action_delete_confirm'))));
 
  // Récursivité pour créer les lignes des fils
  foreach ($area->get('__children') as $child)
  {
    $html .= render_row($child, $area->getid());
  }
 
  return $html;
}

Désormais sur ma page, il me suffit de charger mon helper et d’écrire le code suivant :

<?php use_helper('AreaHierarchy') ?>
 
<div class="content-box">
  <div class="content-box-header">
  </div>
  <div class="content-box-content">
    <table id="tree">
      <tbody>
        <?php foreach ($areas->toHierarchy() as $area) : ?>
          <?php echo render_row($area) ?>
        <?php endforeach ?>
      </tbody>
    </table>
  </div>
</div>

Le résultat est exactement le même au niveau de l’affichage en revanche je passe désormais à 5 requêtes et sur les données définitives, j’obtiens toujours 5 requêtes et ce quelque soit le nombre de résultat dans ma collection. J’ai donc bénéficié des avantages de Doctrine et surtout des Doctrine_Hydrator pour diminuer le nombre de requêtes.

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

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 :

generator:
  config:
    list:
      table_method: retrieveBackendCommentList

La méthode en question :
plugins/sfLexikDoctrineActAsCommentablePlugin/lib/model/doctrine/PluginCommentTable.class.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 :

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 :

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 :

  /**
   * 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 :

<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 :

generator:
  config:
      edit:
        display: [..., _handle_comments]

apps/backend/modules/message/template/_handle_comments.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

<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 :

<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 :

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 :

  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 :

include_partial('comment/backend_show', array('comment'=>$comment))

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

En réalité il y a bien plus d’étapes que cela mais ce scénario me permet de poser les bases de mon article.

Pour rester dans la simplicité voici le schéma que nous allons utiliser :

ModelA:
  columns:
    id:         { type: integer(4), autoincrement: true, unsigned: true, primary: true }
    title:      { type: string(255), notnull: true }
    body:       { type: clob, notnull: true }
 
ModelB:
  columns:
    id:         { type: integer(4), autoincrement: true, unsigned: true, primary: true }
    title:      { type: string(255), notnull: true }
    body:       { type: clob, notnull: true }

Tout d’abord j’ai un formulaire lié à un modèle, je dois conserver cet objet dans ma session pour me permettre d’y accéder lors des étapes suivantes. Voilà comment j’ai procédé au niveau de ma class myUser :

<?php
 
class myUser extends sfBasicSecurityUser
{
  const
  MY_NAMESPACE = 'mynamespace';
 
  /**
   * __call
   *
   * @param string $method
   * @param Array $arguments
   */
  public function __call($method, $arguments)
  {
 
    switch (true)
    {
      case (('set' === $prefix = substr($method, 0, 3))
          && (Doctrine_Core::isValidModelClass($class = substr($method, 3)))) :
        $this->_set($class, $arguments[0]);
        break;
 
      case (('getInstance' === $prefix = substr($method, 0, 11))
          && (Doctrine_Core::isValidModelClass($class = substr($method, 11)))) :
        return $this->getModelInstance($class);
        break;
 
      default:
        return parent::__call($method, $arguments);
        break;
    }
 
  }
 
  /**
   * Model storage
   *
   * @param string $class
   * @param Doctrine_Record $argument
   */
  public function _set($class, $argument)
  {
    if (!$argument instanceof $class)
    {
      throw new Exception(sprintf('You must specify a valid %s', $class));
    }
 
    $this->setAttribute($class, $argument, self::MY_NAMESPACE);
  }
 
  /**
   * Return model
   *
   * @param string $modelName
   * @return Doctrine_Record
   */
  protected function getModelInstance($modelName)
  {
    return $this->getAttribute($modelName, array(), self::MY_NAMESPACE);
  }
}

Ayant surchargé ma méthode __call(), je peux désormais appeler les méthodes suivantes :

$this->getUser()->setModelA(new ModelA());
$this->getUser()->getInstanceModelA();

Pour être sûr de ne passer que des objets définis au niveau de mon schéma j’utilise la méthode « Doctrine_Core::isValidModelClass », ce code me permet également de ne conserver qu’une seule fois un objet au niveau de mon objet myUser. De plus, je regroupe toutes ces données dans un « namespace » ce qui me permettra de les effacer très simplement par exemple si mon utilisateur souhaite retourner sur la première étape.

// apps/MON_APPS/modules/MON_MODULE/actions/action.class.php
  public function executeStep1(sfWebRequest $request)
  {
    $this->getUser()->cleanMyNameSpace();
  }
 
// apps/MON_APPS/lin/myUser.class.php
  /**
   * Clean Mynamespace
   *
   * @param $exception Valeur à ne pas enlever
   * @return void
   */
  public function cleanMyNameSpace()
  {
    $this->getAttributeHolder()->removeNamespace(self::MY_NAMESPACE);
  }

Ce code m’a permis de conserver une flexibilité lorsque je passe d’une étape à l’autre, en effet, j’aurai pu choisir de passer simplement les attributs que je souhaite conserver. Depuis la mise en production les paramètres nécessaires d’une étape à l’autre ont changé en conservant un objet entier je n’ai pas eu à m’en soucier, de plus je ne suis pas obligé de stocker ces objets en base de donnée.

Au niveau des formulaire l’apparition du EmbedRelation a vraiment facilité l’implémentation des embedForm. Je ne vais pas reprendre l’explication de cette fonctionnalité dans cet article et vous renvoie donc vers le très bon article de NiKo sur son blog (En anglais).

Petit problème, l’ordre de tri de la Doctrine_Collection retrounée qui est … en vrac ^^ J’en ai fait l’expérience sur une base postGre ou l’ordre de retour est en fonction de la dernière modification alors que sur une base mySql c’est l’ordre des IDs (déjà moins gênant). Dans les 2 cas ça n’est pas très satisfaisant, et on aimerais pouvoir maitriser l’ordre de tri de cette relation.

Un bout de schema.yml pour pouvoir illustrer mon explication :

...
Produit:
  columns:
    id:                 { type: integer(4), unsigned: true, primary: true, autoincrement: true }
    name:               { type: string(128), notnull: true }
 
Photo:
  columns:
    id:                 { type: integer(4), unsigned: true, primary: true, autoincrement: true }
    file_name:          { type: string(128), notnull: true }
    id_produit:         { type: integer(4), unsigned: true }
    ordre:              { type: integer(4), unsigned: true }
  relations:
    Produit:
      local:            id_produit
      foreign:          id
      foreignAlias:     Photos
      onDelete:         CASCADE
...

Dans ce contexte on peut imaginer faire un EmbedRelation des Photos dans la classe ProduitForm.

Le fonctionnement du EmbedRelation est qu’il utilise l’accesseur magique getPhotos() qui elle même fait un findByIdProduit() dans la classe PhotoTable et retourne une Doctrine_Collection d’objects Photo. Seul problème comme je l’ai dit plus haut, c’est que la requête n’est pas trié.

Vous allez me dire « c’est facile, il n’y a qu’à surcharger getPhotos() de Produit.class.php ». C’est ce que j’avais fait au début, et ça marche. Seul problème, c’est que lorsque l’on redéfini un accesseur magique (ici le getteur) l’autre (le setteur) ne fonctionne plus… est ce que c’est voulu ou est ce que c’est un bug? Je n’en sais rien ^^ Toujours est-il que je me servais du setteur et donc cette solution ne m’a pas convenu et j’ai cherché une alternative.

L’alternative est prévue par Doctrine qui depuis la 1.2 qui implémente la possibilité de spécifier le orderBy sur une relation directement lors de sa définition dans le schema.yml. Seul problème le foreinOrderBy n’existe pas et donc la définition de la relation ne peut plus se faire comme je l’avais écrite plus haut, il faut la définir des deux cotés.

Tréve de blabla, ca ressemble à quelque chose comme ca :

...
Produit:
  columns:
    id:                 { type: integer(4), unsigned: true, primary: true, autoincrement: true }
    name:               { type: string(128), notnull: true }
  relations:
    Photos:
      type:             many
      class:            Photo
      local:            id
      foreign:          id_produit
      orderBy:          ordre ASC
      onDelete:         CASCADE
 
Photo:
  columns:
    id:                 { type: integer(4), unsigned: true, primary: true, autoincrement: true }
    file_name:          { type: string(128), notnull: true }
    id_produit:         { type: integer(4), unsigned: true }
    ordre:              { type: integer(4), unsigned: true }
  relations:
    Produit:
      local:            id_produit
      foreign:          id
      onDelete:         CASCADE
...

J’espère que cette petite astuce vous aidera.
@bientôt

Le behavior donne les fonctionnalités, le plugin donne le modèle et l’affichage ainsi que les actions (listing des commentaires, formulaire d’ajout de commentaire, …)

Je me suis basé sur le behavior Doctrine Taggable fourni à l’origine pour réaliser ceci.

Le behavior et le plugin ne sont pas utilisable l’un sans l’autre.

télécharger les sources

Fourni par le behavior :

Le listener :

void postDelete(event) //supprime tous les commentaires liés lors de la suppression de l’objet les portant

Le template et ses méthodes :

void addComment(Comment) //ajoute le commentaire à l’objet

void deleteComments() //supprime tous les commentaires reliés à l’objet

Doctrine_Collection findComments(array $params, array $orders) //retourne tous les commentaires liés à l’objet, respectant les paramètres du tableau params, et classés successivement dans les ordres donnés par le tableau orders

int getNbComments() //retourne le nombre de commentaires liés à l’objet

CommentForm getCommentForm()

Fourni par le plugin :

La classe Comment :

getParent() pour récupérer l’objet porteur du commentaire

La classe CommentTable :

getCommentsFilteredQuery($params, $orders) pour récupérer une requête permettant de retrouver une collection de commentaires selon certains paramètres, et en respectant une suite d’ordres

getUnmoderatedCommentsQuery() pour récupérer une requête permettant de retrouver la collection des commentaires non modérés

getSpamCommentsQuery() pour récupérer la collection des commentaires classés spam
Le modèle de données :

Comment:
  tableName: sf_comment
 
  actAs: [Timestampable]
 
  columns:
    user_id:
      type: integer(4)
 
    #nom de l'auteur
    author_name:
      type: string(255)
      default: Anonyme
    #email de l'auter
    author_mail:
      type: string(255)
    #site web de l'auteur
    author_website:
      type: string(255)
 
    #texte du commentaire
    text:
      type: clob
 
    #id de l'objet porteur du commentaire
    parent_id:
      type: integer
    #classe de l'objet porteur du commentaire
    parent_class_name:
      type: string(255)
 
    #publié ?
    is_published:
      type: boolean
      notnull: true
      default: true
    #modéré ?
    is_moderated:
      type: boolean
      notnull: true
      default: false
    #est un spam ?
    is_spam:
      type: boolean
      notnull: true
      default: false
 
  relations:
    sfGuardUser:
      type: one
      foreignType: many
      local: user_id
      foreign: id
      foreignAlias: Comments

La technique pour relier un objet à cette table Comment est d’utiliser 2 champs spéciaux : parent_class_name et parent_id qui contiennent le nom de la classe ainsi que l’identifiant en base de l’objet porteur du commentaire.

De cette manière, on perd en partie l’aspect relationnel de la base, mais on allège énormément les requêtes de listing (derniers commentaires toutes catégories confondues, commentaires reliés à un objet, reliés à un type d’objet, …).
Comment ça marche :

télécharger les sources
Avant de commencer, il faut évidemment copié les sources du plugin dans le répertoire plugin/ de votre projet, puis :

php symfony plugin:publish-assets

Tout d’abord, il faut activer le module dans les settings, en l’ajoutant comme ceci :

all:
  .settings:
    enabled_modules: [default, sfGuardAuth, sfGuardUser, comment]

Ensuite dans le schema.yml du projet, il faut spécifier le behavior sur l’objet :

Message:
  actAs:
    Timestampable: ~
    Commentable: ~
  columns:
    …

A partir de là, on utilisera les fonctions et méthodes vues plus haut (fournies par le template).

Le plugin fournit des partials pour l’affichage par défaut, personnalisable via les noms de classes et id passables en paramètres (toutes les classes et id sont définies par défaut si pas d’options) :

Partial show_comment, paramètres :
$comment : le message à afficher
$options : les options spécifiques pour css personnalisé
show_comment_class → conteneur global
infos_class → entete (auteur, date et heure)
author_name_class → auteur
time_and_date_class → date et heure
date_class → date
time_class → heure
text_class → corps du commentaire

Partial comments_list, paramètres : (boucle sur le partial show_comment, donc passer en parametre les options pour le show_comment)
$comments : la liste des messages à afficher
$options : les options spécifiques pour css personnalisé
list_comment_class : classe de la div conteneur
list_comment_id : id de la div conteneur

Partial form_comment, paramètres :
$form : le formulaire
$action : l’action du formulaire, définie par défaut
$options : les options spécifiques pour css personnalisé
id → id du formulaire
class → classe du formulaire

Partial ajax_script, paramètres : script jquery permettant de valider le formulaire en ajax
$form : le formulaire

Partial ajax_form_comment, paramètres : le formulaire et le script ajax

Exemple d’utilisation :

  <!-- // liste des commentaires du message -->
  <?php include_partial('comment/comments_list', array('comments'=>$message->findComments(array(), array('created_at DESC')), 'options'=>array())) ?>
 
  <!-- // formulaire d'ajout de commentaire -->
  <div id="form<?php echo $message->getId() ?>">
    <h2>Postez votre commentaire :</h2>
    <?php include_partial('comment/ajax_form_comment', array('form'=>$message->getCommentForm())) ?>
  </div>

Vous aurez noté qu’on ne parle pas encore de l’administration dans ce post, dans les publications à venir je vous parlerai d’abord du backend pour les commentaires, puis de la réalisation d’un behavior étape par étape.

Je me suis par contre amusé à coder un petit validator, qui il me semble, se couple bien avec le sfMailer : sfValidatorEmailList. Son nom est assez explicite mais pourquoi tester des listes de mails ? Tout simplement parceque sfMailer permet d’envoyer des mails groupés !

  /**
   * Creates a new message.
   *
   * @param string|array $from    The from address
   * @param string|array $to      The recipient(s)
   * @param string       $subject The subject
   * @param string       $body    The body
   *
   * @return Swift_Message A Swift_Message instance
   */

Dans les commentaires de la fonction compose() on peut voir que l’on a la possibilité de passer un string ou un tableau. sfValidatorEmailList va ainsi nous permettre de valider une liste de mails séparés par un caractère quelconque.

Tout d’abord je vais créer un formulaire classique qui me permettra de saisir les adresses emails, le sujet et le corps de mon email.

 
class lkInvitationForm extends sfForm
{
 
    public function setup()
    {
 
        if ( ! $this->getOption('mailer') instanceof sfMailer )
        {
            throw new RuntimeException('A valid mailer option is required to send an email from this form');
        }
 
        $this->setWidgets(array(
            'email'         => new sfWidgetFormInputText(array('label' => 'Adresse(s) email')),
            'title'         => new sfWidgetFormInputText(array('label' => 'titre du mail')),
            'body'          => new sfWidgetFormTextarea(array('label' => 'Corps du mail')),
            ));
 
        $this->setValidators(array(
            'email'   => new sfValidatorEmailList(array('required' => true), array('invalid' => '"%value%" invalide')),
            'title'    => new sfValidatorString(array('required' => true), array('invalid' => '"%value%" invalide')),
            'body'    => new sfValidatorString(array('required' => true), array('invalid' => '"%value%" invalide')),
            ));
 
        $this->widgetSchema->setNameFormat('invitation[%s]');
        $this->errorSchema = new sfValidatorErrorSchema($this->validatorSchema);
    }
 
    /**
     * Bind form and send mail
     *
     * @param sfWebRequest $request
     */
    public function bindAndSend(array $taintedValues = array())
    {
        $this->bind($taintedValues);
        if ( $this->isValid() )
        {
            $mailer = $this->options['mailer'];
            return $mailer->composeAndSend('contact@lexik.fr', $this->getValue('email'), $this->getValue('title'), $this->getValue('body'));
        }
 
    }
 
}

J’utilise donc pour mon email le sfValidatorEmailList dont voici le code :

 
class sfValidatorEmailList extends sfValidatorEmail
{
 
  /**
   * @see sfValidatorEmail
   */
    protected function configure($options = array(), $messages = array())
    {
        parent::configure($options, $messages);
 
        $this->addOption('separator', ',');
    }
 
  /**
   * @see sfValidatorString
   */
    public function doClean($value)
    {
        $retVal = array();
        $valueError = array();
        $mails = explode($this->getOption('separator'), $value);
 
        foreach ($mails as $mail)
        {
            try
            {
                $retVal[] = parent::doClean(trim($mail));
            }
            catch (sfValidatorError $e)
            {
                $valueError[] = $e->getValue();
            }
        }
 
        if ( ! empty ($valueError) )
        {
            throw new sfValidatorError($this, 'invalid', array('value' => implode(', ', $valueError)));
        }
 
        return $retVal;
    }
 
}

Quelques explications :

Au niveau de la configuration on peut indiquer quel sera le caractère de séparation. Ensuite, la fonction doClean() qui se charge de tester la validité d’une valeur va transformer le string que l’on récupère en tableau et va appeler le doClean de sfEmailValidator. Afin de permettre un rendu plus propre du message d’erreur, j’utilise un try-catch qui me permet de lister tous les emails invalides. Une fois la boucle terminée, je n’ai plus qu’a créer mon exception avec toutes les valeurs catchées.
Je peux par la suite passer le $this->getValue(‘email’) à ma fonction composeAndSend() puisque le validator me retourne un tableau.

Exemple d’une erreur dans un seul email

Exemple d’une erreur dans plusieurs emails

Maintenant lorsque j’affiche mon formulaire, les utilisateurs pourront saisir des adresses emails séparées d’une virgule pour envoyer à plusieurs contacts.