Blog Symfony2 - Lexik Montpellier » 1.2.x

Tips : Conversions de devises

Nikaw — Mon, 17 May 2010 12:29:10 +0000

Aujourd’hui je vous montre juste une petite astuce pour avoir les taux de conversion de l’Euro vers d’autres devises.

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

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

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

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

^?View Code PHP

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

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

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

^?View Code PHP

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

Pour tester :

^?View Code PHP

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

Et voilà !

Valider un numéro de TVA intracommunautaire

Nikaw — Mon, 03 May 2010 08:23:01 +0000

Aujourd’hui il est courant d’avoir à développer des sites avec abonnement, mise à disposition de service payant en ligne et autre, à l’échelle internationale et à des professionnels.

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

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

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

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

Le validator

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

Commençons par voir la méthode __construct :

^?View Code PHP

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

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

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

^?View Code PHP

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

Testons

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

^?View Code PHP

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

Voici l’action :

^?View Code PHP

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

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

^?View Code PHP

<form action="" method="post">
  <table>
     echo $form ?>
    <tr>
      <td>td>
      <td>
        <input type="submit" value="Tester" />
      td>
    tr>
  table>
form>

Et voilà !

Retour sur le plugin Commentaires, partie administration

Nikaw — Wed, 31 Mar 2010 08:39:13 +0000

J’espère que vous vous souvenez du post concernant le plugin / behavior sfLexikDoctrineActAsCommentablePlugin.
Je vous avais promis une deuxième partie sur l’administration des commentaires, et bien après quelques mois d’absence me revoilà pour tenir ma promesse.

Tout d’abord un peu de configuration, puis nous verront quelles sont l’utilité et la problématique principales de cette partie.
Nous verrons l’administration des commentaires dans leur ensemble, puis la gestion des commentaires depuis l’objet porteur.

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

^?View Code YAML

all:
  .settings:
    enabled_modules: [..., comment]

Problématique

On veut ici pouvoir gérer facilement et rapidement les commentaires déposés par les utilisateurs.
Une des problématiques sera donc la façon de lister les commentaires sur l’index.
J’ai choisi par défaut de regrouper les commentaires par type d’objet, puis par objet, puis par date de modification.

Exemple : je liste tous les commentaires déposé sur les objets Message, je les regroupe par message, et je les classe par date de modification (la plupart du temps, un commentaire ne pouvant être modifié, on aura une concordance entre la date d’ajout et la date de modification).

Pour ceci, je spécifie dans le fichier de génération la méthode utilisée pour récupérer les commentaires :
plugins/sfLexikDoctrineActAsCommentablePlugin/module/comment/config/generator.yml :

^?View Code YAML

generator:
  config:
    list:
      table_method: retrieveBackendCommentList

La méthode en question :
plugins/sfLexikDoctrineActAsCommentablePlugin/lib/model/doctrine/PluginCommentTable.class.php :

^?View Code PHP

  public function retrieveBackendCommentList()
  {
    $query = $this->createQuery('c')
            ->orderBy('c.parent_class_name ASC')
            ->addOrderBy('c.parent_id ASC')
            ->addOrderBy('c.updated_at DESC');
 
    return $query;
  }

Nous allons maintenant nous pencher sur les différents traitements que je propose.
Il s’agit ici de publier / censurer, marquer comme spam / non spam, nettoyer les spams, et bien sûr supprimer des commentaires.

Tout d’abord je vous donne la configuration que j’ai choisie pour l’index, évidemment vous pouvez choisir de la changer, elle représente mes préférences rapportées au projet pour lequel j’ai créé ce plugin.
plugins/sfLexikDoctrineActAsCommentablePlugin/module/comment/config/generator.yml :

^?View Code YAML

generator:
  class: sfDoctrineGenerator
  param:
    model_class:           Comment
    theme:                 admin
    non_verbose_templates: true
    with_show:             false
    singular:              ~
    plural:                ~
    route_prefix:          comment
    with_doctrine_route:     1
 
    config:
      actions: ~
      fields:
      list:
        table_method: retrieveBackendCommentList
        display: [author_name, author_mail, text, is_published, is_spam]
        fields:
          author_name: {label: 'Nom auteur'}
        actions:
          _delete: ~
          CleanSpam: {label: 'Nettoyer les spams'}
        object_actions:
          Publish: {label: 'Publier'}
          UnPublish: {label: 'Censurer'}
          MakeSpam: {label: 'Spam !'}
          UnmakeSpam: {label: 'Pas spam'}
          _delete: ~
        batch_actions:
          _delete: ~
          Publish: {label: 'Publier'}
          UnPublish: {label: 'Censurer'}
          MakeSpam: {label: 'Marquer comme spams'}
          UnmakeSpam: {label: 'Retirer des spams'}
      filter: ~
      form: ~
      edit: ~
      new:     ~

Laissez moi maintenant vous décrire rapidement chaque méthode :
Publish: {label: ‘Publier’}
permet d’afficher un commentaire

UnPublish: {label: ‘Censurer’}
permet de censurer un commentaire, c’est à dire de bloquer sa publication

MakeSpam: {label: ‘Spam !’}
permet de marquer un commentaire en tant que spam

UnmakeSpam: {label: ‘Pas spam’}
permet de marquer un commentaire en tant que non spam

Ces méthodes dans la « list » s’appliquent sur un seul commentaire, et dans le « batch » sur un groupe de commentaires sélectionnés.

La méthode CleanSpam: {label: ‘Nettoyer les spams’} quant à elle permet de supprimer d’un coup tous les commentaires notifiés comme étant des spams.

Voici le code des méthodes ci-dessus :
plugins/sfLexikDoctrineActAsCommentablePlugin/modules/comment/actions/actions.class.php :

^?View Code PHP

public function executeListCleanSpam(sfWebRequest $request)
  {
    $nb = Doctrine::getTable('Comment')->cleanSpam();
 
    if ($nb)
    {
      $this->getUser()->setFlash('notice', sprintf('%d spam'.($nb > 1 ? 's' : '').' supprimé'.($nb > 1 ? 's' : ''), $nb));
    }
    else
    {
      $this->getUser()->setFlash('notice', 'Pas de spams.');
    }
 
    $this->redirect('@comment');
  }
 
  public function executeListPublish(sfWebRequest $request)
  {
    $page = $request->getParameter('page', 1);
 
    $this->comment = $this->getRoute()->getObject();
    $this->comment->setIsPublished(true);
    $this->comment->save();
 
    $this->redirect('@comment?page='.$page);
  }
 
  public function executeListUnPublish(sfWebRequest $request)
  {
    $page = $request->getParameter('page', 1);
 
    $this->comment = $this->getRoute()->getObject();
    $this->comment->setIsPublished(false);
    $this->comment->save();
 
    $this->redirect('@comment?page='.$page);
  }
 
  public function executeListMakeSpam(sfWebRequest $request)
  {
    $page = $request->getParameter('page', 1);
 
    $this->comment = $this->getRoute()->getObject();
    $this->comment->setIsSpam(true);
    $this->comment->save();
 
    $this->redirect('@comment?page='.$page);
  }
 
  public function executeListUnmakeSpam(sfWebRequest $request)
  {
    $page = $request->getParameter('page', 1);
 
    $this->comment = $this->getRoute()->getObject();
    $this->comment->setIsSpam(false);
    $this->comment->save();
 
    $this->redirect('@comment?page='.$page);
  }
 
  public function executeBatchPublish(sfWebRequest $request)
  {
    $page = $request->getParameter('page', 1);
 
    $ids = $request->getParameter('ids');
    foreach($ids as $id)
    {
      $this->comment = Doctrine::getTable('Comment')->find($id);
      $this->comment->setIsPublished(true);
      $this->comment->save();
    }
 
    $this->redirect('@comment?page='.$page);
  }
 
  public function executeBatchUnPublish(sfWebRequest $request)
  {
    $page = $request->getParameter('page', 1);
 
    $ids = $request->getParameter('ids');
    foreach($ids as $id)
    {
      $this->comment = Doctrine::getTable('Comment')->find($id);
      $this->comment->setIsPublished(false);
      $this->comment->save();
    }
 
    $this->redirect('@comment?page='.$page);
  }
 
  public function executeBatchMakeSpam(sfWebRequest $request)
  {
    $page = $request->getParameter('page', 1);
 
    $ids = $request->getParameter('ids');
    foreach($ids as $id)
    {
      $this->comment = Doctrine::getTable('Comment')->find($id);
      $this->comment->setIsSpam(true);
      $this->comment->save();
    }
 
    $this->redirect('@comment?page='.$page);
  }
 
  public function executeBatchUnmakeSpam(sfWebRequest $request)
  {
    $page = $request->getParameter('page', 1);
 
    $ids = $request->getParameter('ids');
    foreach($ids as $id)
    {
      $this->comment = Doctrine::getTable('Comment')->find($id);
      $this->comment->setIsSpam(false);
      $this->comment->save();
    }
 
    $this->redirect('@comment?page='.$page);
  }

et la méthode cleanSpam() dans le modèle :
plugins/sfLexikDoctrineActAsCommentablePlugin/lib/model/doctrine/PluginCommentTable.class.php :

^?View Code PHP

  /**
   * supprime tous les commentaires classifiés comme spam et retourne le nombre d'enregistrements supprimés
   *
   * @return int
   */
  public function cleanSpam()
  {
    $q = $this->createQuery('c')->delete()->where('c.is_spam = ?', true);
 
    return $q->execute();
  }

Je n’ai pas touché au filtre, mais chacun peut décider que tel ou tel champ sera utile ou pas, ça dépendra très souvent du projet.

Donc voilà pour la première étape. Jusque là on peut afficher et traiter les commentaires un par un ou par lots, directement depuis leur index.

Voyons maintenant comment ajouter la gestion des commentaires depuis les objets porteurs.
Attention, cette partie est une nouveauté par rapport au premier post, voici les nouvelles sources : plugin.

Tout d’abord il faut ajouter dans l’édition de l’objet porteur le partial qui permettra de gérer les commentaires.
Pour éviter de devoir dupliquer le même template pour chaque type d’objet, on va créer un partial dans le module comment du plugin puis l’appeler dans le partial de l’objet porteur :
/home/lexik/sfprojects/kelsms/plugins/sfLexikDoctrineActAsCommentablePlugin/modules/comment/templates/_backend_comments_list.php :

^?View Code PHP

<div class="container_16">
  Commentaires :
<ul class="order">
    $comment): ?>
	<li id="$comment->getId() ?>" class="row_$key%2 ?>">
<div id="show_$comment->getId() ?>" class="grid_10">
          $comment)) ?>div>
<div class="grid_4">
          $comment)) ?>div>li>
ul>
div>
<script type="text/javascript">script>

Il sera appelé de la manière suivant dans le partial de notre objet, par exemple ici un Message, grâce à la configuration du generator.yml :

^?View Code YAML

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

apps/backend/modules/message/template/_handle_comments.php :

^?View Code PHP

$form->getObject()->findComments())) ?>

Bref.
Dans le partial _backend_comments_list.php on remarque 3 choses :
1) l’appel du partial backend_show
2) l’appel du partial backend_comment_actions
3) les fonctions javascript

1) le partial backend_show affiche tout simplement le contenu du commentaire :
_backend_show.php

^?View Code PHP

<div class="show_comment_class">
<div class="infos_class">
    <span class="author_name_class">
      getAuthorName() ?>
    span>
 
    <span class="time_and_date_class">
      - le <span class="date_class">getCreatedAt(), 'd/MM/yyyy', 'fr') ?>span>
      à <span class="time_class">getCreatedAt(), 'hh:mm', 'fr') ?>span>
    span>div>
