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

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

Voici le résultat :

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

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

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

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

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

Je crée donc l’helper suivant :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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.

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.

Symfony étant un Framework et non un CMS on ne trouve pas énormément d’informations concernant le SEO. Cependant pour quelques sites que Lexik a lancé récemment nous nous sommes penché un peu sur l’optimisation de notre référencement.

Attention il ne s’agit la que de quelques conseils primaires rien de bien révolutionnaire. Prétendre ressortir premier sur Google en quelques lignes et serait un pure escroquerie.

Pour commencer j’ai voulu éclaircir quelques chose qui me perturbe depuis que je travaille sur Symfony. La balise META title. Elle est présente dans un projet Symfony mais je ne l’avais vu quasiment nulle part auparavant.
Un exemple simple tapez des mots extrèmement concurrentiel sur votre moteur de recherche préféré : « Jeux d’argent », « Location immobilière ». Sur la première page des résultats si on regarde la source des pages on peut voir que la majorité ont la balise <title></title> en première position dans leur header et que la quasi totalité n’ont pas de balise META title.

L’explication qui semble la plus plausible et que ces deux balises ont la même fonction et que les moteurs de recherche pourraient interpréter la présence des deux balises comme du spam, en gros on essaye de caser nos mots clés en quantité anormale.

J’ai donc cherché comment régler ce problème et je suis tombé sur un post qui correspondait exactement à ce que je voulais : Removing META name=title tag in Symfony for SEO Simplement il y a une petite retouche à faire dans le code fourni, ce qui donne :

<?php
class myWebResponse extends sfWebResponse
{
    public function getMetas()
    {
        $meta_tags = $this->metas;
 
        if (array_key_exists('title', $meta_tags))
        {
            unset($meta_tags['title']);
        }
        return $meta_tags;
    }
}

Il nous faut ensuite modifier notre fichier factories.yml pour lui indiquer quelle classe utiliser :

prod:
  response:
    class: myWebResponse

Et voilà le tour est joué. On se retrouve maintenant avec uniquement la balise

Pour rester dans les META je vous conseille de modifier votre fichier view.yml dans votre application afin d’être sur d’avoir des META sur toutes les pages.

default:
  metas:
    title:        Le titre de mon site
    description:  la description de mon site
    keywords:     site, symfony

Maintenant google et les autres moteurs de recherche, oui oui il en existe d’autres, n’aiment pas que l’on est des META en double en gros ils n’aiment pas retrouver les mêmes descriptions ou titre d’une page à l’autre. Donc de manière générale je définis les META pour chaque page à partir de l’action.

1

$this->getContext()->getResponse()->addMeta('description', 'La description de mon site');

Ensuite de manière à ce que le moteur de recherche tombe en premier sur mes mots clés j’ai tendance à modifier un peu mon layout.php et l’ordre des includes, je précise que ce n’est en rien une vérité :

1
2
3
4
5
6

    <head>
        <?php include_title() ?>
        <?php include_metas() ?>
        <?php include_http_metas() ?>
        <link rel="shortcut icon" href="/favicon.ico" />
    </head>

Une fois encore je précise que ce ne sont là pas des vérités absolus, juste des mise en pratique d’observations.

De plus cette semaine j’ai vu qu’un plugin spécial SEO venait de sortir csSEOToolkitPlugin je n’ai pas eu le temps de le tester mais je compte bientôt le faire, peut être ce sera le sujet d’un prochain post, en attentant si certains ont des feed-back à partager sur ce plugin, ils peuvent les partager via les commentaires.

Il serait maintenant intéressant de pouvoir l’utiliser dans une application et également de pouvoir suivre l’évolution de notre tâche.

Pour lancer la tâche nous avions dans un premier penser la lancer grâce à la fonction proc_open() de PHP qui inclut une gestion des logs assez intéressante. Nos premiers tests en local se sont déroulés sans problèmes mais une fois en production il semble que la configuration du serveur ne permette pas d’utiliser cette commande.
On s’est donc rabattus sur la façon qui semble la plus utilisée :

 
chdir(sfConfig::get('sf_root_dir')); 
$myTask = new importExecuteTask(sfContext::getInstance()->getEventDispatcher(), new sfFormatter());
$myTask->run(array(), array());

