Blog Symfony - Lexik Montpellier » olivier http://www.lexik.fr/blog/symfony Blog sur le développement Web PHP Tue, 20 Jul 2010 08:35:36 +0000 en hourly 1 http://wordpress.org/?v=3.0 Tips : Symfony 1.3/1.4 orderBy des relations http://www.lexik.fr/blog/symfony/symfony/tips-symfony-1-31-4-orderby-des-relations-1026 http://www.lexik.fr/blog/symfony/symfony/tips-symfony-1-31-4-orderby-des-relations-1026#comments Thu, 14 Jan 2010 14:11:27 +0000 olivier http://www.lexik.fr/blog/symfony/?p=1026 Depuis la branche 1.3/1.4 la gestion des relations a été bien enrichie.

Au niveau des formulaire l’apparition du EmbedRelation a vraiment facilité l’implémentation des embedForm. Je ne vais pas reprendre l’explication de cette fonctionnalité dans cet article et vous renvoie donc vers le très bon article de NiKo sur son blog (En anglais).

Petit problème, l’ordre de tri de la Doctrine_Collection retrounée qui est … en vrac ^^ J’en ai fait l’expérience sur une base postGre ou l’ordre de retour est en fonction de la dernière modification alors que sur une base mySql c’est l’ordre des IDs (déjà moins gênant). Dans les 2 cas ça n’est pas très satisfaisant, et on aimerais pouvoir maitriser l’ordre de tri de cette relation.

Un bout de schema.yml pour pouvoir illustrer mon explication :

?View Code YML
...
Produit:
  columns:
    id:                 { type: integer(4), unsigned: true, primary: true, autoincrement: true }
    name:               { type: string(128), notnull: true }
 
Photo:
  columns:
    id:                 { type: integer(4), unsigned: true, primary: true, autoincrement: true }
    file_name:          { type: string(128), notnull: true }
    id_produit:         { type: integer(4), unsigned: true }
    ordre:              { type: integer(4), unsigned: true }
  relations:
    Produit:
      local:            id_produit
      foreign:          id
      foreignAlias:     Photos
      onDelete:         CASCADE
...

Dans ce contexte on peut imaginer faire un EmbedRelation des Photos dans la classe ProduitForm.

Le fonctionnement du EmbedRelation est qu’il utilise l’accesseur magique getPhotos() qui elle même fait un findByIdProduit() dans la classe PhotoTable et retourne une Doctrine_Collection d’objects Photo. Seul problème comme je l’ai dit plus haut, c’est que la requête n’est pas trié.

Vous allez me dire « c’est facile, il n’y a qu’à surcharger getPhotos() de Produit.class.php ». C’est ce que j’avais fait au début, et ça marche. Seul problème, c’est que lorsque l’on redéfini un accesseur magique (ici le getteur) l’autre (le setteur) ne fonctionne plus… est ce que c’est voulu ou est ce que c’est un bug? Je n’en sais rien ^^ Toujours est-il que je me servais du setteur et donc cette solution ne m’a pas convenu et j’ai cherché une alternative.

L’alternative est prévue par Doctrine qui depuis la 1.2 qui implémente la possibilité de spécifier le orderBy sur une relation directement lors de sa définition dans le schema.yml. Seul problème le foreinOrderBy n’existe pas et donc la définition de la relation ne peut plus se faire comme je l’avais écrite plus haut, il faut la définir des deux cotés.

Tréve de blabla, ca ressemble à quelque chose comme ca :

?View Code YML
...
Produit:
  columns:
    id:                 { type: integer(4), unsigned: true, primary: true, autoincrement: true }
    name:               { type: string(128), notnull: true }
  relations:
    Photos:
      type:             many
      class:            Photo
      local:            id
      foreign:          id_produit
      orderBy:          ordre ASC
      onDelete:         CASCADE
 
Photo:
  columns:
    id:                 { type: integer(4), unsigned: true, primary: true, autoincrement: true }
    file_name:          { type: string(128), notnull: true }
    id_produit:         { type: integer(4), unsigned: true }
    ordre:              { type: integer(4), unsigned: true }
  relations:
    Produit:
      local:            id_produit
      foreign:          id
      onDelete:         CASCADE
...

J’espère que cette petite astuce vous aidera.
@bientôt

]]> http://www.lexik.fr/blog/symfony/symfony/tips-symfony-1-31-4-orderby-des-relations-1026/feed 3 Gestion d’une galerie photo avec swfUpload dans l’admin http://www.lexik.fr/blog/symfony/symfony/gestion-dune-galerie-photo-avec-swfupload-dans-ladmin-918 http://www.lexik.fr/blog/symfony/symfony/gestion-dune-galerie-photo-avec-swfupload-dans-ladmin-918#comments Wed, 16 Sep 2009 09:49:18 +0000 olivier http://www.lexik.fr/sfblog/?p=918 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 :D

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

upload1

upload2

upload3

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

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

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

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

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

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

