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.

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.