<hr />
<div class="text_class">
    getText() ?>div>
div>

2) le partial _backend_comment_actions.php contient les actions pouvant être effectuées sur un commentaire :

^?View Code PHP

<a onclick="publishComment($comment->getId()?>)" href="#">publiera> |
<a onclick="unPublishComment($comment->getId()?>)" href="#">censurera> |
<a onclick="makeSpamComment($comment->getId()?>)" href="#">spama> |
<a onclick="unMakeSpamComment($comment->getId()?>)" href="#">pas spama> |
<a onclick="deleteComment($comment->getId()?>)" href="#">supprimera> |
<a href="$comment->getId()) ?>">editera>

3) les fonctions javascript : elles permettent d’appeler respectivement les méthodes permettant d’effectuer les actions correspondante, tout ça en AJAX.

Ces différentes actions vont effectuer le même travail que les ListAction, à la différence près qu’elle sont appelée en Ajax, et n’ont donc pas le même template de retour.

Voilà d’abord le routing, puis les actions :

^?View Code YAML

comment_ajax_publish:
  url:   /comment_ajax_publish
  params: {module: comment, action: ajaxPublish}
comment_ajax_unpublish:
  url:   /comment_ajax_unpublish
  params: {module: comment, action: ajaxUnPublish}
comment_ajax_makespam:
  url:   /comment_ajax_markspam
  params: {module: comment, action: ajaxMakeSpam}
comment_ajax_unmakespam:
  url:   /comment_ajax_unmarkspam
  params: {module: comment, action: ajaxUnMakeSpam}
comment_ajax_delete:
  url:   /comment_ajax_delete
  params: {module: comment, action: ajaxDelete}

actions :

^?View Code PHP

  public function executeAjaxPublish(sfWebRequest $request)
  {
    $this->comment = Doctrine::getTable('Comment')->find($request->getParameter('id'));
    $this->forward404Unless($this->comment);
    $this->publish($this->comment);
 
    $this->setTemplate('ajaxAction');
  }
 
  public function executeAjaxUnPublish(sfWebRequest $request)
  {
    $this->comment = Doctrine::getTable('Comment')->find($request->getParameter('id'));
    $this->forward404Unless($this->comment);
    $this->unpublish($this->comment);
 
    $this->setTemplate('ajaxAction');
  }
 
  public function executeAjaxMakeSpam(sfWebRequest $request)
  {
    $this->comment = Doctrine::getTable('Comment')->find($request->getParameter('id'));
    $this->forward404Unless($this->comment);
    $this->makespam($this->comment);
 
    $this->setTemplate('ajaxAction');
  }
 
  public function executeAjaxUnMakeSpam(sfWebRequest $request)
  {
    $this->comment = Doctrine::getTable('Comment')->find($request->getParameter('id'));
    $this->forward404Unless($this->comment);
    $this->unmakespam($this->comment);
 
    $this->setTemplate('ajaxAction');
  }
 
  public function executeAjaxDelete(sfWebRequest $request)
  {
    $this->comment = Doctrine::getTable('Comment')->find($request->getParameter('id'));
    $this->forward404Unless($this->comment);
 
    $this->comment->delete();
  }
 
  protected function publish($comment)
  {
    $comment->setIsPublished(true);
    $comment->save();
  }
  protected function unpublish($comment)
  {
    $comment->setIsPublished(false);
    $comment->save();
  }
  protected function makespam($comment)
  {
    $comment->setIsSpam(true);
    $comment->save();
  }
  protected function unmakespam($comment)
  {
    $comment->setIsSpam(false);
    $comment->save();
  }

On remarque une certaine redondance de code dans le actions.class.php,c’est pour ça que j’ai factorisé. Pensez à corriger les autres actions (elles sont ok si vous récupérez les sources).

Et pour finir, dans les templates correspondant à ces actions, on reload la ligne du commentaire en cours, ce qui permettra de mette à jour ses état de publication et spam dans la liste des commentaires.

ajaxActionSuccess.php :

^?View Code PHP

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

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

sfLexikDoctrineActAsCommentablePlugin ou comment rendre des objets commentables via un behavior / plugin

Nikaw — Mon, 09 Nov 2009 10:39:52 +0000

Aujourd’hui je vais vous montrer comment rendre des objets commentables grâce à un behavior Doctrine que j’ai créé, et le plugin qui permet de l’exploiter.

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

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

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

télécharger les sources

Fourni par le behavior :

Le listener :

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

Le template et ses méthodes :

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

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

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

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

CommentForm getCommentForm()

Fourni par le plugin :

La classe Comment :

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

La classe CommentTable :

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

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

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

^?View Code YAML

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

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

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

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

php symfony plugin:publish-assets

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

^?View Code YAML

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

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

^?View Code YAML

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

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

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

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

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

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

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

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

Exemple d’utilisation :

^?View Code PHP

  
   include_partial('comment/comments_list', array('comments'=>$message->findComments(array(), array('created_at DESC')), 'options'=>array())) ?>
 
  
  <div id="form$message->getId() ?>">
    <h2>Postez votre commentaire :h2>
     include_partial('comment/ajax_form_comment', array('form'=>$message->getCommentForm())) ?>
  div>

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

Snippet sfValidatorEmailList

yoye — Wed, 14 Oct 2009 07:55:38 +0000

La version de Symfony 1.3 vient de passer en ALPHA2. Etant en cours de développement d’un projet sur cette version j’en profite pour tester les nouvelles fonctionnalités. Parmi celles-ci, il y a le sfMailer. Je ne vais pas m’étendre sur le sujet car on peut déjà trouver pas mal de posts sur internet concernant cette classe notamment dans les jobeet : Day 16 The Mailer .

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 !

^?View Code PHP

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

^?View Code PHP

 
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 :

^?View Code PHP

 
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.

Réflexions sur l’élaboration d’un bon backend

Calu — Wed, 30 Sep 2009 08:00:20 +0000

Lors de la réalisation de vos projets, l’étape de la construction du backend est devenue un passage obligatoire. Que cela soit un souhait initial du client ou une envie de pouvoir proposer une prise en main du site via une interface, le backoffice justifie pleinement sa présence et son importance. Cette philosophie est très largement soutenue par Symfony avec son générateur CRUD d’admin, ses filters, l’extensibilité de ses templates, l’internationalisation…

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