?View Code JAVASCRIPT
$('#photo-<?php echo $photo_id ?>').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
<?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
<?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
<?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
<?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
<?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
<?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 !

]]> http://www.lexik.fr/blog/symfony/symfony/gestion-dune-galerie-photo-avec-swfupload-dans-ladmin-918/feed 15 Du Javascript dynamique dans une vue en utilisant sf_format http://www.lexik.fr/blog/symfony/symfony/du-javascript-dynamique-dans-une-vue-en-utilisant-sf_format-746 http://www.lexik.fr/blog/symfony/symfony/du-javascript-dynamique-dans-une-vue-en-utilisant-sf_format-746#comments Wed, 08 Jul 2009 08:13:32 +0000 olivier http://www.lexik.fr/sfblog/?p=746 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 <script> directement au milieu du html (un peu crade mais efficace)
  • Faire un fichier .js « en dur » dans le dossier /web/js (mais là on perd la possibilité d’utiliser du php)
  • Utiliser un slot dans le <head> du template
  • Utiliser une vue

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

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

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

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

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

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

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

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

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

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

?View Code HTML
<script type="text/javascript" src="/actualites/index.js"></script>

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

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

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

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

?View Code PHP
<?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.
]]> http://www.lexik.fr/blog/symfony/symfony/du-javascript-dynamique-dans-une-vue-en-utilisant-sf_format-746/feed 0 Listes déroulantes mises à jours en Ajax avec jQuery http://www.lexik.fr/blog/symfony/symfony/listes-deroulantes-mises-a-jours-en-ajax-avec-jquery-704 http://www.lexik.fr/blog/symfony/symfony/listes-deroulantes-mises-a-jours-en-ajax-avec-jquery-704#comments Wed, 17 Jun 2009 08:49:39 +0000 olivier http://www.lexik.fr/sfblog/?p=704 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 :D

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>
<?php foreach($region->getDepartements() as $departement): ?>
<option value="<?php echo $departement->getId() ?>"><?php echo $departement->getNom() ?></option>
<?php endforeach; ?>

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

