Lexik c’est qui ?
Une société basée à Montpellier depuis 5 ans, avec 10 personnes et une ambiance sympa.

On fait quoi chez Lexik ?
Nous sommes spécialisés dans le développement d’applications web en Symfony2. Nos projets reposent sur les méthodes agiles et un développement de qualité via la mise en place de tests unitaires et fonctionnels.

Quels types de clients ?
Des start-ups qui recherchent un appui technique sur la mise en place de leur projet, des PME et collectivités locales ayant un besoin d’accompagnement en conseil et réalisation.

Lexik, c’est quoi d’autre ?
Des scrum meetings quotidiens, des points techniques presque tous les mardi, des idées communes pour des projets internes, du développement en équipe et comme dirait Laurent, le vendredi c’est sushis !

Et si on résumait tout ça techniquement :

• spécialistes du framework Symfony2 ;
• contributions à des bundles Open Source sur Github ;
• un blog technique ;
• développement frontend avec jQuery, Twitter Bootstrap, websockets, etc. ;
• méthodes agiles avec Scrum ;
• intégration continue avec Jenkins et tests fonctionnels avec Behat.

Description du poste :

Vous êtes motivé et passionné par votre métier, vous suivez avec attention l’évolution des frameworks et des derniers langages à la mode. Vous avez déjà travaillé en équipe et vous aimez ça.

Vous bénéficiez d’une bonne expérience à titre privé ou professionnel dans les technologies suivantes :

• PHP 5.3, OOP ;
• HTML5 / CSS3 ;
• SQL (MySQL, SQLite, PostgreSQL, …).

Une expérience ou un intérêt dans les domaines suivants seront un atout :

• Framework symfony 1.4 / Symfony2 avec l’ORM Doctrine ou Propel2 ;
• Gestionnaire de version (Git / SVN) ;
• Javascript, jQuery, node.js ;
• Tests unitaires et fonctionnels, intégration continue, Behat ;
• Méthodologie de développement agile (Scrum).

Détails :

Envoyez-nous votre CV et lettre de motivation par email à l’adresse : recrutement@lexik.fr

• Type de contrat : CDI
• Lieu : Pérols
• Début du contrat : ASAP
• Télétravail : non
• Rémunération : selon profil

Voici le LexikMaintenanceBundle qui a pour but d’activer et désactiver la mise en maintenance de votre site. Quand un site à besoin pour X raisons d’être mis en maintenance, par exemple lors d’une mise à jour, vous allez pouvoir faire apparaître une page d’erreur où seront redirigés les visiteurs avec la possibilité d’en autoriser certains.

Pourquoi utiliser un bundle pour gérer la maintenance ?

Il existe de nombreuses manières de mettre un site Internet en maintenance, comme par exemple en éditant le .htaccess ou le virtual host. Symfony 1 proposait une mise en maintenance en ligne de commande et cette fonctionnalité n’a pas été reprise dans sa version 2, l’idée de ce bundle est de proposer une fonctionnalité similaire tout en laissant plus de souplesse, via l’utilisation de drivers et d’un service.

Nous avons choisi de créer ce bundle car nous voulions laisser aux utilisateurs plusieurs alternatives de mise en maintenance, ainsi que son activation depuis la console ou depuis le backend par exemple.

Fonctionnement

Un listener

Le bundle utilise un listener qui écoute l’événement onKernelRequest avec une priorité evelée pour être ainsi le premier à être appelé. Le listener va tout d’abord vérifier s’il y a des adresses IP autorisées à consulter le site en maintenance. Si oui, l’utilisateur peut continuer. Dans le cas contraire on va demander au driver utilisé dans la configuration de vérifier si la maintenance a été activé et de décider si on lève une exception qui retournera un status 503. Sinon on laisse passer l’utilisateur.

Des drivers

Un driver est une méthode choisie pour activer/désactiver la maintenance. Le bundle propose trois drivers différents.

• Le premier est le FileDriver dont l’utilisation consiste à créer un fichier quelque part et à vérifier si celui-ci existe.
• Le second est le MemCacheDriver qui utilise MemCache et qui va regarder si une donnée a été stockée dans le serveur de cache.
• Le troisième est le DatabaseDriver qui va créer une table dans une base de données et vérifier les informations présentes à l’intérieur.

Il y a d’autres implémentation de drivers possibles, libre à chacun de créer le sien.

Options

TTL

Chaque driver a la possibilité d’avoir un temps limite pour la durée de la maintenance -par défaut il n’y en a pas-. Cette option est le ttl -time to life- qui peut être modifié soit dans votre configuration soit dynamiquement via la console par exemple. (A l’exception du FileDriver).

IP autorisées

Vous avez la possibilité, comme écrit plus haut, d’ajouter dans un tableau des adresses IP qui seront autorisées à consulter le site.

Installation et configuration

L’installation se fait comme pour tous les autres bundle Symfony2 à l’aide des fichiers deps et deps.lock.

Fichier deps:

Enregistrer le namespace:

Activer le bundle:

Pour la configuration, les options de bases requises sont la classe du driver et les options qui iront avec.

Remarques pour la configuration:

• Pour utiliser la connexion Doctrine, vous n’êtes pas obligé de passer des options, vous pouvez écrire simplement le nom de la classe du driver.
• Pour utiliser une table existante sur une autre base de données (option dsn), vous devez avoir un champ ttl dans votre table.
• Pour le FileDriver, vous ne pouvez pas changer la durée en mode console, seulement pour DatabaseDriver et MemCacheDriver

Utilisation

Ce service met à disposition les méthodes `lock()` et `unlock()` permettant d’activer et désactiver le mode maintenance de votre site. L’intérêt majeur de ce service est qu’il vous permet de l’utiliser dans le contexte de votre choix, libre à vous d’implémenter une interface de backend permettant d’activer la maintenance. LexikMaintenanceBundle propose en standard les commandes console suivantes:

lexik:maintenance:lock qui aura pour effet d’appeler la méthode lock().

lexik:maintenance:unlock aura l’effet inverse.

Pour la vue

Element important de la maintenance, une page d’erreur à afficher. Lorsque le listener lève une exception avec le status 503, Symfony2 va afficher par défaut la vue error.html.twig située dans le bundle TwigBundle. Vous pouvez alors définir une vue appelée error503.html.twig dans app/Resources/TwigBundle/views/Exception/ qui sera appelée à la place.