^?View Code PHP

    public function executeIndex(sfWebRequest $request) {
        if($request-&gt;getParameter('filter')) {
            $this-&gt;setFilters($request-&gt;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 :

^?View Code PHP

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

^?View Code PHP

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

^?View Code PHP

    public function getCountPositioning() {
        return link_to($this-&gt;getComments()-&gt;count(),'@comment_comment?filter[article_id]='.$this-&gt;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 :

^?View Code PHP

    public function executeIndex(sfWebRequest $request) {
        sfConfig::set('sf_escaping_strategy', false);
        if($request-&gt;getParameter('filter')) {
            $this-&gt;setFilters($request-&gt;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 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 :

?View Code PHP

display: [_countComments]

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

^?View Code PHP

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

Gestion d’une galerie photo avec swfUpload dans l’admin

Samuel Breton — Wed, 16 Sep 2009 08:49:18 +0000

Je vous propose de voir une gestion de galerie photo pour l’administration, telle que je l’ai abordée dans un de mes derniers projets.

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.

^?View Code YML

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

^?View Code CONSOLE

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

^?View Code YML

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.

^?View Code PHP

 use_stylesheet('swfUpload.css') ?>
 
 use_javascript('jquery.js') ?>
 use_javascript('jquery-ui.js') ?>
 use_javascript('swfupload.js') ?>
 use_javascript('swfupload.queue.js') ?>
 use_javascript('fileprogress.js') ?>
 use_javascript('handlers.js') ?>
 
<div id="pictures_list" class="sf_admin_form_row">
   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.
  0 fichier uploadé.

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)

^?View Code PHP

 use_helper('Thumb') ?>
 
 if($photos->count() > 0): ?>
 foreach( $photos as $photo ): ?>
<div id="photo-$photo->getId()?>" class="picture">
   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">
     if($photo->isDefault()): ?>
    <strong><img src="/images/backend/star.png" align="left" /> Par défautstrong>
     else: ?>
    <ul>
      <li><a href="$photo) ?>" class="default"><img src="/images/backend/star.png" align="left" /> Par défauta>li>
      <li><a href="$photo) ?>" class="delete"><img src="/images/backend/cross.png" align="left" /> Supprimera>li>
    ul>
     endif; ?>
  div>
div>
 endforeach; ?>
<div class="clear">div>
 else: ?>
<p>Aucune photo pour l'instant.

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.

^?View Code JAVASCRIPT

$('#photo-').effect('drop');

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

^?View Code YML

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

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

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

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

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

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

^?View Code YML

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

mySessionStorage.calss.php

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

Utilisation de sfSessionStorage dans Symfony

yoye — Mon, 24 Aug 2009 07:10:29 +0000

sfSessionStorage fait partie des fonctionnalités du Framework qui restent un brin obscures lorsqu’on commence avec Symfony. Mais il s’avère par la suite très utile, que ce soit dans le cadre de la production ou même du développement.

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.

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

^?View Code YML

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 :

^?View Code PHP

// environnement redac
require_once(dirname(__FILE__).'/../config/ProjectConfiguration.class.php');
 
$configuration = ProjectConfiguration::getApplicationConfiguration('frontend', 'redac', true);
sfContext::createInstance($configuration)-&gt;dispatch();
 
// environnement admin
require_once(dirname(__FILE__).'/../config/ProjectConfiguration.class.php');
 
$configuration = ProjectConfiguration::getApplicationConfiguration('frontend', 'admin', true);
sfContext::createInstance($configuration)-&gt;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.

Liste d’objets ordonnable via AJAX partie 1 bis

Nikaw — Tue, 18 Aug 2009 14:12:40 +0000

Ce post a pour but de reprendre la première version de la liste, en utilisant le plugin csDoctrineActAsSortablePlugin.
Ce plugin gère exactement la situation décrite dans la partie 1 en utilisant simplement un behavior dans le schema.

Voilà le lien du plugin : csDoctrineActAsSortablePlugin

Le readme est assez bien fait, cependant pour plus de clarté reprenons l’exemple précédent.

Dans un premier temps, révisons le schema.yml :
schema.yml

^?View Code YAML

Item:
  actAs:
    Sortable: ~
  columns:
    name:
      type: string(255)

Le champs « rank » est remplacé par le behavior actAs: Sortable: ~

Il gère les ajout et les suppression, les surcharges des méthodes save() et delete() dans la classe Item.class.php ne sont plus utiles.

Il ajoute aussi des méthodes de tri, de classement, de positionnement etc. les méthodes déclarées dans la class ItemTable.class.php ne sont donc plus utiles non plus.

Nous allons voir maintenant à quel point le listing et les déplacements sont facilités grâce à ce plugin.
Commençons par les actions :
actions.class.php

^?View Code PHP

public function executeIndex(sfWebRequest $request)
  {
    $this->items = Doctrine::getTable('Item')->findAllSorted('ASCENDING');
  }

La méthode findAllSorted() est fournie par le plugin et est associée à tout objet comportant le behavior actAs: Sortable dans le schéma.

La vue indexSuccess.php ne change pas.

En revanche, l’action déclenchée par le bouton oui :
actions.class.php:

^?View Code PHP

public function executeOrder(sfWebRequest $request)
  {
    $this->elements = explode(",",$request->getParameter('elements'));
 
    Doctrine::getTable('Item')->sort($this->elements);
 
    $this->items = Doctrine::getTable('Item')->findAllSorted('ASCENDING');
    $this->setTemplate('index');
  }

Les changements sont Doctrine::getTable(‘Item’)->sort($this->elements);
Cette méthode est également liée au behavior actAs: Sortable, mais le plugin tel quel contient des erreurs.

Corrections des erreurs de la méthode sort() :
/plugins/csDoctrineActAsSortablePlugin/lib/template/Sortable.php, ligne 221

^?View Code PHP

$connection->beginTransaction();

Là il manque juste la lettre « c ».

A la ligne 225 une variable $class est utilisée, mais elle n’est pas définie, ce qui génère une deuxième erreur.
Pour la corriger, il faut donc définir cette $class, qui est en fait une variable contenant la classe de l’objet à trier.
Ici il s’agirait de la classe « Item », mais soyons théorique : il faut se débrouiller pour récupérer la classe d’un objet quelconque.
Voici ma solution :
/plugins/csDoctrineActAsSortablePlugin/lib/template/Sortable.php, fonction sortTableProxy()

^?View Code PHP

/**
   * Send an array from the sortable_element tag (symfony+prototype)and it will
   * update the sort order to match
   *
   * @param string $order
   * @return void
   * @author Travis Black
   */
  public function sortTableProxy($order)
  {
    /*
      TODO
        - Make this a transaction.
        - Add proper error messages.
    */
    //on récupère l'objet
    $object = $this->getInvoker();
    //on récupère la connection
    $connection = $object->getTable()->getConnection();
 
    $connection->beginTransaction();
 
    foreach ($order as $position =&gt; $id)
    {
      $newObject = $object->getTable()->findOneById($id);
 
      if ($newObject->get($this->_options['name']) != $position + 1)
      {
        $newObject->moveToPosition($position + 1);
      }
    }
 
    // Commit Transaction
    $connection->commit();
  }

Et voilà, la classe est corrigée, et l’action fonctionne à présent.

Les méthodes principales pour reclasser des éléments Sortable sont (comme indiquées dans le readme) :
pour les Record :
promote()
demote()
moveToFirst()
moveToLast()
moveToPosition($newPosition)

pour les Table :
sort($order)
findAllSorted($sortMode)
findAllSortedWithParent(…)

Voyons comment utiliser ces méthodes.
Mais d’abord, corrigeons encore quelques erreurs :
tout d’abord, le return de la méthode getFinalPosition() :

^?View Code PHP

return (integer) $finalPosition;

Il faut faire un cast car cette méthode entraine une erreur de type.
Ensuite, dans la méthode moveToPosition() :

^?View Code PHP

public function moveToPosition($newPosition)
  {
    if (!is_int($newPosition))
    {
      throw new Doctrine_Exception('moveToPosition requires an Integer as the new position. Entered ' . $newPosition);
    }
 
    $object = $this->getInvoker();
    $position = $object->get($this->_options['name']);
    $connection = $object->getTable()->getConnection();
 
    //begin Transaction
    $connection->beginTransaction();
 
    // Position is required to be unique. Blanks it out before it moves others up/down.
    $object->set($this->_options['name'], null);
    $object->save();
 
 
    if ($position > $newPosition)
    {
      $q = $object->getTable()->createQuery()
          ->update(get_class($object))
          ->set($this->_options['name'], $this->_options['name'].' + 1')
          ->where($this->_options['name'].' < ?',$position)
          ->andWhere($this->_options['name'].' >= ?',$newPosition)
          ->orderBy($this->_options['name'].' DESC');
 
      foreach ($this->_options['uniqueBy'] as $field)
      {
        $q->addWhere($field.' = '.$object[$field]);
      }
 
      $q->execute();
    }
    elseif ($position < $newPosition)
    {
      $q = $object->getTable()->createQuery()
          ->update(get_class($object))
          ->set($this->_options['name'], $this->_options['name'].' - 1')
          ->where($this->_options['name'].' > ?',$position)
          ->andWhere($this->_options['name'].' <= ?',$newPosition)
          ->orderBy($this->_options['name'].' ASC');
 
      foreach($this->_options['uniqueBy'] as $field)
      {
        $q->addWhere($field . ' = ' . $object[$field]);
      }
 
      $q->execute();
    }
 
    $object->set($this->_options['name'], $newPosition);
    $object->save();
 
    // Commit Transaction
    $connection->commit();
  }

Il manquait tout simplement le orderBy ASC dans le elseif, ce qui engendrait une erreur a cause du unique.

Maintenant que tout est juste, il ne reste plus qu’à créer une route et une action pour chaque méthode :
routing.yml

^?View Code YAML

promote:
  url:        /promote/:id
  class:      sfDoctrineRoute
  params:     { module: item, action: promote }
  options:    { model: Item, type: object }
 
demote:
  url:        /demote/:id
  class:      sfDoctrineRoute
  params:     { module: item, action: demote }
  options:    { model: Item, type: object }
 
movetofirst:
  url:        /movetofirst/:id
  class:      sfDoctrineRoute
  params:     { module: item, action: moveToFirst }
  options:    { model: Item, type: object }
 
movetolast:
  url:        /movetolast/:id
  class:      sfDoctrineRoute
  params:     { module: item, action: moveToLast }
  options:    { model: Item, type: object }

actions.class.php

^?View Code PHP

public function executePromote(sfWebRequest $request)
  {
    $this->item = $this->getRoute()->getObject();
    $this->item->promote();
    $this->items = $this->item->getTable()->findAllSorted('ASCENDING');
    $this->redirect('@homepage');
  }
 
  public function executeDemote(sfWebRequest $request)
  {
    $this->item = $this->getRoute()->getObject();
    $this->item->demote();
    $this->items = $this->item->getTable()->findAllSorted('ASCENDING');
    $this->redirect('@homepage');
  }
 
  public function executeMoveToFirst(sfWebRequest $request)
  {
    $this->item = $this->getRoute()->getObject();
    $this->item->moveToFirst();
    $this->items = $this->item->getTable()->findAllSorted('ASCENDING');
    $this->redirect('@homepage');
  }
 
  public function executeMoveToLast(sfWebRequest $request)
  {
    $this->item = $this->getRoute()->getObject();
    $this->item->moveToLast();
    $this->items = $this->item->getTable()->findAllSorted('ASCENDING');
    $this->redirect('@homepage');
  }
 
  public function executeOrder(sfWebRequest $request)
  {
    $this->elements = explode(",",$request->getParameter('elements'));
 
    Doctrine::getTable('Item')->sort($this->elements);
 
    $this->items = Doctrine::getTable('Item')->findAllSorted('ASCENDING');
    $this->redirect('@homepage');
  }

Et la vue qui correspond, avec les liens pour tester chaque méthode :
indexSuccess.php

^?View Code PHP

<h1>Ordered list of items - AJAX enabledh1>
<ul id="order">
   foreach($items as $item): ?>
  <li id="$item->getId() ?>">
       echo $item->getName() ?> |
      <a href="$item) ?>">Promotea> |
      <a href="$item) ?>">Demotea> | 
      <a href="$item) ?>">Move to firsta> |
      <a href="$item) ?>">Move to lasta> |
  li>
   endforeach ?>
ul>
 
<input type="button" value="Enregistrer" onclick="submitOrder()"/>
<script type="text/javascript">
  $(function() {
    $("#order").sortable();
    $("#order").disableSelection();
  });
 
  function submitOrder()
  {
    var elements = "";
    var i=0;
    $('ul#order li').each(function()
    {
      elements += $(this).attr('id')+",";
      i++;
    })
//alert(elements.substr(0, elements.length-1));
$.post('@order') ?>', { elements: elements.substr(0, elements.length-1) });
  }

Voilà donc tout ce qu’il faut pour utiliser basiquement ce plugin.

Liste d’objets ordonnable via AJAX partie 1

Nikaw — Wed, 12 Aug 2009 13:07:48 +0000

Aujourd’hui, voyons les fonctions sortables permettant de changer la position d’objet, de les ordonner et de sauvegarder l’ordre. C’est toujours pratique pour organiser une galerie photo, ou des éléments dans votre site internet.

Toutes les informations sur l’objet que nous souhaitons ordonner et/ou classer seront stockées en base :
schema.yml

^?View Code YAML

Item:
  columns:
    name:
      type: string(255)
    rank:
      type: integer
      notnull: true
      unique: true

L’attribut ‘rank’ étant notnull, il faut forcément qu’il soit définit lors du save(), et étant unique on ne peut pas le définir par défaut.
Il faut donc surcharger la méthode save() :
Item.class.php

^?View Code PHP

public function save(Doctrine_Connection $con = null)
{
   // les nouveaux enregistrements seront ajoutés à la suite, donc avec un rang élévé de 1 par rapport au rang max
   if($this->isNew())
   $this->setRank($this->getTable()->getMaxRank()+1);
 
   return parent::save($con);
}

Il faut aussi surchager la méthode delete() pour redescendre tous les éléments de rang supérieur lors de la suppression :
Item.class.php

^?View Code PHP

public function delete(Doctrine_Connection $con = null)
{
   //tous les enregistrements au dessus descendent d'une place
  $items = Doctrine_Query->create()->from('Item')->where('rank > ?', $this->getRank())->execute();
 
   // delete the item
   $ret = parent::delete();
 
  foreach($items as $item)
  {
    $item->setRank($item->getRank()-1);
    $item->save();
  }
  return $ret;
}

Nous avons donc besoin d’une méthode permettant de récupérer le rang max :
ItemTable.class.php

^?View Code PHP

//permet de récupérer le rang le plus haut
public function getMaxRank()
{
  $query = Doctrine_Query::create()
        ->select('MAX(rank)')
        ->from('Item i');
 
    $tmp = $query->execute(array(),Doctrine::HYDRATE_NONE);
 
    return $tmp[0][0];
}

Ici on passe en paramètre Doctrine::HYDRATE_NONE pour que la méthode ne retourne pas une collection. Le retour est un tableau à 2 entrées, mais la requête ne retournant qu’un résultat, il est disponible en [0][0].

Passons maintenant à la vue.
Il s’agit d’afficher la liste des items, tout simplement.
Mais pour les afficher, il faut les charger, voyons donc d’abord l’action :
actions.class.php

^?View Code PHP

public function executeIndex()
{
  $this->items = Doctrine::getTable('Item')->getAllOrderedByRank();
}

Un coup d’oeil tout de suite sur la méthode getAllOrderedByRank() :
ItemTable.class.php

^?View Code PHP

public function getAllOrderedByRank()
  {
    $query = Doctrine_Query::create()
        ->from('Item')
        ->orderBy('rank ASC');
 
    return $query->execute();
  }

Maintenant voyons la vue :
indexSuccess.php

^?View Code PHP

<h1>Ordered list of itemsh1>
<ul>
   foreach($items as $item): ?>
  <li id="$item->getId() ?>">
       echo $item->getName() ?>
  li>
   endforeach ?>
ul>

Passons maintenant aux choses sérieuses.
Le framework Javascript JQuery comporte des fonctions permettant de créer des liste dont les éléments sont « drag n’ droppables », ici c’est celles ci que l’on va utiliser.
Pour cela, il faut modifier la vue, afin de rajouter le script jquery, et de spécifier une id à la liste, id que le script jquery utilisera pour cibler la liste à ordonner :

^?View Code PHP

<ul id="order">
   foreach($items as $item): ?>
  <li id="$item->getId() ?>">
       echo $item->getName() ?>
  li>
   endforeach ?>
ul>
 
<input type="button" value="Enregistrer" onClick="submitOrder()"/>
<script type="text/javascript">
  $(function() {
    //on spécifie la liste
    $("#order").sortable();
    $("#order").disableSelection();
  });
 
  function submitOrder()
  {
    //initialisation de la chaine contenant les id des items
    var elements = "";
 
    //parcours de la liste d'items
    $('ul#order li').each(function()
    {
      //pour chaque item, on concatene l'id dans la chaine
      elements += $(this).attr('id')+",";
    })
  //on execute l'action, a laquelle on envoie en param la liste des id
  $.post('@order') ?>', { elements: elements.substr(0, elements.length-1) });
  }

Vous aurez noté l’ajout du bouton submit. C’est en cliquant sur celui-ci que l’on déclenche l’action qui sauvegarde le nouvel ordre des items.
Pour enregistrer l’ordre des items, chaque

a pour id l’id de l’item en question.
Lors du click on exécute un script qui récupère toutes les id dans l’ordre et qui les concatène dans une chaîne de caractères en les séparant par des « , ». Cette chaîne est envoyée en paramètre à l’action.
Routing :
routing.yml

^?View Code YAML

order:
  url:      /order-item
  params:  { module: item, action: order }

L’action :
actions.class.php

^?View Code PHP

public function executeOrder(sfWebRequest $request)
  {
    //on récupère les id, que l'on place dans un tableau pour un parcours plus aisé
    $this->elements = explode(",",$request->getParameter('elements'));
 
    //on parcours les id, on récupère l'item correspondant, et on met son rang à jour
    foreach($this->elements as $key=>$element_id)
    {
      $item = Doctrine::getTable('Item')->find($element_id);
      $item->setRank($key);
      $item->save();
    }
 
    $this->items = Doctrine::getTable('Item')->getAllByRank();
 
    //on affiche à nouveau la liste des items, mis à jour
    $this->setTemplate('index');
  }

Voilà, vous aurez noté que les nouveaux rangs sont tout simplement la position dans la liste, partant de 0.

Dans la prochaine partie, nous verront comment implanter cette fonctionnalité dans votre backend avec l’admin generator

Symfony : Utilisation de la classe sfFilter

yoye — Thu, 16 Jul 2009 09:48:23 +0000

Nous allons voir l’utilisation de la classe sfFilter. Attention à ne pas confondre sfFilter et les classes auto-générés lors du build de l’application qui sont des classes principalement utilisées dans le backend pour faire le tri sur les colonnes.

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 :

^?View Code PHP

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

^?View Code PHP

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

^?View Code YML

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 :

^?View Code YML

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.

Générer des thumbs lors de l’affichage d’une image

thomas — Thu, 09 Jul 2009 16:11:13 +0000

Nous allons voir ici comment générer facilement des thumbs lors de l’affichage d’une image sur le site, plutôt que lors de l’upload de cette image.
L’intérêt: une fois que le site est lancé, qu’il y a des images déjà uploadées, il est beaucoup plus facile de changer dans le code la taille d’affichage et de regénérer automatiquement les images, plutôt que de devoir tout réuploader une seconde fois, voir +.

Afin d’optimiser l’affichage des pages, il est recommandé de généré plusieurs thumb (vignettes) pour une même image. Il y a l’image d’origine, puis une version en 200×200, une en 150×100 et une 50×50, suivant leur position sur le site.
Une première solution est de générer ces thumbs lors de l’upload, c’est très efficace, le travail ce fait une fois lors de la sauvegarde et est opérationnel directement. Mais on a tous eu un projet où finalement il faut créer un nouveau thumb ou changer le 150×100 en 100×100 et là c’est le drame: il faut re-uploader toutes les images une par une (enfin si le site est déjà en prod, le mieux c’est de s’en rendre compte du problème avant).

Bref, la deuxième solution est d’uploader une image source, et lors de l’affichage demander la taille souhaitée. Là on vérifie si le thumb existe, si oui on l’affiche, sinon , on le crée et on l’affiche.
Voila ce que je vous propose aujourd’hui, un petit helper tout fait qui s’occupe de cette deuxième solution.
Il est basé sur le plugin sfImageTransformPlugin qui est excellent et dont vous avez toute la doc ici: http://www.symfony-project.org/plugins/sfImageTransformPlugin.

Pour installer le helper rien de plus simple, vous créez le répertoire lib/helper, et vous placez le fichier dedans.
lors de l’appel il faut penser à le loader avec la fonction suivante dans une action sfProjectConfiguration::getActive()->loadHelpers(‘Thumb’);
ou

^?View Code PHP

 use_helper('Thumb');?>

dans la vue.

il y a deux fonctions:

une pour générer le thumb:
doThumb($image_name, $folder, $options = array(), $resize = ‘scale’, $default = ‘default.jpg’)
@param $image_name : le nom de l’image donc généralement le $object->getImage(), pas de répertoire
@param $folder : le nom du répertoire dans uploads où est stocké l’image : uploads/object/source => $folder = object
@param $options : la taille de l’image: width et height
@param $resize : l’opération sur le thumb: « scale » pour garder les proportions, « center » pour tronquer l’image
@param $default : l’image par défaut si image_name n’existe pas
le thumb est créé dans uploads/object/thumb/
le réslutat retourné est le lien vers l’image : /uploads/object/thumb/mon-image.jpg

une autre fonction :
showThumb($image_name, $folder, $options = array(), $resize = ‘scale’, $default = ‘default.jpg’)
elle appelle la précédente avec les même paramètres.
elle retourne l’image tag directement. donc un seul paramètre change:
@param $options : les parametres à passer à l’image: width, height, alt, title, class, id…

Vous pouvez télécharger le helper ici: thumbhelper

Merci de me contacter en cas de soucis.

Du Javascript dynamique dans une vue en utilisant sf_format

Samuel Breton — Wed, 08 Jul 2009 07:13:32 +0000

Il arrive que l’on ai besoin d’utiliser un script javascript spécifique dans une vue. Un script dynamique qui nécessite d’être renseigné par des informations de php (utiliser des variables ou des méthodes de nos objets).

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

Mettre des balises

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.

^?View Code JAVASCRIPT

jQuery(function() {
 
  $('div.action a').click(function(event) {
    event.preventDefault();
    $.post(
      '@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.

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

^?View Code YML

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

Listes déroulantes mises à jours en Ajax avec jQuery

Samuel Breton — Wed, 17 Jun 2009 07:49:39 +0000

Un petit TIPS pour faire des listes déroulantes liées qui s’enrichissent en fonction de la valeur choisie sur l’une d’entre elles.
(J’ai l’impression que la phrase est très compliqué pour pas grand chose ^^)
Le tout en Ajax en utilisant jQuery.

Dans mon exemple, ça sera tout simplement un formulaire Lambda avec des listes déroulante pour les Régions et les Départements.
Le fonctionnement est le suivant. Par défaut les listes déroulantes sont initialisées avec toutes les valeurs. Dés que l’on choisi une valeur pour la région, la liste déroulante des département affine sa liste pour ne proposer que les départements de la région saisie.

Vite fait, le schéma utilisé :

^?View Code YML

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

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

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

La route :

^?View Code JAVASCRIPT

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

L’action :

^?View Code PHP

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

Le partial :

^?View Code PHP

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

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

^?View Code JAVASCRIPT

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

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

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

@bientôt !

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

Formulaires i18n et ajout de langues automatisé

Nikaw — Fri, 12 Jun 2009 14:39:51 +0000

Ce post à pour but de faciliter les embedI18n pour les formulaires ayant des champs en i18n.

Il s’agit normalement de ceci dans votre formulaire principal (donc objectForm.class.php, et non objectTranslationForm.class.php) :

^?View Code PHP

$this->embedI18n(array('en', 'fr',...));
$this->widgetSchema->setLabel('en', 'Anglais');
$this->widgetSchema->setLabel('fr', 'Français');
...
...
...

Il y aura donc autant de lignes que de langues à ajouter.

Imaginons maintenant la situation suivante :

Je suis développeur web, et je réalise un site international pour un client Mr Gui, il me donne la liste des langues, je code tous mes formulaires, et le lendemain, Mr Gui m’appelle, et me dit qu’il est désolé, il a oublié 3 langues, seulement voilà, j’ai 27 formulaires dans mon appli… (et oui il s’agit d’un énorme site, Mr Gui est un très gros client…). Je reprend donc mes 27 formulaires, et je rajoute mes embedForm et mes setLabel.
Mais, le lendemain, Mr Gui me rappelle pour me dire que finalement, le finlandais c’est pas la peine de le mettre, je dois donc r’ouvrir mes 27 formulaires et supprimer dans chacun le finlandais dans le embedI18n et dans le setLabel.

En résumé, même si une situation pareil est exagérée, il serait quand même pratique de centraliser les cultures, et d’automatiser les embedI18n et setLabel.

Voilà donc la solution que je propose aujourd’hui, en 2 étapes :

Etape 1 : centraliser les cultures

On sait déjà que Symfony permet l’utilisation dans les apps des fichier de configuration app.yml pour tout ce qui est options du site, et paramètres globaux. Nous allons donc utiliser ce principe pour définir toutes les langues.
Sachant que ces langues ne sont pas forcément propres à une application en particulier (frontend, backend, etc.) il convient de placer le fichier des langues dans un dossier plus haut placé. Créons donc un dossier config dans le dossier apps, et plaçons y un fichier app.yml (il pourra éventuellement contenir d’autres infos que les langues, on ne l’appellera donc pas languages.yml ou cultures.yml, …)

/apps/config/app.yml :

^?View Code YAML

all:
  cultures:
    enabled:
      fr: Français
      en: English
      es: Español

Facile pour l’instant non ?
La syntaxe globale est en fait la suivante :

^?View Code YAML

environnement:
  cultures:
    enabled:
      clé: label

Etape 2 : automatisation dans les formulaires

Maintenant que les langues sont centralisées, reste plus qu’à automatiser les formulaires, la méthode est la suivante:

^?View Code PHP

public function configure()
{
  $array = sfYaml::load(sfConfig::get('sf_apps_dir').'/../config/app.yml'); /* 1 */
  $languages = $array['all']['cultures']['enabled']; /* 2 */
  $keys = array_keys($languages); /* 3 */
  $this->embedI18n($keys); /* 4 */
 
  /* 5 */
  foreach($languages as $key=>$lang)
  {
    $this->widgetSchema->setLabel($key, $lang);
  }
  parent::configure();    
}

Explications :
1 : le sfConfig::get() n’est pas joignable depuis les formulaires, et puis de toutes façons, le fichier n’est pas placé dans une app, il faut donc le charger autrement.
Le framework Symfony dispose d’un Yaml Loader qui le permet.

2 : les fichiers *.yml sont chargé par le loader Symfony comme des tableaux, construits de la manière suivante :

^?View Code YAML

tableau:
  clé1: valeur
  sous-tableau:
    sous-clé1: valeur
    sous-tableau2 : { sous-sous-clé1: valeur, sous-sous-clé2: valeur }

Tout ceci sera chargé comme suit par le loader :

^?View Code PHP

array(
  'tableau' => array(
    'clé1' => valeur,
    'sous-tableau' => array(
      'sous-clé1' => valeur,
      'sous-sous-tableau' => array(
        'sous-sous-clé1' => valeur,
        'sous-sous-clé2' => valeur
      ),
    ),
  ),
);

La lige marquée /* 2 */ permet donc de stocker dans la variable $languages un tableau de la forme :

^?View Code PHP

array(
  'fr' => 'Français',
  'en' => 'English',
  ...,
  ...
);

3 : cette ligne permet des ranger les clés du tableaux languages (donc ‘fr’, ‘en’, etc.) dans un tableaux où elles seront valeurs, et non clés.
4 : cette ligne embed donc toutes les langues présentes dans le yml
5 : le foreach permet donc de set tous les labels, en correspondance avec les langues.

Et voilà !

Utilisation de sfDoctrineGuardPlugin pour la gestion des utilisateurs

Samuel Breton — Wed, 27 May 2009 11:01:50 +0000

sfDoctrineGuardPlugin comme son nom l’indique est la version Doctrine de sfGuardPlugin qui est THE plugin de gestion des utilisateurs de Symfony.

Il comporte des formulaires d’identification et d’inscription très basique, mais son principal point fort est la gestion des droits associés aux utilisateurs, la possibilité de gérer des groupes le tout générant automatiquement les crédentials qui va permettre de sécuriser l’application de manière très simple.

Je ne reviendrai pas sur la gestion des crédentials qui est très bien expliquée dans le Jobeet #13.

De même pour l’installation. Le readme est très bien fait et explique très clairement comment faire.

Le modèle de données

Le modèle de données du plugin comporte la table des Utilisateurs, des Groupes et des Permissions ainsi que les tables d’associations entre Utilisateurs/Permissions, Groupes/Permissions et Utilsateurs/Groupes.

Ce sont les permissions attribuées à un utilisateur (directement ou par ses groupes) qui déterminent les crédentials qu’il aura une fois logué (C’est le nom de la permission qui sera le nom du crédential).

Pour illustrer tout ca, on va voir un petit exemple.

On prends une structure simple, avec 2 groupes et 3 permissions.
Les permissions de Lecture, Ecriture et Téléchargement (même si la loi Hadopie a été votée ^^).
Les groupes Admin qui a tous les droits et Membre qui n’a que le droit de lecture.

^?View Code YML

 
sfGuardPermission:
  pLecture:
    name: lecture
  pEcriture:
    name: ecriture
  pTelegargement:
    name: telechargement
 
sfGuardGroup:
  gAdmin:
    name: admin
  gMembre:
    name: membre
 
sfGuardGroupPermission:
  gp1:
    sfGuardGroup:      gAdmin
    sfGuardPermission: pLecture
  gp2:
    sfGuardGroup:      gAdmin
    sfGuardPermission: pEcriture
  gp3:
    sfGuardGroup:      gAdmin
    sfGuardPermission: pTelegargement
  gp4:
    sfGuardGroup:      gMembre
    sfGuardPermission: pLecture

Et 3 utilisateurs : Toto, Titi et Tata à qui on va définir des droits différents.

- Toto sera dans le groupe admin, il aura ainsi tout les droits.
- Titi et Tata seront dans le groupe Membre et auront ainsi seulement le droit de Lecture.
- Titi a en plus le droit de téléchargement.

Ce qui se traduit en fixture comme ceci :

^?View Code YML

 
sfGuardUser:
  Toto:
    username: toto
    password: t0t0
  Titi:
    username: titi
    password: t1t1
  Tata:
    username: tata
    password: t4t4
 
sfGuardUserGroup:
  ug1:
    sfGuardUser:  Toto
    sfGuardGroup: gAdmin
  ug2:
    sfGuardUser:  Titi
    sfGuardGroup: gMembre
  ug3:
    sfGuardUser:  Tata
    sfGuardGroup: gMembre
 
sfGuardUserPermission:
  up1:
    sfGuardUser:       Titi
    sfGuardPermission: pTelegargement

Dans un module lambda, on peut donc très facilement sécuriser nos pages comme suit.

/module/config/security.yml

^?View Code YML

secure:
  is_secure:   on
 
telechargement:
  is_secure:   on
  credentials: [lecture, telechargement]
 
default:
  is_secure:   off

La page secure nécessite que l’utilisateur soit connecté mais il n’y a aucune restriction de crédential. Les 3 utilisateur, une fois logés, pourront y accéder.

La page téléchargement nécessite 2 permissions lecture et téléchargement. Seuls Toto et Titi y auront accès. Tata sera redirigé automatiquement vers la page d’erreur de permissions.

La redirection après l’authentification.

L’authentification est gérée par le plugin, il suffit d’envoyer l’utilisateur vers la route @sf_guard_signin.

Une fois l’authentification effectuée, le script redirige l’utilisateur. Par défaut l’utilisateur est redirigé vers le HTTP_REFERER.

Heureusement on peut aussi déterminer une route vers laquelle on veut être redirigé après l’authentification de plusieurs manières.

Premièrement via des variable du app.yml

^?View Code YML

all:
  sf_guard_plugin:
    success_signin_url:      @my_route?param=value
    success_signout_url:     module/action

Autre méthode qui consiste à utiliser le comportement par défaut de redirection vers le referer, mais en utilisant la méthode setReferer() de la classe sfGuardSecurityUser.

^?View Code PHP


class moduleActions extends sfActions
{
  ...
  public function executeAction(sfWebRequest $request)
  {
    ...
    $this->getUser()->setReferer('@my_route');
    $this->redirect('@sf_guard_signin');
  }
}

L’ordre de priorité est :
- la variable du fichier app.yml
- le getReferer() du GuardUser
- le HTTP_REFERER

Connecter automatiquement un utilisateur

Il est possible de connecter automatiquement un utilisateur grâce à la méthode signin() à la quelle on doit passer une instance de sfGuardUser.

Par exemple dans une action quelconque :

^?View Code PHP


class moduleActions extends sfActions
{
  ...
  public function executeAction(sfWebRequest $request)
  {
    ...
    $utilisateur = Doctrine::getTable('sfGuardUser')->findOneByUsername('toto');
    $this->getUser()->signin($utilisateur);
    ...
  }
}

Associer un ou plusieurs groupes à un utilisateur

On a vu au début de l’article comment associer des groupes aux utilisateurs par le fixture.

On va voir ici comment le faire en php.

Par exemple si on avait à le faire dans le script d’inscription et qu’on veulait associer automatiquement le groupe membre aux utilisateurs qui s’inscrivent.

^?View Code PHP

 
public function executeInscription(sfWebRequest $request)
{
  $this->form = new sfGuardUserFormRegister();
  // la classe de formulaire sfGuardUserFormRegister n'existe pas dans le plugin par defaut
  // je la mets en annexe à la fin de l'article
 
  if($request->isMethod('post'))
  {
    $this->form->bind($request->getParameter($this->form->getName()));
 
    if($this->form->isValid())
    {
      $permission = Doctrine::getTable('sfGuardGroup')->findOneByName('membre');
 
      $utilisateur = $this->form->getObject();
      $utilisateur['permissions'][] = $permission;
      $utilisateur->save();
 
      $this->getUser()->signIn($utilisateur);
      $this->redirect('@homepage');
    }
  }
}

Annexe

^?View Code PHP

 
/**
 * formulaire d'inscription
 *
 * @package    form
 * @subpackage sfGuardUser
 * @author     Lexik
 * @version    SVN: $Id: sfDoctrineFormTemplate.php 6174 2007-11-27 06:22:40Z fabien $
 */
class sfGuardUserFormRegister extends PluginsfGuardUserForm
{
 
  public function configure()
  {
    unset(
      $this['groups_list'],
      $this['permissions_list'],
      $this['algorithm'],
      $this['salt'],
      $this['is_active'],
      $this['is_super_admin'],
      $this['last_login'],
      $this['created_at'],
      $this['updated_at']
    );
 
    $this->widgetSchema['password']     = new sfWidgetFormInputPassword();
    $this->widgetSchema['password_bis'] = new sfWidgetFormInputPassword();
 
    $this->widgetSchema->setLabels(array(
      'username'     => 'Email* :',
      'password'     => 'Mot de passe* :',
      'password_bis' => 'Confirmation* :'
    ));
 
    $this->validatorSchema['username']     = new sfValidatorEmail(array('required' => true), array('invalid' => 'Cet email n\'est pas valide.', 'required' => 'Champ obligatoire.'));
    $this->validatorSchema['password']     = new sfValidatorString(array('required' => true, 'min_length' => 6), array('min_length' => '"%value%" est trop court (%min_length% lettres minimum).', 'required' => 'Champ obligatoire.'));
    $this->validatorSchema['password_bis'] = new sfValidatorString(array('required' => true, 'min_length' => 6), array('min_length' => '"%value%" est trop court (%min_length% lettres minimum).', 'required' => 'Champ obligatoire.'));
 
    $this->mergePostValidator(new sfValidatorSchemaCompare(
      'password',
      sfValidatorSchemaCompare::EQUAL,
      'password_bis',
      array(),
      array('invalid' => 'Les champs doivent être identiques.')
    ));
  }
 
}

Colonnes de recherche perso dans le filter de l’admin generator, avec Doctrine

Nikaw — Wed, 22 Apr 2009 18:17:34 +0000

Comment faire pour filtrer l’affichage dans l’admin generator lorsqu’on a à faire à un champs qui n’est pas dans la table considérée ?

Un exemple ici : j’ai des utilisateurs, avec la table User, mais j’ai aussi une table sfGuardUser.

Ma table User contient les infos globales de mes utilisateurs, alors que la table sfGuardUser contient les informations d’identification et permet également de récupérer les infos sur les permissions, les groupes, etc.

Voilà le problème : j’ai dans le listing de mes utilisateurs ajouté la colonne « Administrateur ? », indiquant si l’utilisateur est admin ou non (vous l’aurez compris…), pour cela il m’a suffit de rajouter la méthode getIsAdmin() dans ma classe User.class.php (lib/model/doctrine/User.class.php), et le champs is_admin dans le generator.yml de mon module user dans le backend (apps/backend/modules/user/config/generator.yml). (cf jobeet n°12)

Pour le filter le problème est un tout petit peu plus complexe : il n’utilise pas la classe pour filtrer l’affichage, et n’utilisera donc pas la méthode getIsAdmin().

Pourquoi ?

Par ce qu’il ne fait que générer une requete Doctrine_Query executée dans l’action.

Il y’aura donc ici 3 choses à faire :

ajouter le champs is_admin dans le formulaire du filter
surcharger la méthode getFields() (sert à récupérer les valeurs du formulaire)
ajouter la méthode qui modifie la requête

1) Ajout du champs is_admin (lib/form/filter/doctrine/UserFormFilter.class.php)
Le formulaire du filtre n’est rien de mieux qu’un formulaire sfFormFilter, on a donc déjà vu comment ça marche

^?View Code PHP

    $this->validatorSchema['is_admin'] = new sfValidatorBoolean(array('required' => false), array());
    $this->widgetSchema['is_admin'] = new sfWidgetFormSelect(array(
      'choices' => array('' => '', true => 'oui', false => 'non')
      ));

Pensez aussi à créer le label correspondant.

2) Surcharge de getFields() (lib/form/filter/doctrine/UserFormFilter.class.php)

^?View Code PHP

  public function getFields()
  {
    return array_merge(array('is_admin' => 'IsAdmin'), parent::getFields());
  }

3) Ajout de la méthode de modification de la requête :

^?View Code PHP

  public function addIsAdminColumnQuery(Doctrine_Query $q, $field,$value)
  {
    if($value) //je cherche à trouver les admins
    {
      $a = $q->getRootAlias();
      $q->innerJoin($a . '.sfGuardUser u')
        ->innerJoin('u.sfGuardUserPermission up')
        ->innerJoin('up.sfGuardPermission p')
        ->andWhere('p.name = ?', 'admin');
    }
 
    if(!$value) //si je cherche les non admins
    {
      $a = $q->getRootAlias();
      $q->innerJoin($a . '.sfGuardUser u')
        ->innerJoin('u.sfGuardUserPermission up')
        ->innerJoin('up.sfGuardPermission p')
        ->andWhere('p.name = ?', 'member');
    }
    return $q;
  }

Essayons de voir le plan général :

- la méthode à ajouter doit s’appeler add*nom de la colonne*ColumnQuery
- elle prend en paramètres :

- la requête déjà défini par les autres champs du filtre, si aucun champs n’est renseigné elle correspond à la
requête récupérant tous les objets en question (ici les utilisateurs)

- le nom du champs en question

- la valeur entrée dans le formulaire filter.

A vous de modifier ensuite la requête passée en paramètre pour filtrer vos résultats.
Et voilà !!

Schema.yml Doctrine, Bonnes pratiques, Convention de nommage et fonctions magiques

Samuel Breton — Tue, 21 Apr 2009 12:14:33 +0000

On s’est rendu compte ici qu’il y avait pas mal de questions en rapport avec le schema.yml qui ressortaient régulièrement.

Le schema.yml est généralement trop vite oublié. C’est facile à faire, ça génère la base sans trop se poser de questions, et puis on l’oublie… Alors que le schema.yml est certainement le fichier le plus important d’une application Symfony.

Je vais donc essayer de regrouper dans ce post les questions auxquelles on répond généralement par « Regardes dans ton schema.yml » où « Comment est ce que tu l’as défini dans ton schema.yml ? ».

Notamment au niveau des définitions des relations et les méthodes magiques qui en découlent.

Tout d’abord un petit bookmark des pages à lire et à relire de la documentation doctrine.

(Personnellement je trouve que la documentation Doctrine est très bien faite. Les exemples omniprésent et la rendent très explicite, même pour un anglophobe.)

Pour ce post j’ai fait le schema.yml d’une application lambda. On a des utilisateurs, des groupes, la relation n:n entre les deux. Et pour rajouter une petite relation 1:n les utilisateurs ont des photos. (original non?)

J’ai utilisé des behaviors Timestampable et Sluggable.
Dans les types j’en ai profité pour tester le Enum que je n’utilisais pas jusqu’à présent, mais je pense que dans un avenir proche je vais m’en servir beaucoup plus
Pareil dans les data validation le « email: true » sur le champ email et le « past: true » sur la date de naissance sont assez énormes et permettent d’avoir déjà les validators adéquats dans les classes formulaires.

^?Download schema.yml

Utilisateur:
  tableName:        test_utilisateur
  actAs:
    Timestampable:  ~
    Sluggable:
      unique:       true
      fields:       [nom,prenom]
      canUpdate:    true
  columns:
    id:             { type: integer(4), unsigned: true, primary: true, autoincrement: true }
    sexe:           { type: enum, values: ['','Homme','Femme'], default: 'Homme' }
    nom:            { type: string(255) }
    prenom:         { type: string(255) }
    date_naissance: { type: date, past: true }
    email:          { type: string(255), notnull: true, unique: true, email: true }
  relations:
    Groupes:
      class:        Groupe
      refClass:     Membre
      local:        utilisateur_id
      foreign:      groupe_id
 
 
Photo:
  tableName:        test_photo
  actAs:
    Timestampable:  ~
  columns:
    id:             { type: integer(4), unsigned: true, primary: true, autoincrement: true }
    fichier:        { type: string(255), notnull: true }
    utilisateur_id: { type: integer(4), unsigned: true, primary: true }
  relations:
    Utilisateur:
      local:        utilisateur_id
      foreign:      id
      foreignAlias: Photos
      onDelete:     CASCADE
 
 
Membre:
  tableName:        test_membre
  columns:
    utilisateur_id: { type: integer(4), unsigned: true, primary: true }
    groupe_id:      { type: integer(4), unsigned: true, primary: true }
  relations:
    Utilisateur:
      local:        utilisateur_id
      foreign:      id
      foreignAlias: Membres
      onDelete:     CASCADE
    Groupe:
      local:        groupe_id
      foreign:      id
      foreignAlias: Membres
      onDelete:     CASCADE
 
 
Groupe:
  tableName:        test_groupe
  columns:
    id:             { type: integer(4), unsigned: true, primary: true, autoincrement: true }
    nom:            { type: string(255), notnull: true }
  relations:
    Utilisateurs:
 
      class:        Utilisateur
      refClass:     Membre
      local:        groupe_id
      foreign:      utilisateur_id

La convention de nommage

Le nom des objets : Le plus court et le plus explicite possible. En CamelCase avec la première lettre en majuscule et au singulier. Pourquoi la 1er lettre en majuscule. Si la table a le même nom, ça permet de les dissocier facilement pour éviter les ambiguïté, notamment dans la construction des requête en DQL.

Le nom des relations : Si possible, je donne le même nom que l’objet cible. Au singulier si on est sur une relation N:1 ou 1:1 et au pluriel quand on est sur une relation 1:N ou N:N (généralement les foreignAlias). La aussi la 1er lettre en majuscule est importante, car elle permet de conserver une syntaxe camelCase sur les accessers magiques.

Par exemple sur l’objet Photo :

^?View Code YML

Photo:
  ...
  relations:
    Utilisateur:
      local:        utilisateur_id
      foreign:      id

L’accesseur magique sera :

^?View Code PHP

$ma_photo->getUtilisateur();

Alors que si on appelle la relation en minuscule :

^?View Code YML

Photo:
  ...
  relations:
    utilisateur:
      local:        utilisateur_id
      foreign:      id

L’accesseur magique sera

^?View Code PHP

$ma_photo->getutilisateur()

Et du coup on perd la syntaxe camelCase qui est généralisée dans tout le framework.
C’est du chipotage mais ca peut être source d’erreur bête qui fait perdre du temps.

Les TOC (Troubles Obsessionnels de Codage :p) ou Bonnes pratiques

Sur les relations 1:N et 1:1, je définie toute la relation dans l’objet qui possède la clé étrangère. Pour essayer de ne pas alourdir trop mon schema.yml et aussi par faignantise.

^?View Code YML

Photo:
  ...
  relations:
    Utilisateur:
      local:        utilisateur_id
      foreign:      id
      foreignAlias: Photos
      onDelete:     CASCADE

Cette relation défini 2 méthodes magiques Photo::getUtilisateur() qui va retourner l’objet Utilisateur lié à la photo et Utilisateur::getPhotos() qui retourne une collection d’objets Photo liés à utilisateur.

Cette même relation peut se décrire aussi en la décomposant en 2 parties.

^?View Code YML

Utilisateur:
  ...
  relations:
    Photos:
      local:        id
      foreign:      utilisateur_id
      onDelete:     CASCADE
 
Photo:
  ...
  relations:
    Utilisateur:
      local:        utilisateur_id
      foreign:      id
      onDelete:     CASCADE

Les 2 méthodes marchent parfaitement et ont leurs avantages et leurs inconvénients.

Sur les relations N:N, je définie toute la relation dans la Classe de liaison, et sur les objets externes seulement la partie qui les concernent. Pour éviter les multiples redéfinitions.

^?View Code YML

Membre:
  ...
  relations:
    Utilisateur:
      local:        utilisateur_id
      foreign:      id
      foreignAlias: Membres
      onDelete:     CASCADE
    Groupe:
      local:        groupe_id
      foreign:      id
      foreignAlias: Membres
      onDelete:     CASCADE
 
 
Utilisateur:
  ...
  relations:
    Groupes:
      class:        Groupe
      refClass:     Membre
      local:        utilisateur_id
      foreign:      groupe_id
 
 
Groupe:
  ...
  relations:
    Utilisateurs:
      class:        Utilisateur
      refClass:     Membre
      local:        groupe_id
      foreign:      utilisateur_id

Sur les objets, j’aime bien avoir des noms simples et explicites mais paradoxalement, j’aime bien préfixer mes tables dans la base de donnée. C’est pourquoi je redéfinie systématiquement le tableName des objets dans le schema.yml

^?View Code YML

Utilisateur:
  tableName:        test_utilisateur
  ...

Sur les objets l’id est généré automatiquement mais il est de type bigint(20) signé. Et là aussi, comme je suis un gros maniaque et que je n’aime pas avoir des id signé qui plus est en bigint. Je redéfini l’id en int signé.

^?View Code YML

Utilisateur:
  ...
  columns:
    id:             { type: integer(4), unsigned: true, primary: true, autoincrement: true }

Attention, il est possible de définir les relations à plusieurs endroits et de plusieurs manières différentes. Il faut essayer de se tenir à une méthodologie la plus stricte possible pour éviter des redéfinitions de relations.
Si il y a des redéfinitions, Symfony ne va pas forcement les détecter lors de la re-génération des classes et ça risque de ne pas fonctionner correctement.

Créer des relations avec les objets d’un plugin

On va prendre le cas de sfGuard qui est un des plugins les plus utilisés.

Petite chose à savoir. Quand on utilise sfGuard, l’id de l’objet sfGuardUser est un int signé. Si vous avez besoin de faire des jointures pensez bien à utiliser un integer(4).

(Le type des clé étrangère est très important et source de pas mal de problèmes.)

Si on voulait lier l’objet Photo à sfGuardUser il faudrait écrire quelque-chose comme :

^?View Code YML

Photo:
  ...
  columns:
    ...
    user_id: { type: integer(4) }
  relations:
    User:
      class:            sfGuardUser
      local:            user_id
      foreign:          id
      foreignAlias:     Photos
      onDelete:         CASCADE

Toujours dans l’hypothèse de l’intégration de sfGuard à la place de mon objet Utilisateur.
Pour les relations N:N, étant donné que l’on a pas accès au schema.yml de l’objet sfGuarduser avec lequel on va se lier. Il faut définir toutes les relations de manière externe.

Pour la relation avec les groupes ça donnerais :

^?View Code YML

Membre:
  ...
  relations:
    Utilisateur:
      class:        sfGuardUser
      local:        utilisateur_id
      foreign:      id
      foreignAlias: Membres
      onDelete:     CASCADE
    Groupe:
      local:        groupe_id
      foreign:      id
      foreignAlias: Membres
      onDelete:     CASCADE
 
 
Groupe:
  ...
  relations:
    Utilisateurs:
      class:        sfGuardUser
      refClass:     Membre
      local:        groupe_id
      foreign:      utilisateur_id
      foreignAlias: Groupes

Méthodes magiques dans les objets

On a vu que les nom des relations et les foreignAlias engendraient des méthodes magiques qui permettent de remonter facilement les objets de la relation.
Si on reprends le schema.yml du début, la liste des méthodes magiques est la suivante :

^?View Code PHP

 
//methodes magiques su l'objet Utilisateur
$utilisateur = new Utilisateur();
 
$utilisateur->getPhotos();
$utilisateur->getGroupes();
$utilisateur->getMembres();
 
//methodes magiques su l'objet Photo
$photo = new Photo();
 
$photo->getUtilisateur();
 
//methodes magiques su l'objet Membre
$membre = new Membre();
 
$membre->getUtilisateur();
$membre->getGroupe();
 
//methodes magiques su l'objet Groupe
$groupe = new Groupe();
 
$groupe->getMembres();
$groupe->getUtilisateurs();

Les getters et les setters sont aussi des méthodes magiques.

Il y a un petit piège à éviter si on veut surcharger un getter ou un setter.

Par exemple si on vaut surcharger le getter Nom de l’objet Utilisateur, on a tendance a vouloir écrire :

^?View Code PHP

class UtilisateurTable extends Doctrine_Table
{
 
  public function getNom()
  {
    return parent::getNom();
  }
 
 
}

Et bien il ne faut pas ! Ça fait en fait une boucle infinie.
Il faut écrire :

^?View Code PHP

class UtilisateurTable extends Doctrine_Table
{
 
  public function getNom()
  {
    return parent::_get('nom');
  }
 
 
}

Finders magiques dans les classes Table

Comme pour les getters, il y a deux finders magiques par champ dans la classe Table.
Un findByLechamp et un findOneByLechamp. Le premier qui retourne une collection d’objets (même s’il n’y en a qu’un) et le second qui renvoie un objet seul.

Par exemple:

^?View Code PHP

 
$utilisateur = Doctrine::getTable('Utilisateur')->findOneByNom('Toto');

Le nombre de requêtes

Le nombre de requêtes effectuer en base peut rapidement devenir impressionnant.

Mais si on y regarde de plus prés ce sont souvent de petites requêtes.
On va voir comment jouer sur le nombre de requêtes générées avec un petit exemple.

Une action toute simple ou je récupère un objet Utilisateur par son slug.

^?View Code PHP


 
//actions.class.php
class userActions extends sfActions
{
 
  public function executeIndex(sfWebRequest $request)
  {
    $this->test_utilisateur = Doctrine::getTable('Utilisateur')->findOneBySlug('teta-toto');
  }
 
}

Et la vue qui correspond

^?View Code PHP

//indexSuccess.php
<p>Utilisateur :  echo $test_utilisateur->getPrenom() ?>p>
 
<p>Photos :  echo $test_utilisateur->getGroupes()->count() ?>p>
 
<ul>
 foreach($test_utilisateur->getPhotos() as $photo): ?>
  <li>php echo $photo->getFichier() ?>li>
 endforeach; ?>
ul>
 
<p>Groupes :  echo $test_utilisateur->getGroupes()->count() ?>p>
 
<ul>
 foreach($test_utilisateur->getGroupes() as $groupe): ?>
  <li>php echo $groupe->getNom() ?>li>
 endforeach; ?>
ul>

On vois que 3 requetes sont effectuées.

^?View Code SQL

 
1. SELECT t.id AS t__id, t.sexe AS t__sexe, t.nom AS t__nom, t.prenom AS t__prenom, t.date_naissance AS t__date_naissance, t.email AS t__email, t.created_at AS t__created_at, t.updated_at AS t__updated_at, t.slug AS t__slug FROM test_utilisateur t WHERE t.slug = ? LIMIT 1 - (teta-toto )
 
2. SELECT t.id AS t__id, t.nom AS t__nom, t2.utilisateur_id AS t2__utilisateur_id, t2.groupe_id AS t2__groupe_id FROM test_groupe t LEFT JOIN test_membre t2 ON t.id = t2.groupe_id WHERE t2.utilisateur_id IN (?) - (1 )
 
3. SELECT t.id AS t__id, t.utilisateur_id AS t__utilisateur_id, t.fichier AS t__fichier, t.created_at AS t__created_at, t.updated_at AS t__updated_at FROM test_photo t WHERE t.utilisateur_id IN (?) - (1 )

La 1er requête est effectuée lors du findOneBySlug() dans l’action.
La seconde lors du getPhotos() dans la vue.
Et la derniere lors du getGroupes() dans la vue également.

On peut obtimiser le nombre de requete en forceant les jointures.

Pour le même code si on surcharge le finder findOneBySlug() en y rajoutant toutes les jointures

^?View Code PHP

 

/**
 * /lib/model/doctrine/UtilisateurTable.class.php
 */
class UtilisateurTable extends Doctrine_Table
{
 
  public function findOneBySlug($slug)
  {
    $q = Doctrine_Query::create()
      ->from('Utilisateur u')
      ->leftJoin('u.Photos')
      ->leftJoin('u.Groupes')
      ->where('u.slug = ?', $slug);
 
    return $q->fetchOne();
  }
 
}

On obtiens le même résultat avec une seule requète

^?View Code SQL

 
SELECT  t.id AS  t__id, t.sexe AS  t__sexe, t.nom AS  t__nom, t.prenom AS  t__prenom, t.date_naissance AS  t__date_naissance, t.email AS  t__email, t.created_at AS  t__created_at, t.updated_at AS  t__updated_at, t.slug AS  t__slug, t2.id AS  t2__id, t2.utilisateur_id AS  t2__utilisateur_id, t2.fichier AS  t2__fichier, t2.created_at AS  t2__created_at, t2.updated_at AS  t2__updated_at, t3.id AS  t3__id, t3.nom AS  t3__nom FROM test_utilisateur t LEFT JOIN test_photo t2 ON t.id = t2.utilisateur_id LEFT JOIN test_membre t4 ON t.id = t4.utilisateur_id LEFT JOIN test_groupe t3 ON t3.id = t4.groupe_id WHERE t.slug = ? - (teta-toto )

Il ne faut pas nonplus s’amuser a remonter la moitié de la base de donnée dans chaque requête, mais ça permet de mieu gérer la charge générée par les scripts.

Supprimer ou renommer un objet

Si on supprime ou qu’on renomme une classe, les classes générés ne sont pas nettoyées et il faut le faire « a la main » sinon, les objets sont toujours regénéré et les tables toujours présentes en base.

Par exemple si ou voulais supprimer l’objet Utilisateur parcequ’on a décidé de se servir de sfGuard pour gérer les utilisateurs.

Il faut supprimer :

/lib/filter/doctrine/UtilisateurFormFilter.class
/lib/filter/doctrine/base/BaseUtilisateurFormFilter.class.php
/lib/form/doctrine/UtilisateurForm.class.php
/lib/form/doctrine/base/BaseUtilisateurForm.class.php
/lib/model/doctrine/Utilisateur.class.php
/lib/model/doctrine/UtilisateurTable.class.php
/lib/model/doctrine/base/Utilisateur.class.php

Merci a ceux qui ont eu le courage d’aller jusqu’au bout. J’avoue que je ne pensais pas faire un post aussi long à la base.
J’ai un peu tapé au kilomètre et je pense que je le remanierai d’ici quelques temps avec plus d’explications et beaucoup moins de fautes

Petit système de vote en AJAX

Nikaw — Tue, 21 Apr 2009 07:59:48 +0000

Le système que je vous propose est assez simpliste : il s’agit d’un vote type « j’aime / j’aime pas ».

On dispose d’un ensemble d’éléments (ici des messages) que l’on nous propose de noter.

Dans une première étape, le principe est de créer le système de vote, dans une deuxième étape on limitera les votes : un visiteur ne peut voter sur un élément qu’une fois par jour.
(Attention, ne pas pas oublier d’ajouter les include et use_javascript dans le layout de votre appli)

Etape 1 :

Schéma :

Message:
  columns:
    text:
      type: string(255)
    relations:
      Ratings:
        type: many
        class: Rating
        local: id
        foreign: message_id

Rating:
  actAs: { Timestampable: ~ } //permet d'avoir les champs "created_at" et "updated_at", pour limiter le nombre de vote à 1 par jour
  columns:
    value:
      type: boolean
    message_id:
      type: integer
  relations:
    Message:
      onDelete: CASCADE
      local: message_id
      foreign: id

On a donc une table contenant nos messages (ici on n’a besoin que du texte) et une table contenant les votes : un vote est donc décrit par une id, et un message, donc à chaque click un nouveau vote est inséré dans la base de données.

Pour éviter de se retrouver avec une BDD sur-remplie, on pourra rajouter une 3° étape qui consiste à créer une tâche qui compile chaque vote sur un message pour en faire un résumé (qui fait la somme par exemple) et qui ensuite supprime les votes compilés.

Bref, les fonctionnalités utiles maintenant sont : afficher la note du message, afficher le nombre de votes (pour pouvoir faire la différence entre un message qui a une bonne note mais 3 votes et un message qui a une bonne note mais 1000 votes, par exemple), et afficher les liens permettant de voter, tout ça à coté du message en question, bien évidemment.

Voici donc le code de l’index des message (apps/*votre appli*/modules/message/templates/indexSuccess.php)

Message List



  
   $message)) ?>




   'rating'.$message->getId(),
                          'url'      => '@message_vote_plus?id='.$message->getId()
    )); ?>
   'rating'.$message->getId(),
                  'url'      => '@message_vote_moins?id='.$message->getId()
    )); ?>




  gettext() ?>

Partial message/rating (apps/*votre appli*/module/template/_rating.php) :

Note : getGlobalRating(); ?>/,
Nombre de votes : getRatingsCount() ?>

La syntaxe utilisée ici pour les fonction link_to_remote est :
link_to_remote(‘texte à afficher pour le lien’, tableau des options(‘update’ => id de la div a update, ‘url’ => adresse de l’action))

Vous noterez aussi que les url des link_to_remote utilisent des routes, voici les routes utilisées(apps/*votre appli*/config/routes.yml) :

message_vote_plus:
  url:      /message-vote-plus/:id
  param:    { module: message, action: votePlus }

message_vote_moins:
  url:      /message-vote-moins/:id
  param:    { module: message, action: voteMoins }

Un click sur un lien va donc engendrer l’action votePlus ou voteMoins de l’objet message en question, spécifié par l’id.
Voici les actions (apps/*votre appli*/modules/message/actions.class.php) :

  //execute le vote "j'aime"
  public function executeVotePlus(sfWebRequest $request)
  {
    //on récupère le message courant
    $this->message = Doctrine::getTable('Message')->find($request->getParameter('id'));
    //on effectue le vote positif
    $this->message->votePlus();
    //on génère le partial du message, c'est ce résultat qui sera utilisé par le link_to_remote pour mettre à jour la div spécifiée, cela évite également le passage par le template votePlusSuccess.php (qui donc n'est pas à créer)
    return $this->renderPartial('message/rating',array('message' => $this->message));
  }

  //execute le vote "j'aime pas"
  public function executeVoteMoins(sfWebRequest $request)
  {
    //on récupère le message courant
    $this->message = Doctrine::getTable('Message')->find($request->getParameter('id'));
    //on effectue le vote négatif
    $this->message->voteMoins();
    //on génère le partial du message, c'est ce résultat qui sera utilisé par le link_to_remote pour mettre à jour la div spécifiée, cela évite également le passage par le template voteMoinsSuccess.php (qui donc n'est pas à créer)
    return $this->renderPartial('message/rating',array('message' => $this->message));
  }

L’action utilise donc naturellement des méthodes du controlleur (lib/model/doctrine/Message.class.php) :
-récupération du nombres de vote sur 1 message :

  //retourne le nombre de votes sur ce message
  public function getRatingsCount()
  {
    return Doctrine::getTable('Rating')->getMessageRatingsQuery($this->getId())->count();
  }

-récupération de la note d’un message :

  //retourne la note globale du message courant
  public function getGlobalRating()
  {
    //on récupère tous les votes sur ce message
    $ratings = Doctrine::getTable('Rating')->getMessageRatingsQuery($this->getId())->execute();
    //on initialise la note a 0
    $note = 0;
    //pour chaque vote positif on incrémente la note (rappel : la note est stockée sous forme de boolean dans la base)
    foreach ($ratings as $rating)
    {
      if ($rating->getValue())
      {
        $note++;
      }
    }
    //on récupère le nombre de votes, pour calculer la moyenne
    $nbvotes = $this->getRatingsCount();
    //si il n'y pas encore eu de vote sur ce message, on est obligé de donner la valeur 1 à nbvotes, pour éviter une division par 0
    if($nbvotes == 0){ $nbvotes = 1; }

    //on retourne la moyenne : (note/nb_votes)*"valeur sur laquelle on rapporte la note" et on arrondi (round)
    //la valeur sur laqelle on rapporte la note est stockée dans la config (app.yml), ainsi que le nombre de chiffres apres la virgule
    return round(($note/$nbvotes)*sfConfig::get('app_moyenne_sur'), sfConfig::get('app_round'));
  }

-votes :

  //ajoute un vote positif relatif à ce message
  public function votePlus()
  {
    return $this->vote('1');
  }

  //ajoute un vote négatif relatif à ce message
  public function voteMoins()
  {
    return $this->vote('0');
  }

  //effectur le vote
  public function vote($value)
  {
    $rating = new Rating(); //nouveau vote
    //on set ses champs
    $rating->setMessageId($this->getId()); //message_id
    $rating->setValue($value); //value
    $rating->save(); //on l'enregistre dans la base
  }

Voilà pour la première étape, le système de votes est opérationnel, reste plus qu’à limiter les votes.

Etape 2
De quoi a-t-on besoin pour la suite ?
1) Modifier le schéma pour ajouter l’attribut ip_user, correspondant à l’adresse ip de l’utilisateur
2) De vérifier au moment du vote dans le modèle, s’il existe déjà un vote récent pour ce message et pour cette adresse ip
3) Donc, on a aussi besoin d’une méthode dans la classe RatingTable.class.php qui récupère les votes récents
4) On ajoutera également un message à l’utilisateur pour le remercier de son vote ou lui indiquer qu’il n’a plus le droit de voter.

