Utilisation de sfUser et de ses « namespace »(s)

yoye — Mon, 08 Feb 2010 15:06:29 +0000

Récemment j’ai du développer un outil permettant de créer des tournois, cet outil a la particularité d’être accessible par les personnes connectés ou non. Je devais conserver d’une page à l’autre les informations saisies par mon utilisateur, pour quelqu’un de connecté on peut toujours passer par la base de donnée mais pour les autres on doit jouer avec la classe sfUser.

Le scénario est le suivant :
- Etape 1 : je saisis des informations dans un formulaire
- Etape 2 : je saisis de nouvelles informations en fonction des précédentes

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 :

^?View Code YML

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 :

^?View Code 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 :

^?View Code PHP

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

^?View Code PHP

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

Symfony et les tâches

yoye — Wed, 01 Apr 2009 10:42:53 +0000

Pour un projet récent j’ai du implémenter un script qui devait insérer des utilisateurs dans la base d’un projet symfony. Afin de conserver l’avantage des objets et de leur validator je n’ai pas effectué un script à base de ‘INSERT INTO’ mais j’ai bel et bien créé ma propre tâche.
Je ne vais pas dans cette article vous parler de la façon de créer les tâches pour cela je vous renvoie vers le cookbook aucune excuse pour ne pas le lire, il a été traduit en français mais je vais vous parler de la façon dont je l’ai implémenté dans mon application.

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 :

^?View Code YML

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 :

^?View Code BATCH

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

^?View Code PHP

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

^?View Code PHP

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

^?View Code PHP

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

^?View Code YML

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.

^?View Code 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()

^?View Code PHP

    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 :

^?View Code PHP

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

^?View Code BATCH

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

^?View Code PHP

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

^?View Code BATCH

./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é :

^?View Code PHP

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

Blog Symfony - Lexik Montpellier » méthode magique

Utilisation de sfUser et de ses « namespace »(s)

Symfony et les tâches