Il est important de ne pas oublier le chdir() pour permettre l’exécution de notre tâche.

La première étape est donc terminée, on a pu lancer notre tâche depuis notre application, on va maintenant s’intéresser à suivre l’évolution de celle-ci.
Pour cela je vais créer un fichier que j’appelerai lock.txt dans mon répertoire d’import et je vais même l’utiliser comme compteur. Pour des raisons que nous verrons un peu plus bas, je vais créer une constante dans la classe de ma tâche qui correspondra au nom du fichier.

 
const LOCK_FILE = 'lock.txt';

Au début de ma boucle je donc avoir le code suivant :

 
$handle = fopen($options['file'], 'r');
fopen($arguments['import_dir'].'/'.self::LOCK_FILE, 'x');
while (($data = fgetcsv($handle, 5000, ";")) !== false)
{
 /* Mon code d'insertion */
}

Bon ok on a notre fichier mais à quoi nous sert-il ?
On peut dès à présent l’utiliser pour faire un redirect dans notre action pour empêcher de lancer plusieurs tâches en même temps :

 
$this->redirectIf(is_file('chemin/de/mon/dossier/import'.'/'.importExecuteTask::LOCK_FILE), 'import/loading');

Ici je redirige vers une page « loading » qui permettra de faire « patienter » notre utilisateur.

On vient de voir la première utilisation de notre fichier lock on va maitenant l’utiliser pour suivre l’évolution de la tâche. Pour cela je vais utiliser un compteur dans la boucle de ma tâche et l’écrire dans mon fichier. Il me faut tout d’abord obtenir le nombre maximum de mon fichier CSV.

 
            $handle = fopen($arguments['import_dir'].$file, 'r');
            $contenu_fichier = fread($handle, filesize($arguments['import_dir'].$file));
            $max = substr_count($contenu_fichier, "\n");
            fclose($handle);

Dans ma boucle je vais maintenant incrémenter mon compteur et mettre tout ça dans notre fichier lock :

 
$count = 0;
while (($data = fgetcsv($handle, 5000, ";")) !== false)
{
//- Début de mon code
 
file_put_contents($arguments['import_dir'].self::LOCK_FILE, $count.'/'.$max);
 
$count++;
}

Maintenant que mon fichier contient les informations nécessaires je vais les utiliser dans l’action :

 
        $filename = sfConfig::get('app_chemin_import').'/'.importExecuteTask::LOCK_FILE;
        if (is_file($filename))
        {
            $handle = fopen($filename , 'r');
 
            $moyenne = fread($handle, filesize($filename));
 
            $a = explode("/", $moyenne);
 
            $this->content = floor(($a[0] * 100) / $a[1]);
 
            fclose($handle);
 
        }

Voilà maintenant lorsque l’utilisateur sera redirigé vers notre page d’attente. On pourra lui afficher le pourcentage de l’évolution de la tâche. Petit problème si l’on veut suivre en direct cette évolution on va recharger la page indéfiniment ? Non pour cela on va utiliser un Helper Javascript : periodically_call_remote()

On va donc créer une action page progess qui ne sera appeler que par le javacript et qui sera inclut dans notre page « loading » par l’appel d’un component ce qui nous donnera :

// actions.class.php
 
    public function executeProgress()
    {
 
        $filename = sfConfig::get('app_chemin_import').'/lock.txt';
        if (is_file($filename))
        {
            $handle = fopen($filename , 'r');
 
            $moyenne = fread($handle, filesize($filename));
 
            $a = explode("/", $moyenne);
 
            $this->content = floor(($a[0] * 100) / $a[1]);
 
            fclose($handle);
 
        }
}

Notre template :

 
<div style="width: 220px;">
<div style='width:<?php echo $content ?>%; background-image: url(/images/progress.gif); float: left;'><?php echo $content ?> %</div>
</div>

Une div qui contiendra une image gif que l’on fera grandir au fur et à mesure tel une barre de progression.
Et pour terminer notre page d’attente :

 
<?php use_helper('Javascript') ?>
 