Mise à jour de la table Rating dans le schéma :

Rating:
  actAs: { Timestampable: ~ }
  columns:
    value:
      type: boolean
    message_id:
      type: integer
    user_ip:
      type: string(12)
      notnull: true
  relations:
    Message:
      onDelete: CASCADE
      local: message_id
      foreign: id

1) Modification de la méthode vote()

public function vote(sfWebRequest $request, $value)
  {
    //on récupère l'adresse ip du visiteur/utilisateur
    $user_ip = $request->getRemoteAddress();
    //on récupère les votes effectués par cet utilisateur sur ce message
    $recent_rating = Doctrine::getTable('Rating')->getRecentRating(array('user_ip' => $user_ip, 'message_id' => $this->getId()));
    //si il n'existe pas de vote trop récent
    if(!($recent_rating->count() > 0))
    {
      $rating = new Rating(); //nouveau vote
      //on set ses champs
      $rating->setUserIp($user_ip); //user_ip
      $rating->setMessageId($this->getId()); //message_id
      $rating->setValue($value); //value
      $rating->save(); //on l'enregistre dans la base et on retourne vrai
      return true;
    }
    else //si le vote est trop récent, pas de vote, on retourne faux
    {
      return false;
    }
  }

Ce qui implique évidemment la création de la méthode getRecentRating() (dans lib/model/doctrine/RatingTable.class.php) :

  //retourne les votes récents dans la query
  public function getRecentRating($params, Doctrine_Query $query = NULL)
  {
    if(is_null($query)) //si pas de requete, on récupère tous les votes de la base
    {
      $query = $this->createQuery('c');
    }
    //on récupère tous les votes faits avec cette ip
    $query = $this->getRatingsByUserIp($params['user_ip'], $query);
    //on récupère tous les votes sur ce message
    $query = $this->getMessageRatingsQuery($params['message_id'], $query);
    //on sélectionne uniquement les message récents
    $query->andWhere('c.created_at >= ?', date('Y-m-d h:i:s', time() - 86400 * (sfConfig::get('app_vote_time_limit') / 24)));
    return $query;
  }