?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 :P ).

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’)

]]> http://www.lexik.fr/blog/symfony/symfony/listes-deroulantes-mises-a-jours-en-ajax-avec-jquery-704/feed 7 Utilisation de sfDoctrineGuardPlugin pour la gestion des utilisateurs http://www.lexik.fr/blog/symfony/symfony/utilisation-de-sfdoctrineguardplugin-pour-la-gestion-des-utilisateurs-634 http://www.lexik.fr/blog/symfony/symfony/utilisation-de-sfdoctrineguardplugin-pour-la-gestion-des-utilisateurs-634#comments Wed, 27 May 2009 12:01:50 +0000 olivier http://www.lexik.fr/sfblog/?p=634 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
<?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
<?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
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

 
/**
 * 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.')
    ));
  }
 
}
]]> http://www.lexik.fr/blog/symfony/symfony/utilisation-de-sfdoctrineguardplugin-pour-la-gestion-des-utilisateurs-634/feed 4 Schema.yml Doctrine, Bonnes pratiques, Convention de nommage et fonctions magiques http://www.lexik.fr/blog/symfony/symfony/schemayml-doctrine-bonnes-pratiques-convention-de-nommage-et-fonctions-magiques-508 http://www.lexik.fr/blog/symfony/symfony/schemayml-doctrine-bonnes-pratiques-convention-de-nommage-et-fonctions-magiques-508#comments Tue, 21 Apr 2009 13:14:33 +0000 olivier http://www.lexik.fr/sfblog/?p=508 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
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69

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
<?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 : <?php echo $test_utilisateur->getPrenom() ?></p>
 
<p>Photos : <?php echo $test_utilisateur->getGroupes()->count() ?></p>
 
<ul>
<?php foreach($test_utilisateur->getPhotos() as $photo): ?>
  <li><?php echo $photo->getFichier() ?></li>
<?php endforeach; ?>
</ul>
 
<p>Groupes : <?php echo $test_utilisateur->getGroupes()->count() ?></p>
 
<ul>
<?php foreach($test_utilisateur->getGroupes() as $groupe): ?>
  <li><?php echo $groupe->getNom() ?></li>
<?php 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
 
<?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 :D

]]> http://www.lexik.fr/blog/symfony/symfony/schemayml-doctrine-bonnes-pratiques-convention-de-nommage-et-fonctions-magiques-508/feed 5 Configurer Ubuntu pour envoyer des mails PHP à la sauce sendmail sans sendmail ! http://www.lexik.fr/blog/symfony/ubuntu/configurer-ubuntu-pour-envoyer-des-mails-php-a-la-sauce-sendmail-sans-sendmail-237 http://www.lexik.fr/blog/symfony/ubuntu/configurer-ubuntu-pour-envoyer-des-mails-php-a-la-sauce-sendmail-sans-sendmail-237#comments Fri, 13 Mar 2009 18:03:14 +0000 olivier http://www.lexik.fr/sfblog/?p=237 Sur windows la fonction mail() de php est configurée pour fonctionner via SMTP que l’on peut configurer dans le php.ini

Sur les systèmes Linux, ça n’est pas le cas. Php est configuré pour transmettre les mails via un vrai service de transport de mail du style sendmail ou postfix.
Le problème de ces programmes (demon), c’est qu’ils ne sont pas évidents à installer et configurer correctement pour tout les développeurs qui ne sont pas admin système.

Heureusement ESMTP est là pour nous sauver, nous autres simples développeurs.

Esmtp is a send-only sendmail emulator

Pour les anglophobes, ESMTP est un émulateur de sendmail pour l’envoi seulement des mails.
C’est à dire que c’est un programme qui comprend les commandes sendmail, les traduit en requêtes smtp et les transmet à un serveur smtp.

Installation et configuration de ESMTP

?View Code BASH
sudo apt-get install esmtp

Ou alors, vous le trouverez dans Synaptic.

Aprés quoi un petit coup de

?View Code BASH
sudo nano /etc/esmtprc

pour aller modifier la configuration et mettre le stmp que l’on veut utiliser (celui de votre provider).

?View Code BASH
# Config file for ESMTP sendmail
 
# The SMTP host and service (port)
hostname=smtp.orange.fr:25

Dernier petit point à voir, faire un lien symbolique de sendmail vers esmtp pour faire croire à php que sendmail est installé.

?View Code BASH
sudo ln -s /usr/bin/esmtp /usr/bin/sendmail

Et voila ! Vous pouvez coder des envois de mails, dans des conditions de production, avec la méthode sendmail sans avoir eu à passer des heures à configurer votre serveur de mail ;)

Source : http://esmtp.sourceforge.net/

]]> http://www.lexik.fr/blog/symfony/ubuntu/configurer-ubuntu-pour-envoyer-des-mails-php-a-la-sauce-sendmail-sans-sendmail-237/feed 1 Formulaire multiples http://www.lexik.fr/blog/symfony/symfony/formulaire-multiples-7 http://www.lexik.fr/blog/symfony/symfony/formulaire-multiples-7#comments Mon, 16 Feb 2009 09:29:12 +0000 olivier http://www.lexik.fr/sfblog/?p=7 Depuis la 1.1, les formulaires imbriqués sont gérés grace à la méthode embedForm de la classe sfForm

Un exemple avec le module sfDoctrineGuard que l’on veut éttendre avec un profil.

La classe du formulaire principal :

?View Code PHP
class sfGuardUserForm extends PluginsfGuardUserForm
{
  public function configure()
  {
    unset(
      $this['is_active'],
      ...
      $this['permissions_list']
    );
 
    $profile = new ProfileForm();
 
    unset(
      $profile['sf_guard_user_id']
    );
 
    $this->embedForm('Profile', $profile);
  }
}

L’action :

?View Code PHP
public function executeIndex(sfWebRequest $request)
{
  $this->form = new sfGuardUserForm();
 
  if( $request->isMethod('post') &amp;&amp; $this->form->bindAndSave() )
  {
    $this->getUser()->setFlash('notice', 'Utilisateur enregistré.');
    $this->redirect('utilisateur/index');
  }
}

Le problème c’est que le de bindAndSave() sur le formulaire principal provoque 2 save sur le formulaire embarqué.

Du coup si il y a des champs unique dans le formulaire embarqué et surtout un notnull sur la clé de jointure, ca plante.

La méthode alternative pour arriver au même résultat :

Pas la peine de redéfinir la classe formulaire.

Tout se passe dans la classe action ou on va définir les 2 formulaires à utiliser dans la vue et le traitement associé.

?View Code PHP
  public function executeInscription(sfWebRequest $request)
  {
    $this->formUser    = new sfGuardUserFormInscription();
    $this->formProfile = new UtilisateurFormInscription();
 
    if( $request->isMethod('post') )
    {
      $this->formUser->bind($request->getParameter('sf_guard_user', array()));
      $this->formProfile->bind($request->getParameter('utilisateur', array()));
 
      if( $this->formUser->isValid() &amp;&amp; $this->formProfile->isValid() )
      {
        $con = Doctrine_Manager::connection();
 
        try
        {
          $con->beginTransaction();
 
          $newUser = $this->formUser->save($con);
          $newProfil = $this->formProfile->save($con);
 
          $newProfil->setUserId($newUser->getId());
          $newProfil->save($con);
 
          $con->commit();
        }
        catch(Exception $e)
        {
          $con->rollback();
 
          throw $e;
        }
 
        $this->getUser()->setFlash('notice', "Votre inscription a bien été prise en compte.\nVous allez recevoir un email dans quelques minutes pour valider votre inscription.");
        $this->redirect('utilisateur/index');
      }
 
    }
  }

Pour garantir l’intégrité des données il faut passer par une transaction que l’on est obligé de gérer à la main. (avec embedForm elle est gérée automatiquement)

Le code html avec les deux formulaires :

?View Code PHP
<form action="<?php echo url_for('utilisateur/inscription'); ?>" method="post">
  <table>
    <?php echo $formUser ?>
    <?php echo $formProfile ?>
    <tr>
      <td colspan="2"><input type="submit" value="<?php echo __('Signin') ?>" /></td>
    </tr>
  </table>
</form>
]]> http://www.lexik.fr/blog/symfony/symfony/formulaire-multiples-7/feed 1