<div id="progress"></div>
 
<?php echo periodically_call_remote(array(
   'frequency'  => '1',
   'update'     => 'progress',
   'url'        => 'import/progress'
)) ?>

Tout les secondes la div va donc être rafraîchie en appelant notre page progress ce qui simulera l’évolution de notre tâche.

Pour terminer, il ne faudra surtout pas oublier de supprimer le fichier lock à l’aide d’un petit unlink().

Il s’agit donc d’un projet très simple listant des profils d’utilisateur pour lesquels on spécifie des dates d’inscription à une option.

Voici donc le schéma que l’on obtient :

Utilisateur:
actAs:
Timestampable:  ~
columns:
civilite:         { type: string(5)}
nom:              { type: string(150)}
prenom:           { type: string(150)}
email:            { type: string(255), unique: true}
profession:       { type: string(255)}
adresse:          { type: string(255)}
code_postal:      { type: string(10)}
ville:            { type: string(100)}
pays:             { type: string(5)}
date_naissance:   { type: date}
telephone:        { type: string(30)}
site_inscription: { type: string(255)}
option1:         { type: Date}
option2:         { type: Date}
option3:         { type: Date}
option4:         { type: Date}

On a vu plus compliqué comme schéma. Le but de ma tâche est donc de récupérer des fichiers CSV et de les insérer dans ma base de données. On va commencer par créer notre tâche :

./symfony generate:task import:execute

On se retrouve donc avec notre class importExecuteTask dans le dossier : /lib/task
Dans la partie configure je vais d’abord définir l’option file qui va définir le fichier CSV que je veux importer :

new sfCommandOption('file', null, sfCommandOption::PARAMETER_REQUIRED, 'Nom du fichier a traiter', '')

Maintenant passons à la partir qui va se charger de l’import. Dans un premier temps création de ma boucle

$handle = fopen($options['file'], 'r');
while (($data = fgetcsv($handle, 5000, ";")) !== false)
{
 /* Mon code d'insertion */
}

Je veux que les utilisateurs déjà existant soit juste mis à jour pour les autres ils seront créé.

$user = Doctrine::getTable('Utilisateur')->createQuery('c')
->andWhere('c.email = ? ', $data[0])->fetchOne();
 
if (!$user)
{
  $user =new Utilisateur();
}
$user->setEmail($data[0]);
$user->setPrenom($data[1]);
 /* Etc pour chaque champs */

Je veux maintenant préciser les options et pouvoir en ajouter dans le futur assez facilement. Pour cela je vais mettre dans mon fichier apps/monApplication/modules/monModule/config/app.yml la liste de mes options :

all:
  option: [option1, option2, option3, option4]

Je vais ensuite définir un attribut dans ma tâche, n’oublions pas que c’est une classe et que symfony ou pas il n’en reste pas moins qu’on peut lui définir des attributs, j’insiste sur ce point car je pense que c’est une des difficultés quand on débute avec symfony, ne pas oublier que l’on est dans du PHP.

private static $app_yml = array();