La valeur de la limite de temps pour le vote et stockée dans la config, de la même manière que round et moyenne_sur dans la première partie

All:
  moyenne_sur: 20
  round: 1
  #limite de temps pour le vote (en heures)
  vote_time_limit: 24

Vous noterez sûrement la présences des fonctions getRatingsByUserIpQuery() et getMessageRatingsQuery() :

  //retourne la requête permettant de récupérer tous les votes sur un message donné, parmis ceux récupérés par la requete $query
  public function getMessageRatingsQuery($message_id, Doctrine_Query $query = NULL)
  {
    if(is_null($query)) //si aucune requête passée, on génère la requête pour récup tous les votes
    {
      $query = $this->createQuery('c');
    }
    $query->andWhere('c.message_id = ?', $message_id); //on ajoute le where pour filtrer par message_id

    return $query;
  }

  //retourne la requete permettant de récupérer tous les votes passé par une adresse ip, parmis ceux récupérés par la requete $query
  public function getRatingsByUserIp($user_ip, Doctrine_Query $query = NULL)
  {
    if(is_null($query)) //si aucune requête passée, on génère la requête pour récup tous les votes
    {
      $query = $this->createQuery('c');
    }
    $query->andWhere('c.user_ip = ?', $user_ip); //on ajoute le where pour filtrer par user_ip

    return $query;
  }