Astuce: Cela fonctionne aussi pour les erreurs 404, 403 etc…

Information: Nous ne proposons pas de vue par défaut, c’est à vous d’en créer une.

Pour plus le reste, voici le lien vers les sources Github.

Pourquoi utiliser la base de données ?

En effet, pourquoi utiliser la base de données au lieu d’éditer directement les fichiers de traduction ? Lorsque votre site sera en production des modifications pourront être faites grâce à l’interface d’édition, cependant les développeurs seront potentiellement amenés à ajouter de nouvelles traductions dans les fichiers. Donc si on édite directement les fichiers de traduction un problème risque de se présenter: lors des mises en ligne, comment ajouter les nouvelles traductions sans perdre les modifications faites depuis l’interface d’édition ? (sans compter le fait que Apache devra avoir les droits en écriture sur les fichiers).
C’est pour cela que nous avons choisi de charger les traductions en base de données. De cette façon l’administrateur du site peut modifier les traductions à son gré et les développeurs peuvent à tout moment ajouter de nouvelles entées dans les fichiers.

Fonctionnement

Le bundle redéfinit le service de traduction de Symfony (translator) et fournit un loader pour charger les traductions depuis la base de données.
Les traductions présentes en base de données sont chargées en dernier, elles prennent donc le dessus sur les traductions des fichiers xliff, yml ou php. Le bundle fournit aussi une interface d’édition et d’ajout de traductions avec une intégration de jqGrid 4.2.0.
L’ajout de traduction dans la base de données se fait soit par l’interface, soit en ligne de commande avec une tâche qui va importer vos fichiers de traduction dans la base de données.

Utilisation

Lors de votre développement créez vos fichiers de traductions au moins pour une langue (la langue par défaut du site par exemple). Ensuite lancez la tâche d’import pour ajouter les nouvelles traductions en base de données. Une fois importées les traductions sont éditables dans l’interface, vous pouvez donc modifier les traductions pour toutes les langues gérées par le bundle.
Une traduction n’est éditable que si elle est présente dans la base de données, donc si vous ajoutez de nouvelles entées dans vos fichiers de traduction il faudra relancer la tache d’import.

Note: lors de la modification d’une traduction via l’interface il sera nécessaire de cliquer sur le bouton « invalidate cache » afin de prendre en compte le changement de la traduction (surtout en environnement de production).

Installation et configuration

L’installation se fait comme pour tous les autres bundle Symfony2 à l’aide des fichiers deps et deps.lock.
Au niveau de la configuration il vous faudra au minimum définir la langue par défaut (fallback_locale) et les langues que le bundle doit gérer (managed_locales), comme ci-dessous :

# app/config/config.yml
lexik_translation:
    fallback_locale:  fr
    managed_locales:  [fr, en]

Il est aussi possible de configurer certaines classes utilisées par le bundle dans le cas où vous souhaitez redéfinir des éléments (entité et/ou service).

Pour plus de détail sur cette partie je vous invite à lire la doc sur le dépot Github.

Votre profil :

De formation BTS / DUT ou école d’ingénieur, vous justifiez d’une expérience significative dans le milieu du développement Web.

Vous bénéficiez d’une bonne expérience à titre privé ou professionnel dans les technologies suivantes :

• XHTML / CSS ;
• PHP 5, orienté objet ;
• SQL (MySQL, SQLite, PostgreSQL, …).

Une expérience ou un intérêt dans les domaines suivants seront un atout :

• Framework symfony 1.4 / Symfony2 avec l’ORM Doctrine ;
• Gestionnaire de version (Git / SVN) ;
• Javascript ;
• Tests unitaires et fonctionnels / Intégration continue ;
• Méthodologie de développement agile (SCRUM).

Détails :

Envoyez-nous votre CV et lettre de motivation par email à l’adresse : contact@lexik.fr

• Type de contrat : CDI
• Lieu : Pérols
• Début du contrat : ASAP
• Télétravail : non
• Rémunération selon profil

http://www.lexik.fr/

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.

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

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.

De formation initiale informatique (de bac à +5), vous êtes un développeur confirmé en PHP/MySQL (environnement LAMP et WAMP) avec une expérience d’au moins 1 ans au sein d’une SSII ou d’une web agency.

Compétences requises :
- Framework PHP Symfony
- bonnes connaissances des environnements WAMP (Windows) et LAMP
- MySQL et SQL
- PHP (programmation objet)
- (X)HTML, DHTML , JavaScript, CSS.
- AJAX
- Javascript, jQuery
- standards du web (W3C)
- Connaissance de subversion

Qualités recherchées :
- curiosité
- force de proposition
- sens du travail en équipe

Disponibilité :
- ASAP

Poste à Montpellier 34000

Contactez Samuel Breton, Tél : 04 67 99 63 19
Email : contact@lexik.fr
CV + LM

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.

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

La Homepage

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

Accueil du backoffice : Statistiques et accés

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

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

Un listing précis et concis

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

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

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

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

Les filtres au service de la navigation

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

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

Comment cela est-il possible ?

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

Mise en place

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

    public function executeIndex(sfWebRequest $request) {
        if($request->getParameter('filter')) {
            $this->setFilters($request->getParameter('filter'));
        }
        parent::executeIndex($request);
    }

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

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

@user_user?filter[is_active]=0

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

@project_project?filter[state][text]=1

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

Allez plus loin

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

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

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

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

    public function executeIndex(sfWebRequest $request) {
        sfConfig::set('sf_escaping_strategy', false);
        if($request->getParameter('filter')) {
            $this->setFilters($request->getParameter('filter'));
        }
        parent::executeIndex($request);
    }

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

Mise à jour

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

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

display: [_countComments]

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

<?php echo link_to($article->getComments()->count(), '@comments_comments?filter[article_id]='.$article->getId());?>

Pour vous situer, il s’agit d’un site de vente en ligne.
Qui dit vente dit produits, et qui dit produits dit photos

L’idée est de gérer les photos d’un produit directement depuis sa page d’édition de l’admin générator.