Maitenant que l’attribut est crée on va lui attribuer la valeur contenu dans le fichier app.yml graĉe à la classe sfYaml()

    protected function configure()
    {
       self::$app_yml = sfYaml::load(sfConfig::get('sf_root_dir').'/apps/backend/config/app.yml');
// suite du code ...

Mais à quoi cela peut-il servir ? Et bien par exemple à créer des options à la volée :

protected function configure()
    {
       // Début du code
        foreach (self::$app_yml['all']['option'] as $option)
        {
            $this->addOption($option,null,sfCommandOption::PARAMETER_OPTIONAL, 'Valeur pour '.$option, false);
        }
 
     // Suite du code

Je me retrouve maintenant avec 4 options supplémentaires que l’on peut vérifier en tapant la commande

./symfony help import:execute

Maintenant que nous avons créé ces options autant les utiliser mais il faut que cela soit dynamique pour cela on va utiliser les méthodes magiques dans ma boucle qui insère les utilisateurs :

// debut du code
 foreach (self::$app_yml['all']['option'] as $option)
{
  if ($options[option])
  {
    $user->__get($option, date('Y-m-d'));
  }
}
// fin du code

Maintenant lorsque que je vais appeler ma tâche je peux préciser les options auxquelles correspond mon fichier CSV.

./symfony import:execute --option1="true"

Pour terminer voilà un petit conseil pour le traitement de masse et la création multiple d’objet. En fin de boucle une fois que votre objet ne sera plus utiliser ajouté :

// debut du code
$user->free();
unset($user);
// fin de ma boucle

Ceci évitera certains problèmes de mémoire.

En conclusion :

Dans le futur si des options supplémentaires sont nécessaires je pourrais simplement rajouter une colonne dans ma base de données et compléter mon fichier app.YML. Il est bien évident que l’on pourrait faire cette gestion dans la base de données directement avec une table lié et une relation 1-1. Mais ici le but été de voir également la possibilité de charger un fichier YML depuis un autre module voir même d’ailleurs.

Le but est d’obtenir un site (un bout de site) qui nous permette de faire un listing de recettes et cela dans différentes langues, on va se contenter du français et de l’anglais. Il faut d’abord commencer par le schéma :

 Recipe:
  actAs:
    I18n:
      fields: [name, body, is_activated]
    actAs:
      Sluggable: { fields: [name], uniqueBy: [lang, name] }
  columns:
    name: { type: string(255)}
    body: { type: clob}
    is_activated: { type:boolean, notnull: true, default: 0}

Le schema est très simple il n’y aucune relation avec d’autres tables, ce qui nous intéressent ici c’est le traitement I18N et les formulaires. Petite remarque : – Je passe le is_activated, qui indique si la recette est active ou non, dans le actAs I18N ainsi les recettes par langue seront totalement indépendantes. – Le sluggable est passé également en deuxième niveau d’actAs pour permettre à chaque langue d’avoir son propre slug. – Dernier point, il ne faut surtout pas mettre de unique : true dans la partie columns de notre schema, sinon on va se retrouver à ne pas pouvoir mettre à jour une langue indépendament de l’autre. Maintenant que l’on visualise le schéma et donc les classes qui en découlent on va parler code. Comme on en a l’habitude on va générer nos modèles, notre CRUD de recettes. On va maintenant s’attaquer à notre classe RecipeForm.class.php, on veut que l’utilisateur n’ai pas à rentrer les recettes dans les deux langues mais uniquement dans la sienne. Pour cela il faut lui afficher uniquement le formulaire rattaché à sa culture. Modifions notre classe:

 class RecipeForm extends BaseRecipeForm
 {
   private $lang; 
 
   public function __construct($lang = 'fr')
   {
      $this->lang = $lang; 
 
      parent::__construct();
   }
 }

La première étape est donc de redéfinir le constructeur de notre classe auquel on va soumettre une langue par défaut et de créer un attribut privé pour définir la langue ($lang). On va maintenant définir l’affichage de notre formulaire en modifiant la fonction configure()

public function configure()
{
  if (!is_array($this->lang))
  {
    $cultures = array($this->lang);
  }
  else
  {
    $cultures = $this->lang;
  } 
 
  foreach ($cultures as $culture)
  {
    $i18nObject = $this->object->Translation[$culture];
    $i18n = new RecipeTranslationForm($i18nObject);
    unset($i18n['id'], $i18n['lang'], $i18n['is_activated']);
    $i18n->widgetSchema['name'] = new sfWidgetFormInput(array(), array('size'=> 60));
    $i18n->widgetSchema['body'] = new sfWidgetFormTextarea(array(), array('cols'=> 58,'rows'=> 12));
    $this->embedForm($culture, $i18n);
  }
}

Dans notre action on va appeler ce formulaire comme suit :

public function executeNew(sfWebRequest $request)
{
  $this->culture = $this->getUser()->getCulture();
  $this->form = new RecipeForm($this->culture);
}

Vous noterez que l’on passe la culture en attribut ainsi on peut le récupérer dans le template :

render()

Il vous suffit de mettre désormais tout les champs et les label à afficher et le tour est joué.