Il ne reste plus qu’à afficher un petit message à notre utilisateur (dans l’action) :

  //execute le vote "j'aime"
  public function executeVotePlus(sfWebRequest $request)
  {
    //on récupère le message courant
    $this->message = Doctrine::getTable('Message')->find($request->getParameter('id'));
    //on effectue le vote positif
    if($this->message->votePlus($request))
    {
      $this->getUser()->setFlash('vote', "Merci d'avoir voté", false);
    }
    else
    {
      $this->getUser()->setFlash('vote', "vous ne pouvez plus voter", false);
    }
    //on génère le partial du message, c'est ce résultat qui sera utilisé par le link_to_remote pour mettre à jour la div spécifiée
    //cela évite également le passage par le template votePlusSuccess.php (qui donc n'est pas à créer)
    return $this->renderPartial('message/rating',array('message' => $this->message));
  }

  //execute le vote "j'aime pas"
  public function executeVoteMoins(sfWebRequest $request)
  {
    //on récupère le message courant
    $this->message = Doctrine::getTable('Message')->find($request->getParameter('id'));
    //on effectue le vote négatif
    if($this->message->voteMoins($request))
    {
      $this->getUser()->setFlash('vote', "Merci d'avoir voté", false);
    }
    else
    {
      $this->getUser()->setFlash('vote', "vous ne pouvez plus voter", false);
    }
    //on génère le partial du message, c'est ce résultat qui sera utilisé par le link_to_remote pour mettre à jour la div spécifiée, cela évite également le passage par le template voteMoinsSuccess.php (qui donc n'est pas à créer)
    return $this->renderPartial('message/rating',array('message' => $this->message));
  }