On a choisi de gérer l’upload avec swfUpload qui gére un liste d’attente pour l’upload de plusieurs fichiers. Et l’upload en background qui ne gèle pas la page, ca fait plus web2.0 :p
(http://code.google.com/p/swfupload/)

J’ai téléchargé le SWFUpload v2.2.0.1 Samples.zip et j’ai utilisé les fichiers du répertoire « simpledemo » que j’ai réparties comme suis.
(Le fichier css d’origine s’appelait default.css, je l’ai renommé pour des raisons évidentes.)

• /web/swf/swfupload.swf
• /web/css/swfUpload.css
• /web/js/swfupload.js
• /web/js/swfupload.queue.js
• /web/js/fileprogress.js
• /web/js/handlers.js
• /web/images/XPButtonUploadText_61x22.png

Un coup d’oeil rapide à la partie du schema.yml qui nous intéresse. Rien de transcendant, un objet Produit avec quelques champs types et l’objet ProduitPhoto qui lui est lié. Sur l’objet ProduitPhoto, un filename et un booléen pour définir l’image par défaut du produit.

...
Produit:
  tableName:        monprojet_produit
  actAs:
    Timestampable:  ~
  columns:
    id:             { type: integer(4), unsigned: true, primary: true, autoincrement: true }
    nom:            { type: string(255), notnull: true }
    description:    { type: clob }
    prix:           { type: decimal, scale: 2 }
 
ProduitPhoto:
  tableName:        monprojet_produit_photo
  columns:
    id:             { type: integer(4), unsigned: true, primary: true, autoincrement: true }
    produit_id:     { type: integer(4), unsigned: true }
    filename:       { type: string(255), notnull: true }
    is_default:     { type: boolean, default: false }
  relations:
    Produit:
      local:        produit_id
      foreign:      id
      foreignAlias: Photos
      onDelete:     CASCADE
...

On génére l’admin-generator pour l’objet produit.

./symfony doctrine:generate-admin backend Produit

Et c’est partie !

Pour rajouter cette gestion des images dans l’ecran d’édition des produits il faut rajouter un partial à la vue edit.
(On la rajoute uniquement sur l’edit, car sur l’écran create, l’objet n’est pas encore persisté en base et donc on ne peut pas lui rattacher des objets ProduitPhoto)

Le fonctionnement est le suivant. Le partial général où est inclus et configuré swfUpload (_photoUpload.php). Un parial _photoListe.php inclus dans _photoUpload.php qui servira pour raffraichir la liste en ajax (avec jQuery). Et un dernier partial _ajaxPhotoDelete.php qui ne sert qu’a retourner l’animation à faire lors de la suppression d’une photo.

On commence par positionner le partial _photoUpload.php dans le generator.yml en contexte edit.

generator:
  class: sfDoctrineGenerator
  param:
    model_class:           Produit
    theme:                 admin
    non_verbose_templates: true
    with_show:             false
    singular:              ~
    plural:                ~
    route_prefix:          produit_produit
    with_doctrine_route:     1
 
    config:
      actions: ~
      fields:
        created_at:        { label: Date de création, date_format: dd/MM/yyyy }
        updated_at:        { label: Date de modification, date_format: dd/MM/yyyy }
        nom:               { label: Nom }
        description:       { label: Déscription }
      list:
        title:             Liste des produits
        display:           [=id, =nom]
      filter: ~
      form: ~
      edit:
        title:             Modifier un produit
        display:
          "Produit":       [id, nom, description]
          "Photos":        [_photoUpload]
          "Dates":         [created_at, updated_at]
      new:
        title:             Ajouter un produit
        display:
          "Produit":       [id, nom, description]
          "Dates":         [created_at, updated_at]

Et on va se pencher plus en détail sur ce partial _photoUpload.php.

<?php use_stylesheet('swfUpload.css') ?>
 
<?php use_javascript('jquery.js') ?>
<?php use_javascript('jquery-ui.js') ?>
<?php use_javascript('swfupload.js') ?>
<?php use_javascript('swfupload.queue.js') ?>
<?php use_javascript('fileprogress.js') ?>
<?php use_javascript('handlers.js') ?>
 
<div id="pictures_list" class="sf_admin_form_row">
  <?php include_partial('produit/photoListe', array('photos' => $form->getObject()->getPhotos())) ?>
</div>
 
<div id="picture_upload" class="sf_admin_form_row">
  <div class="fieldset flash" id="fsUploadProgress"><span class="legend">File d'attente.</span></div>
  <div id="divStatus">0 fichier uploadé.</div>
  <div>
    <span id="spanButtonPlaceHolder"></span>
    <input id="btnCancel" type="button" value="Cancel All Uploads" onclick="$.swfUpload.cancelQueue();" disabled="disabled" style="margin-left: 2px; font-size: 8pt; height: 29px;" />
  </div>
</div>
 
<script type="text/javascript">
 
(function($) {
 
  $('div.actions a.default').live('click', function(event) {
    event.preventDefault();
    $.post(
      $(this).attr('href'),
      { },
      function(data) {
        $('#pictures_list').html(data);
      }
    );
  });
 
  $('div.actions a.delete').live('click', function(event) {
    event.preventDefault();
    if(confirm('Etes vous sur de vouloir supprimer cette photo ?')) {
      $.post(
        $(this).attr('href'),
        { },
        function(data) {
          eval(data);
        }
      );
    }
  });
 
  myQueueComplete = function(numFilesUploaded) {
    var status = document.getElementById("divStatus");
    status.innerHTML = numFilesUploaded + " fichier" + (numFilesUploaded === 1 ? "" : "s") + " uploadé" + (numFilesUploaded === 1 ? "" : "s") + ".";
 
    $.post(
      '<?php echo url_for('produit_ajax_photo_liste', $form->getObject()) ?>',
      { },
      function(data) {
        $('#pictures_list').html(data);
      }
    );
  };
 
  jQuery.swfUpload = new SWFUpload({
    flash_url: "/swf/swfupload.swf",
    upload_url: "<?php echo url_for('produit_photo', $form->getObject()) ?>",
    post_params: {"<?php echo ini_get('session.name') ?>" : "<?php echo session_id(); ?>"},
    file_size_limit: "100 MB",
    file_types: "*.jpg;*.gif;*.png",
    file_types_description: "Fichiers image",
    file_upload_limit: 10,
    file_queue_limit: 0,
    file_post_name: 'photo',
    custom_settings: {
      progressTarget: "fsUploadProgress",
      cancelButtonId: "btnCancel"
    },
    debug: false,
    // Button settings
    button_image_url: "/images/XPButtonUploadText_61x22.png",
    button_width: "61",
    button_height: "22",
    button_placeholder_id: "spanButtonPlaceHolder",
    // The event handler functions are defined in handlers.js
    file_queued_handler: fileQueued,
    file_queue_error_handler: fileQueueError,
    file_dialog_complete_handler: fileDialogComplete,
    upload_start_handler: uploadStart,
    upload_progress_handler: uploadProgress,
    upload_error_handler: uploadError,
    upload_success_handler: uploadSuccess,
    upload_complete_handler: uploadComplete,
    queue_complete_handler: myQueueComplete
  });
 
})(jQuery);
 
</script>

Il faut penser à inclure les différents éléments nécessaires le css et les tout les js. Je les ai inclus ici pour bien les mettre en évidence.
Après il suffit de positionner les différents éléments html nécessaires au fonctionnement de swfUpload.
Et enfin le javascript pour initialiser swfUpload. J’utilise jQuery pour gérer l’ajax, j’ai donc adapté l’initialisation de swfUpload pour la rendre « jQuery friendly » :p

L’initialisation de swfUpload est assez standard, avec toute une tripoté de paramètres pour définir : le type de fichier accepté, configurer l’apparence du bouton et configurer tous les retour d’événements qu’il est possible d’utiliser.
J’ai laissé les gestionnaires d’événements par défaut à l’exception de l’événement de fin d’upload (myQueueComplete) que j’ai redéfini pour faire un appel ajax et recharger le partial _photoListe.php.
J’attire votre attention sur le parametre post_params auquel on passe le session name et le session_id, on verra un peu plus bas le pourquoi du comment

Le partial _photoListe.php, rien de spécial. Un listing des photos du produit avec 2 liens pour supprimer ou définir comme image par défaut, les 2 faisant appel à une action en ajax.
(NB: On retrouve le Helper Thumb de thomas pour les miniatures des photos)

<?php use_helper('Thumb') ?>
 
<?php if($photos->count() > 0): ?>
<?php foreach( $photos as $photo ): ?>
<div id="photo-<?php echo $photo->getId()?>" class="picture">
  <?php echo showThumb(
  $photo->getFilename(),
  'produits',
  array(
    'height' => 120,
    'width'  => 120,
    'alt'    => $photo->getProduit()->getNom(),
    'title'  => $photo->getProduit()->getNom(),
    'border' => 0
  ),
  'center',
  'produit-defaut.jpg') ?>
  <div class="actions">
    <?php if($photo->isDefault()): ?>
    <strong><img src="/images/backend/star.png" align="left" /> Par défaut</strong>
    <?php else: ?>
    <ul>
      <li><a href="<?php echo url_for('produit_photo_ajax_default', $photo) ?>" class="default"><img src="/images/backend/star.png" align="left" /> Par défaut</a></li>
      <li><a href="<?php echo url_for('produit_photo_ajax_delete', $photo) ?>" class="delete"><img src="/images/backend/cross.png" align="left" /> Supprimer</a></li>
    </ul>
    <?php endif; ?>
  </div>
</div>
<?php endforeach; ?>
<div class="clear"></div>
<?php else: ?>
<p>Aucune photo pour l'instant.</p>
<?php endif; ?>

Le partial _ajaxPhotoDelete.php, c’est juste l’effet jQuery-ui pour faire disparaitre la div de la photo qui viens d’être supprimée.

$('#photo-<?php echo $photo_id ?>').effect('drop');

Un petit tour sur le routing.yml pour défnir les différentes routes utilisées.

...
produit_photo:
  url:     /produit/:id/upload
  class:   sfDoctrineRoute
  options: { model: Produit, type: object }
  param:   { module: produit, action: upload }
  requirements:
    sf_method: [get, post]
 
produit_photo_ajax_default:
  url:     /produit_photo/:id/default
  class:   sfDoctrineRoute
  options: { model: ProduitPhoto, type: object }
  param:   { module: produit, action: ajaxPhotoDefault }
  requirements:
    sf_method: [post]
 
produit_photo_ajax_delete:
  url:     /produit_photo/:id/delete
  class:   sfDoctrineRoute
  options: { model: ProduitPhoto, type: object }
  param:   { module: produit, action: ajaxPhotoDelete }
  requirements:
    sf_method: [post]
 
produit_ajax_photo_liste:
  url:     /produit_photo/:id/list
  class:   sfDoctrineRoute
  options: { model: Produit, type: object }
  param:   { module: produit, action: ajaxPhotoListe }
  requirements:
    sf_method: [post]
...

On utilise la classe formulaire qui va gérer l’upload.
Il faut désactiver le csrf car l’envoie n’est pas effectué par le formulaire mais par l’animation flash.

<?php
 
class ProduitPhotoForm extends BaseProduitPhotoForm
{
  public function configure()
  {
    $this->widgetSchema['produit_id'] = new sfWidgetFormInputHidden();
    $this->widgetSchema['is_default'] = new sfWidgetFormInputHidden();
    $this->widgetSchema['filename'] = new sfWidgetFormInputFile(array());
 
    $this->validatorSchema['filename'] = new sfValidatorFile(array(
      'required'   => true,
      'path'       => sfConfig::get('sf_upload_dir').'/produits/source',
      'mime_types' => 'web_images',
      'max_size'   => 10485760
    ), array(
      'max_size' => 'Fichier trop gros (10Mo maximum).'
    ));
 
    $this->disableCSRFProtection();
  }
}

Et enfin l’action.class.php qui orchestre tout ca.
Au niveau de l’action executeUpload il faut créer « à la main » le tableau des paramètres à passer au bind.

<?php
 
require_once dirname(__FILE__).'/../lib/produitGeneratorConfiguration.class.php';
require_once dirname(__FILE__).'/../lib/produitGeneratorHelper.class.php';
 
/**
 * produit actions.
 *
 * @package    
 * @subpackage produit
 * @author     
 * @version    SVN: $Id: actions.class.php 12474 2008-10-31 10:41:27Z fabien $
 */
class produitActions extends autoProduitActions
{
 
  public function executeUpload(sfWebRequest $request)
  {
    $this->produit = $this->getRoute()->getObject();
    $this->forward404unless($this->produit);
 
    $this->form = new ProduitPhotoForm();
 
    $values = array(
      'produit_id' => $this->produit->getId(),
      'is_default' => ($this->produit->getPhotos()->count() > 0) ? false : true,
      'filename'   => $request->getFiles('photo')
    );
 
    $this->form->bind($values, $values);
 
    if ($this->form->isValid())
    {
      $photo = $this->form->save();
 
      $return = 'ok';
    }
    else
    {
      $return = 'ko';
    }
 
    return $this->renderText($return);
  }
 
 
  /**
   * ajax pour definir une photo par defaut
   *
   * @param sfWebRequest $request
   */
  public function executeAjaxPhotoDefault(sfWebRequest $request)
  {
    if($request->isXmlHttpRequest())
    {
      $photo = $this->getRoute()->getObject();
      $produit = $photo->getProduit();
 
      $old_default = $produit->getPhotoDefault();
 
      $produit->setPhotoDefaut($photo->getId());
 
      return $this->renderPartial('produit/photoListe', array('photos' => $produit->getPhotos()));
    }
    else
    {
      $this->redirect404();
    }
  }
 
 
  /**
   * ajax pour effacer une photo
   *
   * @param sfWebRequest $request
   */
  public function executeAjaxPhotoDelete(sfWebRequest $request)
  {
    if($request->isXmlHttpRequest())
    {
      $photo = $this->getRoute()->getObject();
      $photo_id = $photo->getId();
      $photo->delete();
 
      return $this->renderPartial('produit/ajaxPhotoDelete', array('photo_id' => $photo_id));
    }
    else
    {
      $this->redirect404();
    }
  }
 
 
  /**
   * ajax pour avoir la liste des photos
   *
   * @param sfWebRequest $request
   */
  public function executeAjaxPhotoListe(sfWebRequest $request)
  {
    if($request->isXmlHttpRequest())
    {
      $produit = $this->getRoute()->getObject();
 
      return $this->renderPartial('produit/photoListe', array('photos' => $produit->getPhotos()));
    }
    else
    {
      $this->redirect404();
    }
  }
 
 
}

Produit.class.php

<?php
 
class Produit extends BaseProduit
{
 
  public function setPhotoDefaut($photoId)
  {
    Doctrine_Query::create()
    ->update('ProduitPhoto p')
    ->set('p.is_default', '?', false)
    ->where('p.produit_id = ?', $this->getId())
    ->execute();
 
    Doctrine_Query::create()
    ->update('ProduitPhoto p')
    ->set('p.is_default', '?', true)
    ->andWhere('p.id = ?', $photoId)
    ->execute();
 
    return true;
  }
 
  public function getPhotoDefault()
  {
    return Doctrine::getTable('ProduitPhoto')->getDefault($this->getId());
  }
 
}

ProduitPhotoTable.class.php

<?php
 
class ProduitPhotoTable extends Doctrine_Table
{
 
  public function getDefault($produit_id)
  {
    return $this->createQuery('c')
      ->andWhere('c.produit_id = ?', $produit_id)
      ->andWhere('c.is_default = ?', true)
      ->fetchOne();
  }
 
}

ProduitPhoto.class.php

<?php
 
class ProduitPhoto extends BaseProduitPhoto
{
 
  public function isDefault()
  {
    return (bool) $this->getIsDefault();
  }
 
}

Le problème !

A ce stade, tout est fini et en place pour que ca marche. Hors ca ne marche pas… Pourquoi ? Je rapelle le contexte, on est dans l’admin donc on est identifié et c’est là le problème. En effet swfUpload est une animation flash contenu dans le page mais qui va initialiser des requêtes http parallèles à celle utilisée par le navigateur. Et donc lorsque swfUpload se pointe à l’url « produit_photo » pour initialisé son upload, il se prend une belle erreur 403…

Le problème est connu des concepteurs de swfUpload et la solutions qu’ils préconisent est de forcé l’identifiant de session dans le script d’upload en faisant un session_id($session_id). C’est pourquoi on le fait passer dans la variable « post_params » à l’initialisation de swfUpload.

Pour faire la même chose dans symfony on ne peut pas le faire dans une action, car la session est déjà initialisée à ce niveau. On est obligé d’aller modifié le factories.yml et la calsse la classe sfSessionStorage pour aller forcer l’identifiant de session dans le cas ou on fait appel à l’action upload.

C’est un tip que j’ai trouvé sur le forum symfony qui était pour la version 1.0, et qui fonctionne toujours à la différence que le contexte n’est plus passé en paramètre dans la 1.2 et donc il faut aller le charger.

factories.yml

...
all:
...
  storage:
    class: mySessionStorage
    param:
      session_name: weezobackend
...

mySessionStorage.calss.php

<?php
 
class mySessionStorage extends sfSessionStorage
{
  public function initialize($options = null)
  {
    $context = sfContext::getInstance();
 
    //Shitty work-around for swfuploader
    if( $context->getActionName() == "upload")
    {
      $sessionName = $parameters["session_name"];
 
      if($value = $context->getRequest()->getParameter($sessionName))
      {
        session_name($sessionName);
        session_id($value);
      }
    }
 
    parent::initialize($options);
  }
}

Ça y est, cette fois ça marche !
Et vous avez une gestion d’images directement dans la fiche du produit qui est assez user-friendly

Merci d’avoir lu jusqu’au bout :p
Je reste à votre disposition pour toute questions ou suggestions
@bientôt !

A quoi ça sert ?

Tout simplement à la gestion des cookies de session.

pourquoi l’utiliser ?

Récemment j’ai du développer un projet qui contenait plusieurs applications, 3 pour commencer et elles peuvent se multiplier par la suite. Cela n’a rien de choquant tous les projets on généralement un minimum de 2 applications, un backend et un frontend.
Ce qui peut s’avérer très vite ennuyeux, en effet pour peu que l’on souhaite être connecté en tant qu’admin sur notre backend et en tant qu’utilisateur lamda sur notre frontend, il va falloir se déconnecter assez souvent, ce qui a la longue devient fastidieux.

C’est là qu’intervient notre sfSessionStorage.

Comment le configurer ?

Ce qui est intéressant dans l’utilisation des cookies de session c’est leur simplicité d’utilisation grâce au framework. Pour cela il va falloir modifier le fichier factories.yml.

# apps/frontend/config/factories.yml
 
all:
#début de ma config
  storage:
    class: sfSessionStorage
    param:
      session_name: frontend
 
# apps/backend/config/factories.yml
 
all:
#début de ma config
  storage:
    class: sfSessionStorage
    param:
      session_name: backend

Je me retrouve désormais avec des cookies différents pour chaque application ce qui va me permettre de me connecter sur chacune de mes applications avec des utilisateurs différents.

Autres cas pratiques

On peut bien évidemment étendre cette solution sur les environnements. En effet on peut avoir besoin d’être connecté sur une même application avec deux types d’utilisateurs. Imaginons que j’ai besoin de tester sur mon frontend les différents crédentials que j’ai ajouté à mon application. Je peux me créer des environnements pour chacun de ces crédentials comme par ex : rédacteur et administrateur.
Je vais de nouveau modifier mon fichier factories.yml et le champs d’application ne va plus se faire sur toute l’application mais sur un environnement.

redac:
  storage:
    class: sfSessionStorage
    param:
      session_name: redacteur
admin:
  storage:
    class: sfSessionStorage
    param:
      session_name: administrateur

Dans un soucis de simplicité j’ai raccourci le nom des environnements. Il me faut pour terminer créer mes deux environnements. Je vais pour cela créer les fichiers frontend_redac.php et frontend_admin.php dans le dossier web qui contiendront :

// environnement redac
require_once(dirname(__FILE__).'/../config/ProjectConfiguration.class.php');
 
$configuration = ProjectConfiguration::getApplicationConfiguration('frontend', 'redac', true);
sfContext::createInstance($configuration)->dispatch();
 
// environnement admin
require_once(dirname(__FILE__).'/../config/ProjectConfiguration.class.php');
 
$configuration = ProjectConfiguration::getApplicationConfiguration('frontend', 'admin', true);
sfContext::createInstance($configuration)->dispatch();

Je pourrai maintenant être connecté sur mon application avec 2 comptes différents.

L’utilisation de la classe sfSessionStorage peut donc s’avérer très utile comme je l’ai dis plus tôt dans un cadre de développement pour faciliter la navigation entre les différentes configuration que l’on peut retrouver sur notre application quant à son utilisation en production chacun fera en fonction de ses besoins bien évidemment.

Mais quand on voit la simplicité de la mise en place il serait dommage de s’en passer.

Pourquoi utiliser RSync ?

A l’instart du FTP, rsync permet d’effectuer une synchronisation distante basée sur des sauvegardes incrémentales. En clair, à l’aide d’une seule commande, vous pouvez mettre à jour sur votre serveur, seulement l’ensemble des fichiers modifiés depuis votre dernière synchonisation.

Rsync utilise le protocole SSH permettant une communication sécurisée lors du transfert des fichiers. Un autre avantage indéniable par rapport au protocole FTP beaucoup trop bavard sur le réseau, lors de la transmission de vos paramètres d’authentification.

Outre le confort et la rapidité du déploiement par rsync, il ne faut pas oublier son support natif par Symfony.

Configuration RSync

Avant de voir les différents paramètres de configuration, nous allons rapidement installer ce petit utilitaire via notre gestionnaire de packet sur notre Debian-Like :

apt-get install rsync

Pour les paramètres de connection, il faut  créer/modifier le fichier config/properties.ini :

[maconfig]
name=MonSite
author=Lexik.fr
host=66.249.64.0                               #IP du serveur
port=22                                        #Port par default pour ssh
user=votre-login                               #Utilisateur qui se connectera au serveur de destination
dir=/home/lexik/domains/lexik.fr/public_html   #Dossier qui recevera le projet symfony sur le serveur de destination
type=rsync                                     #Type de deploiement

Symfony permet de spécifier les dossiers à exclure lors de la synchronisation. Créer/Modifier le fichier config/rsync_exclude.txt :

.svn
/web/uploads/*
/web/*_dev.php
/cache/*
/log/*
.DS_Store
.cache
.project
.settings

Nous allons ensuite tester nos paramètres de configuration. Cette commande est utile pour effectuer une simulation du transfert. Cela signifie que rien ne sera synchronisé :

php symfony project:deploy maconfig

Nous y voila, effectuez votre rsynchronisation :

php symfony project:deploy maconfig --go

Et voila !

Déploiement sans spécifier le mot de passe

Dans un souci d’automatisation de synchronisation, il peut être embêtant de se faire demander le mot de passe serveur à chaque déploiement par rsync (ou même lorsque l’on souhaite se connecter au serveur directement par SSH).

Dans cette logique, on peut utiliser une encryption asymétrique (clé publique, clé privée) afin de rester « connu » par le serveur:
On génère le couple de clé en local avec la commande :

ssh-keygen -t rsa

On garde le chemin par défault pour la sauvegarde des clés, et nous n’aurons pas besoin dans notre cas de passphrase, en vue d’une possible automatisation des synchronisations.

Les 2 clés sont donc générées dans ~/.ssh/

Il suffit alors de copier la clé publique sur le serveur, dans le répertoire courant de l’utilisateur avec lequel on se connecte.

Voici une procédure possible avec scp (man scp pour plus d’information) :

scp /home/moi/.ssh/id_rsa.pub monlogin@ip-du-server:.ssh/authorized_keys

(Il faudra peut être créer le dossier .ssh à la racine du dossier personnel de l’utilisateur).

Bugs courant :

Agent admitted failure to sign using the key.

Peut se produire alors que la clé publique a bien été transmise au serveur (le bug semblerait provenir du client SSH natif d’ubuntu: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/201786).

Voici la commande salvatrice :

export SSH_AUTH_SOCK=0

En savoir plus

• Cryptographie asymétrique
• Pratical symfony : Day 23

Mais concentrons nous d’abord sur sfFilter. Comme on peut le voir en parcourant rapidement le code c’est une classe abstraite on ne pourra donc l’utiliser que part héritage.
Les filters sont en fait une couche du Framework qui permet d’effectuer des actions avant ou après l’affichage d’une page, ce qui peut s’avérer très pratique.

On va donc partir d’un exemple simple :
Imaginons deux sites internet, un site A qui va faire une redirection vers mon site B. Sur mon site B les utilisateurs peuvent s’inscrire et j’ai besoin de stocker le site de provenance, ce qui va se faire à l’aide d’un cookie.
Une méthode primaire pourrait consister à faire une page qui va poser le cookie et faire la redirection. Seulement le jour ou je souhaite que mon site A redirige vers une page précise de mon site B il va falloir que je vienne changer le code.
Heureusement sfFilter est là !

Grâce à cette couche du framework je vais pouvoir créer une classe que je vais appeler TrackerFilter et qui va me faire tout le traitement nécessaire. Voici le code :

class TrackerFilter extends sfFilter {
     public function execute($filterChain) {
        $context = $this->getContext();
        $request = $context->getRequest();
 
        if ($this->isFirstCall() && $request->getParameter('r'))
        {
            $user = $context->getUser();
 
            if (!$request->getCookie('reservation'))
            {
                $time = time()+60*60*24*7;
                $context->getResponse()->setCookie('reservation', $request->getParameter('r'), $time);
            }
        }
        $filterChain->execute();
    }
}

Que se passe t’il dans ces quelques lignes de code ?

Notre classe va hériter de sfFilter (obligatoire)

On va créer une function execute avec en paramètre $filterchain qui va nous permettre d’exécuter le code souhaité (obligatoire)

On récupère le « context » et le « request » ce qui va nous permettre de vérifier si le cookie existe déjà et de le poser dans le cas contraire

On exécute le filter (obligatoire)

Quelques précisions supplémentaires :
La fonction isFirstCall() permet de vérifier si c’est la première exécution du filter.
Le placement de la ligne

$filterChain->execute();

a son importance puisqu’elle permet de signifier si l’on souhaite que le filter s’exécute avant ou après l’action.

Maintenant il ne nous reste plus qu’à configurer notre filter, pour cela il faut modifier le fichier apps/APPLICATION/config/filters.yml qui d’origine contient :

rendering: ~
security:  ~
 
# insert your own filters here
 
cache:     ~
common:    ~
execution: ~

Ce qui semble assez explicite pour savoir ou écrire notre configuration. On va donc compléter ce fichier comme suit :

rendering: ~
security:  ~
 
TrackerFilter:
  class:  TrackerFilter
 
cache:     ~
common:    ~
execution: ~

Nous avons donc vu comment utiliser les filters avec un cas pratique simple mais qui est un cas qu’un développeur web va rencontrer souvent. Cette façon de faire laisse donc une certaine flexibilité et permet une fois de plus d’avoir un code simple, clair et factorisé.
On trouve là tout la puissance de Symfony.

Pour ceux qui sont intéressés par d’autres cas d’utilisation de sfFilter vous pouvez bien sûr vous reportez sur le livre. Vous y verrez qu’il est possible grâce aux filters de faire des redirection, ou encore d’ajouter du code sur notre page.

Dans mon précédent post j’évoquais les différentes possibilités d’inclure le javascript dans les vues.

• Mettre des balises <script> directement au milieu du html (un peu crade mais efficace)
• Faire un fichier .js « en dur » dans le dossier /web/js (mais là on perd la possibilité d’utiliser du php)
• Utiliser un slot dans le <head> du template
• Utiliser une vue

C’est ce dernier point que je vous propose de voir aujourd’hui.

Pour se dessiner un petit background on va prendre l’exemple d’une vue index dans un module d’actualités.
Dans cette vue on veut faire un appel ajax sur un lien et on veut utiliser le routing pour définir l’url du script à appeler.

On va donc utiliser une action et deux vues, une pour la page html et une pour le javascript qui sera inclus dans la vue html. On utilise des sf_format différents.

On créé la route qui servira pour les deux vues (/app/frontend/config/routing.yml).

...
actu_index:
  url:   /actualites/index.:sf_format
  param: { module: actu, action: index, sf_format: html }
...

Dans notre action on récupère juste les dernières actualités à afficher dans la page html (/app/frontend/modules/actu/actions/actions.class.php).

<?php
 
class actuActions extends sfActions
{
 
  public function executeIndex(sfWebRequest $request)
  {
    $this->actus = Doctrine::getTable('Actu')->getLast();
  }
 
}

La vue Html. C’est la que ca se passe ! On fais un use_javascript() auquel on passe le url_for() de la même vue en spécifiant juste le sf_format à ‘js’ (/app/frontend/modules/actu/templates/indexSuccess.php).

<?php use_javascript(url_for('@actu_index?sf_format=js')) ?>
<div class="liste_actus">
  <?php foreach($actus as $actu): ?>
    <div class="actu">
      <h3><?php echo $actu->getTitre() ?></h3>
      <p><?php echo $actu->getTexteCourt() ?></p>
      <div class="action"><?php echo link_to('Lire la suite', '@actu_detail') ?><div>
    </div>
  <?php endforeach; ?>
</div>

Et donc la vue js sera inclue par la vue html qui rajoute dans le head l’appel au fichier.

<script type="text/javascript" src="/actualites/index.js"></script>

Il ne reste plus qu’a faire la script javascript dans la vue /app/frontend/modules/actu/templates/indexSuccess.js.php ou on peut avoir accès à tous les éléments de symfony que l’on désire.

Par exemple là un peut appel ajax en jQuery ou je récupère l’url du script appelé grâce au routing.

jQuery(function() {
 
  $('div.action a').click(function(event) {
    event.preventDefault();
    $.post(
      '<?php echo url_for('@actu_detail') ?>',
      { url: $(this).attr('href') },
      {},
      'script'
    );
  });
 
});

Il se peut que dans la vue javascript on n’ait pas besoin d’exécuter toute l’action.
Par exemple ici, dans ma vue javascript, je n’ai pas besoin des dernières actualités, il est donc possible de filtrer pour alléger l’action grâce au sf_format.

<?php
 
class actuActions extends sfActions
{
 
  public function executeIndex(sfWebRequest $request)
  {
    if($request->getParameter('sf_format') != 'js')
    {
      $this->actus = Doctrine::getTable('Actu')->getLast();
    }
  }
 
}

Après, libre a chacun de voir si on doit utiliser la même action que la vue html ou si la vue javascript nécessite sa propre action.

En utilisant une action séparée pour la vue javascript on peut s’amuser à pousser le vice du camouflage en utilisant un routing qui fasse croire que l’on appelle un fichier .js (Attention si jamais un fichier avec le même nom existe réellement dans le répertoire /web/js c’est ce dernier qui sera inclus).

...
actu_index_js:
  url:   /js/actu.:sf_format
  param: { module: actu, action: index, sf_format: js }
...

Avantage de cette technique :

• Un code source html super « clean »

Inconvéniant :

• Pour une page html, on fait deux appels à symfony.
  A utiliser avec parcimonie et bien optimiser les actions pour ne pas faire des requêtes inutiles sur la base de donnée.

Il gère les :

• Histogrammes
• Graphique en courbes
• Graphiques en secteurs
• Graphiques en barres
• Graphiques en aires

Les graphiques générés sont entièrement paramétrables : choix des couleurs , des titres .

L’installation du plugin est très simple :

symfony plugin:install stOfcPlugin

puis

symfony cc

Ensuite , dans le template où l’on veut afficher le graphique on copie la ligne suivante :

<code>
stOfc::createChart(500, 300, 'quiz_sondage/pieChartData?slug='.$quiz-&gt;getSlug(), fal
</code>

Les premiers paramètres correspondent à la taille du graphique tandis que le second correspond à la route qui appelle la fonction qui génèrera le graphique.

Si vous ne voulez pas définir une route supplémentaire vous pouvez appelez la fonction comme ceci : module/action

Le readme du contient des exemples pour bien commencé :

http://www.symfony-project.org/plugins/stOfcPlugin

Ce plugin est basé sur un projet open-source, voici l’adresse :

http://teethgrinder.co.uk/open-flash-chart/

Le site contient toute la doc nécessaire

Et voici l’adresse du forum d’aide : ( ça peut toujours servir )

http://forums.openflashchart.com/

Autre solution pour faire des graphique sans flash : jpgraph

Pour télécharger la libraire jpgraph : http://www.aditus.nu/jpgraph

On va donc voir comment l’utiliser avec sympfony :

Télécharger la dernière realease pour PHP5

Dans un premier temps copier le dossier jpgraph obtenu après la décompression de l’archive dans le dossier lib de votre projet

Faites un symfony cc

dans le template voulu copier la ligne suivante :

<code>
<img class="graph" src="&lt;?php echo url_for('@actionSouhaité'); ?&gt;" alt="" />
</code>

 » />

@actionSouhaité = la route appelant l’action qui va générer l’image.

Maintenant on va voir un modèle d’action pour génèrer l’image :

public function executeGraph(sfWebRequest $request)
    {
 
      $i=0;
      $ydata=array(); // Tableau des valeurs
      $xdata=array(); // Tableau axis ( légénde des valeurs )
 
      // Code pour remplir les tableau comme vous voulez    
 
     // Création du graph type courbe
      $graph = new Graph(1300,400,"auto");
      $graph->SetScale("textlin");
      $graph->title->Set('Evolution du nombre d\'inscription');
      $graph->title->SetFont(FF_FONT1,FS_BOLD);
      $line = new LinePlot($ydata);
      $graph->Add($line);
      $line->SetColor("#36393D");
      $line->SetWeight(2);
      $graph->xaxis->setTickLabels($xdata);
 
      // Output graph
      $graph->Stroke();
 
      return sfView::NONE; // Important pour que l'action retourne que le code de l'image
    }

Vite fait, le schéma utilisé :

...
Region:
  tableName:  region
  actAs:
    Sluggable:
      unique: true
      fields: [nom]
  columns:
    id:       { type: integer(4), unsigned: true, primary: true, autoincrement: true }
    nom:      { type: string(255), notnull: true }
 
Departement:
  tableName: departement
  actAs:
    Sluggable:
      unique: true
      fields: [nom]
  columns:
    id:        { type: integer(4), unsigned: true, primary: true, autoincrement: true }
    nom:       { type: string(255), notnull: true }
    region_id: { type: integer(4), unsigned: true }
  relations:
    Region:
      local:        region_id
      foreign:      id
      foreignAlias: Departements
      onDelete:     CASCADE
...

Juste pour mettre en évidence la relation entre le Département et la Région, avec le très important le foreignAlias que j’aime tant

Pour faire fonctionner tout ça on va avoir besoin de :
– 1 route
– 1 action minuscule
– 1 partial de 4 lignes
– 1 tout petit bout de javascript

La route :

# routing.yml
...
ajax_departement:
  url:   /ajax/departement
  param: { module: lambda, action: ajaxDepartement }
...

L’action :

// actions.class.php
 
  /**
   * requete ajax pour avoir la liste des déparements de la région
   *
   * @param sfWebRequest $request
   */
  public function executeAjaxDepartement(sfWebRequest $request)
  {
    $region = Doctrine::getTable('Region')->findOneById($request->getParameter('region'));
    return $this->renderPartial('lambda/selectDepartement', array('region' => $region));
  }

Le partial :

// _selectDepartement.php
<option value=""></option>
<?php foreach($region->getDepartements() as $departement): ?>
<option value="<?php echo $departement->getId() ?>"><?php echo $departement->getNom() ?></option>
<?php endforeach; ?>

Et enfin le petit bout de code jQuery à rajouter au formulaire :

<script language="javascript">
$(document).ready(function(){
  $("#mon_formulaire_lambda_region_id").change( function() {
    $.post("/ajax/departement", { region: $(this).val() },
    function(data){
      $("#mon_formulaire_lambda_departement_id").html(data);
    });
  });
});
</script>

Pour le javascript plusieurs solutions. Soit l’inclure directement dans la vue avec les balises comme je l’ai fait ici.
Soit faire un fichier .js que l’on met dans /web/js/mon_fichier.js (bien mais pas top ).

Le plus « propre » est de faire une vue et d’utiliser le sf_format et d’inclure le fichier via une route.
On verra ça lors d’un prochain post

@bientôt !

NB : Bien entendu il faut que jQuery soi inclus :
– Soit il est inclus dans le view.yml
– Soit directement dans la vue avec un use_javascript(‘jQuery.js’)