On utilise la méthode sfUser::setFlash(). Comme la mise à jour de l’affichage sera le partial rendu, il faut donc intégrer encore quelques lignes dans le template correspondant (apps/*votre appli*/module/message/template/_rating.php :

Note : getGlobalRating(); ?>/,
Nombre de votes : getRatingsCount() ?>

hasFlash('vote')): ?>
getFlash('vote') ?>

Et voilà !!

JEditable et formulaire Symfony 1.2

Samuel Breton — Fri, 17 Apr 2009 07:57:17 +0000

Comment intégrer un plugin jQuery dans un projet Symfony 1.2 ?

La réponse à cette question ne pouvant pas tenir dans le modeste blog de Lexik.fr, je vais seulement vous expliquer comment intégrer la modification d’un champ « INPUT » en ajax dans un formulaire Symfony 1.2, à l’aide du plugin jQuery JEditable.

A ce stade, je vous recommande ce lien : JEditable

Pré-requis

Comme d’habitude, l’éternel plugin : sfFormExtraPlugin
Les JS :
- jquery-1.3.2.min.js
- jquery.jeditable.js

Le widget

Chemin :
[votre_projet]/plugins/sfFormExtraPlugin/lib/widget/sfWidgetFormInputEditInPlace.class.php

Code source :

^?View Code PHP


class sfWidgetFormInputEditInPlace extends sfWidgetFormInput
{
  public $object;
  public $route;
  public function __construct($option = array(), $messages = array(), $object = null, $route = null)
  {
    parent::__construct($option, $messages);
    $this->object = $object;
    $this->route = $route;
  }
  public function configure($options = array(), $messages = array())
  {
    parent::configure($options, $messages);
  }
  public function render($name, $value = null, $attributes = array(), $errors = array())
  {    
    $prefix = $this->generateId($name);    
    return sprintf(<<%s

EOF
    , $prefix, $value,
      $prefix,
      url_for($this->route, $this->object, array('absolute'=>true))
   );
  }
}

Pour ce widget, j’ai créer 2 attributs.

object
Cet attribut contient l’objet de la route objet Symfony.

^?View Code PHP
4
public $object;
route
Cet attribut contient le nom de la route objet Symfony.

^?View Code PHP
5
public $route;

Ces attributs nous permettent de générer l’URL de la page qui va valider et éventuellement sauvegarder les données postées par le widget JQuery.

^?View Code PHP

36	url_for($this->route, $this->object, array('absolute'=>true))

Maintenant que l’outil est créé, utilisons le !
Toute la suite de l’article n’est qu’un exemple d’utilisation.

Schéma

^?View Code YML

Person:
  columns:
    firstname:
      type: string(255)
    lastname:
      type: string(255)
    email:
      type: string(255)

Routing

show_person
La route du formulaire.
save_person_eip
Route de l’action « executeSaveEIP » qui valide et sauve les champs du modèle « Person »

^?View Code YML

# Route du formulaire
show_person:
  url:     /person/show/:id
  class:   sfDoctrineRoute
  options: { model: Person, type: object }
  param:   { module: person, action: show }
 
# Route de la page sauvant les données postées en ajax
save_person_eip:
  url:     /person/saveEIP/:id
  class:   sfDoctrineRoute
  options: { model: Person, type: object }
  param:   { module: person, action: saveEIP }
  requirements:
    id: d+
    sf_method: [post]

Actions

^?View Code PHP

// L'action pour le formulaire de base
public function executeShow(sfWebRequest $request)
{
  $this->person = $this->getRoute()->getObject();
  $this->form = new PersonForm($this->person);
}
 
// L'action qui traite le post en ajax
public function executeSaveEIP(sfWebRequest $request)
{
  // Récupération de l'objet de la route
  $this->person = $this->getRoute()->getObject();
 
  // Récupération des données postées par le widget JQuery
  $id = $request->getParameter('ajaxfield_id');
  $this->value = $request->getParameter('value');
 
  // Récupération du nom du champ
  if(ereg("person_(.*)$", $id, $key))
  {
    $champ = $key[1]; 
  }
 
  // Instanciation d'un formulaire lié à notre objet
  $form = new PersonForm();
 
  // Récupération du validateur du champ
  $validator = $form->getValidator($champ);
 
  // On tente de valider le champ
  try
  {
    $cleaned = $validator->clean($this->value);
    $this->person->set($champ, $this->value);
    $this->joueur->save();
  }
  catch(sfValidatorError $e)
  {
     // Erreur lors de la validation du champ 
     // La valeur à afficher dans le template doit être la valeur actuelle de l'objet
     $this->value = $this->person->get($champ);
  }
}

Templates

showSuccess.php

^?View Code PHP

<h1>Edition d'une personne
firstname']->render();?>

lastname']->render();?>

email']->render();?>

saveEIPSuccess.php
^?View Code PHP
echo $value ?>

Formulaire

On construit chacun des widgets avec l’objet et le nom de la route.
On définit les validators.

^?View Code PHP

  public function configure()
  {
    // Widgets
    $this->widgetSchema['firstname'] = new sfWidgetFormEditInPlace(array(), array(), $this->getObject(), 'save_joueur_eip');
    $this->widgetSchema['lastname'] = new sfWidgetFormEditInPlace(array(), array(), $this->getObject(), 'save_joueur_eip');
    $this->widgetSchema['email'] = new sfWidgetFormEditInPlace(array(), array(), $this->getObject(), 'save_joueur_eip');
 
    // Validators
    $this->validatorSchema['firstname'] = new sfValidatorString();
    $this->validatorSchema['lastname'] = new sfValidatorString();
    $this->validatorSchema['email'] = new sfValidatorEmail();  
  }

View.yml

^?View Code YML

[...]
default:
  javascripts:    [jquery-1.3.2.min.js, jquery.jeditable.js]
[...]