Date : Jeudi 8 Septembre
Lieu : au Fitzpatrick’s Irish pub (Map)
Heure : à partir de 18H30.

Vous pensez venir, passez sur le Doodle!

Les apéros web ont pour objectif de donner un cadre d’échange aux acteurs du web. Que vous soyez développeurs, webdesigner, chef de projet agile ou non, au marketing, ou resp. d’entreprise les apéros web vous permettront de discuter hors contexte entreprise / travail de votre métier et pouvoir échanger librement sur vos problématiques.

A partir de 19H00
The Shakespeare Pub
12 Rue de la Petite Loge, 34000 Montpellier
04 67 60 22 25 ‎


Agrandir le plan

Retrouvez nos développeurs Symfony cachés entre des div et des hn.

Quoi de neuf chez Lexik ?

• un nouveau logo ;
• des projets Symfony2 ;
• de nouveaux développeurs ;
• un championnat de pétanque tout l’été ;
• des applications mobiles pour le blog.

Votre profil :

De formation BTS / DUT ou école d’ingénieur, vous justifiez d’une expérience significative dans le milieu du développement Web.

Vous bénéficiez d’une bonne expérience à titre privé ou professionnel dans les technologies suivantes :

• XHTML / CSS ;
• PHP 5, orienté objet ;
• SQL (MySQL, SQLite, PostgreSQL, …).

Une expérience ou un intérêt dans les domaines suivants seront un atout :

• Framework symfony 1.4 / Symfony2 avec l’ORM Doctrine ;
• Gestionnaire de version (Git / SVN) ;
• Javascript ;
• Tests unitaires et fonctionnels / Intégration continue ;
• Méthodologie de développement agile (SCRUM).

Détails :

Envoyez-nous votre CV et lettre de motivation par email à l’adresse : contact@lexik.fr

• Type de contrat : CDI
• Lieu : Pérols
• Début du contrat : ASAP
• Télétravail : non
• Rémunération selon profil

http://www.lexik.fr/

Le but est juste de savoir comment faire pour avoir accès à l’event dispatcher depuis les classes du modèle, de manière à pouvoir lever des événements « métiers » qui permettent des traitements qui se rapprochent des trigger sql. L’avantage est de rester au sein de l’application symfony et ne pas disperser la logique. C’est une problèmatique que nous avons rencontré à plusieurs reprises dans les projets et nous avons pu trouver cette implementation grace à n1k0 de chez Akei.

(Pour la suite, je vais me servir d’une partie du modèle de Jobeet comme je l’avais fait dans mon post précédent)

A la base, l’event dispatcher se trouve dans le contexte, et donc accessible principalement depuis les actions des modules. L’idée est de le rendre accessible aux classes du modèle doctrine de manière à pouvoir notifier des événements « métier » directement depuis les méthodes. On va donc passer l’event dispatcher à la classe de base dont hérite toutes les classes du modèle. Ou plus exactement, on va rajouter une classe custom dans la pile d’héritage des classes du modèle.

On créé donc une classe CustomDoctrineRecord, que je place dans /lib/model/doctrine/record/CustomDoctrineRecord.class.php pour éviter qu’elle se retrouve noyée avec les classes du modèle. On va faire passer à cette classe l’event dispatcher par des méthodes statiques.
Les classes de base du modèle héritent de sfDoctrineRecord, il faut donc impérativement que la classe custom hérite elle aussi de sfDoctrineRecord.

Fichier : /lib/model/doctrine/record/CustomDoctrineRecord.class.php

<?php
 
abstract class CustomDoctrineRecord extends sfDoctrineRecord
{
  static protected $dispatcher = null;
 
  /**
   * Sets the EventDispatcher
   *
   * @param sfEventDispatcher $dispatcher 
   */
  static public function setEventDispatcher(sfEventDispatcher $dispatcher)
  {
    self::$dispatcher = $dispatcher;
  }
 
  /**
   * Returns the EventDispatcher
   *
   * @return sfEventDispatcher
   */
  static public function getEventDispatcher()
  {
    return self::$dispatcher;
  }
 
  /**
   * Returns if EventDispatcher is available
   *
   * @return boolean
   */
  static public function hasDispatcher()
  {
    return (self::getEventDispatcher() instanceOf sfEventDispatcher);
  }
}

Maintenant il faut spécifier à doctrine d’utiliser notre classe custom comme classe de référence des classes modèles, on utilise la méthode configureDoctrine() de sfProjectConfiguration. Aprés quoi on va avoir besoin de passer l’event dispatcher à notre classe. On va donc catcher l’événement « context.load_factories » qui est déclenché une fois que le contexte est initialisé pour aller initialiser la classe CustomDoctrineRecord.

Fichier : /config/ProjectConfiguration.class.php

<?php
 
require_once dirname(__FILE__).'/../lib/vendor/symfony/lib/autoload/sfCoreAutoload.class.php';
sfCoreAutoload::register();
 
class ProjectConfiguration extends sfProjectConfiguration
{
  public function setup()
  {
    parent::setup();
 
    $this->enablePlugins(array(
      'sfDoctrinePlugin',
    ));
 
    $this->dispatcher->connect('context.load_factories', array($this, 'listenToContextFactoriesLoaded'));
  }
 
  /**
   * Defines the base objects' classe
   */
  public function configureDoctrine(Doctrine_Manager $manager)
  {
    sfConfig::set('doctrine_model_builder_options', array(
      'baseClassName' => 'CustomDoctrineRecord'
    ));
  }
 
  /**
   * Objects can acces the EventDispatcher
   */
  public function listenToContextFactoriesLoaded(sfEvent $event)
  {
    CustomDoctrineRecord::setEventDispatcher($event->getSubject()->getEventDispatcher());
  }
}

Aprés ca, il nous reste à faire un petit

./symfony doctrine:build --all-classes

Et on peut vérifier l’inpact en ouvrant une classe de base, et on trouve bien que la classe hérite de notre classe CustomDoctrineRecord

Fichier : /lib/model/doctrine/base/BaseJobeetJob.class.php

<?php
...
abstract class BaseJobeetJob extends CustomDoctrineRecord
{
...

Il est donc maintenant possible de lever des événements depuis les classes du modèle. Pour exemple je vais lever un événement à l’insertion d’un nouveau Job. Cet événement pourra être utilisé par la suite pour faire ce que l’on veut, comme par exemple envoyer une email au modèrateur l’informant qu’un nouveau job a été saisi sur le site.

Fichier : /lib/model/doctrine/JobeetJob.class.php

<?php
 
class JobeetJob extends BaseJobeetJob
{
  /**
   * @param Doctrine_Event $event 
   */
  public function postInsert($event)
  {
    if (self::hasDispatcher())
    {
      if (self::getEventDispatcher()->hasListeners('JobeetJob.Inserted'))
      {
        self::getEventDispatcher()->notify(new sfEvent($this, 'JobeetJob.Inserted'));
      }
    }
  }
}

C’est un exemple tout simple, mais les possibilités sont immenses. Attention aux événements en cascades, ca peut très vite devenir un casse tête à debugger !

Dernier petit tips, pour pouvoir faire des tests de vos méthodes qui lèvent des événements : c’est à mis chemin entre les tests unitaires et les tests fonctionnels. J’ai voulu tester des enchainements de méthodes qui levaient des événements, et je voulais vérifier que les règles de gestion étaient respectées. Je suis donc parti du bootstap unitaire où j’ai initialisé un contexte que je passe à ma classe de base, de manière à ce que les événements soient diffusés.

Fichier : /test/bootstrap/unit_event.php

<?php
 
include(dirname(__FILE__).'/unit.php');
 
$configuration = ProjectConfiguration::getApplicationConfiguration('frontend', 'test', true);
$context = sfContext::createInstance($configuration);
CustomDoctrineRecord::setEventDispatcher($configuration->getEventDispatcher());

Quand on commence à utiliser les événements, il y a deux réactions possibles. Il y a les réfractaires qui disent « c’est null, ca sert a rien », soit on devient accro et on commence à en mettre de partout. Si vous faites parti du deuxième groupe, voici quelques conseils élémentaires mais important à respecter pour éviter que le debuggage se transforme en calvaire :

• mettre des noms d’événements explicites ;
• centraliser les écouteurs.

Bon codage à tous, et bonnes fêtes

De formation initiale informatique (de bac à +5), vous êtes un développeur confirmé en PHP/MySQL (environnement LAMP et WAMP) avec une expérience d’au moins 1 ans au sein d’une SSII ou d’une web agency.

Compétences requises :
- Framework PHP Symfony
- bonnes connaissances des environnements WAMP (Windows) et LAMP
- MySQL et SQL
- PHP (programmation objet)
- (X)HTML, DHTML , JavaScript, CSS.
- AJAX
- Javascript, jQuery
- standards du web (W3C)
- Connaissance de subversion

Qualités recherchées :
- curiosité
- force de proposition
- sens du travail en équipe

Disponibilité :
- ASAP

Poste à Montpellier 34000

Contactez Samuel Breton, Tél : 04 67 99 63 19
Email : contact@lexik.fr
CV + LM

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 :

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

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

Pour vous situer, il s’agit d’un site de vente en ligne.
Qui dit vente dit produits, et qui dit produits dit photos

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

On a choisi de gérer l’upload avec swfUpload qui gére un liste d’attente pour l’upload de plusieurs fichiers. Et l’upload en background qui ne gèle pas la page, ca fait plus web2.0 :p
(http://code.google.com/p/swfupload/)

J’ai téléchargé le SWFUpload v2.2.0.1 Samples.zip et j’ai utilisé les fichiers du répertoire « simpledemo » que j’ai réparties comme suis.
(Le fichier css d’origine s’appelait default.css, je l’ai renommé pour des raisons évidentes.)

• /web/swf/swfupload.swf
• /web/css/swfUpload.css
• /web/js/swfupload.js
• /web/js/swfupload.queue.js
• /web/js/fileprogress.js
• /web/js/handlers.js
• /web/images/XPButtonUploadText_61x22.png

Un coup d’oeil rapide à la partie du schema.yml qui nous intéresse. Rien de transcendant, un objet Produit avec quelques champs types et l’objet ProduitPhoto qui lui est lié. Sur l’objet ProduitPhoto, un filename et un booléen pour définir l’image par défaut du produit.

...
Produit:
  tableName:        monprojet_produit
  actAs:
    Timestampable:  ~
  columns:
    id:             { type: integer(4), unsigned: true, primary: true, autoincrement: true }
    nom:            { type: string(255), notnull: true }
    description:    { type: clob }
    prix:           { type: decimal, scale: 2 }
 
ProduitPhoto:
  tableName:        monprojet_produit_photo
  columns:
    id:             { type: integer(4), unsigned: true, primary: true, autoincrement: true }
    produit_id:     { type: integer(4), unsigned: true }
    filename:       { type: string(255), notnull: true }
    is_default:     { type: boolean, default: false }
  relations:
    Produit:
      local:        produit_id
      foreign:      id
      foreignAlias: Photos
      onDelete:     CASCADE
...

On génére l’admin-generator pour l’objet produit.

./symfony doctrine:generate-admin backend Produit

Et c’est partie !

Pour rajouter cette gestion des images dans l’ecran d’édition des produits il faut rajouter un partial à la vue edit.
(On la rajoute uniquement sur l’edit, car sur l’écran create, l’objet n’est pas encore persisté en base et donc on ne peut pas lui rattacher des objets ProduitPhoto)

Le fonctionnement est le suivant. Le partial général où est inclus et configuré swfUpload (_photoUpload.php). Un parial _photoListe.php inclus dans _photoUpload.php qui servira pour raffraichir la liste en ajax (avec jQuery). Et un dernier partial _ajaxPhotoDelete.php qui ne sert qu’a retourner l’animation à faire lors de la suppression d’une photo.

On commence par positionner le partial _photoUpload.php dans le generator.yml en contexte edit.

generator:
  class: sfDoctrineGenerator
  param:
    model_class:           Produit
    theme:                 admin
    non_verbose_templates: true
    with_show:             false
    singular:              ~
    plural:                ~
    route_prefix:          produit_produit
    with_doctrine_route:     1
 
    config:
      actions: ~
      fields:
        created_at:        { label: Date de création, date_format: dd/MM/yyyy }
        updated_at:        { label: Date de modification, date_format: dd/MM/yyyy }
        nom:               { label: Nom }
        description:       { label: Déscription }
      list:
        title:             Liste des produits
        display:           [=id, =nom]
      filter: ~
      form: ~
      edit:
        title:             Modifier un produit
        display:
          "Produit":       [id, nom, description]
          "Photos":        [_photoUpload]
          "Dates":         [created_at, updated_at]
      new:
        title:             Ajouter un produit
        display:
          "Produit":       [id, nom, description]
          "Dates":         [created_at, updated_at]

Et on va se pencher plus en détail sur ce partial _photoUpload.php.

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

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

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

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

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

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

$('#photo-<?php echo $photo_id ?>').effect('drop');

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

...
produit_photo:
  url:     /produit/:id/upload
  class:   sfDoctrineRoute
  options: { model: Produit, type: object }
  param:   { module: produit, action: upload }
  requirements:
    sf_method: [get, post]
 
produit_photo_ajax_default:
  url:     /produit_photo/:id/default
  class:   sfDoctrineRoute
  options: { model: ProduitPhoto, type: object }
  param:   { module: produit, action: ajaxPhotoDefault }
  requirements:
    sf_method: [post]
 
produit_photo_ajax_delete:
  url:     /produit_photo/:id/delete
  class:   sfDoctrineRoute
  options: { model: ProduitPhoto, type: object }
  param:   { module: produit, action: ajaxPhotoDelete }
  requirements:
    sf_method: [post]
 
produit_ajax_photo_liste:
  url:     /produit_photo/:id/list
  class:   sfDoctrineRoute
  options: { model: Produit, type: object }
  param:   { module: produit, action: ajaxPhotoListe }
  requirements:
    sf_method: [post]
...

On utilise la classe formulaire qui va gérer l’upload.
Il faut désactiver le csrf car l’envoie n’est pas effectué par le formulaire mais par l’animation flash.

<?php
 
class ProduitPhotoForm extends BaseProduitPhotoForm
{
  public function configure()
  {
    $this->widgetSchema['produit_id'] = new sfWidgetFormInputHidden();
    $this->widgetSchema['is_default'] = new sfWidgetFormInputHidden();
    $this->widgetSchema['filename'] = new sfWidgetFormInputFile(array());
 
    $this->validatorSchema['filename'] = new sfValidatorFile(array(
      'required'   => true,
      'path'       => sfConfig::get('sf_upload_dir').'/produits/source',
      'mime_types' => 'web_images',
      'max_size'   => 10485760
    ), array(
      'max_size' => 'Fichier trop gros (10Mo maximum).'
    ));
 
    $this->disableCSRFProtection();
  }
}

Et enfin l’action.class.php qui orchestre tout ca.
Au niveau de l’action executeUpload il faut créer « à la main » le tableau des paramètres à passer au bind.

<?php
 
require_once dirname(__FILE__).'/../lib/produitGeneratorConfiguration.class.php';
require_once dirname(__FILE__).'/../lib/produitGeneratorHelper.class.php';
 
/**
 * produit actions.
 *
 * @package    
 * @subpackage produit
 * @author     
 * @version    SVN: $Id: actions.class.php 12474 2008-10-31 10:41:27Z fabien $
 */
class produitActions extends autoProduitActions
{
 
  public function executeUpload(sfWebRequest $request)
  {
    $this->produit = $this->getRoute()->getObject();
    $this->forward404unless($this->produit);
 
    $this->form = new ProduitPhotoForm();
 
    $values = array(
      'produit_id' => $this->produit->getId(),
      'is_default' => ($this->produit->getPhotos()->count() > 0) ? false : true,
      'filename'   => $request->getFiles('photo')
    );
 
    $this->form->bind($values, $values);
 
    if ($this->form->isValid())
    {
      $photo = $this->form->save();
 
      $return = 'ok';
    }
    else
    {
      $return = 'ko';
    }
 
    return $this->renderText($return);
  }
 
 
  /**
   * ajax pour definir une photo par defaut
   *
   * @param sfWebRequest $request
   */
  public function executeAjaxPhotoDefault(sfWebRequest $request)
  {
    if($request->isXmlHttpRequest())
    {
      $photo = $this->getRoute()->getObject();
      $produit = $photo->getProduit();
 
      $old_default = $produit->getPhotoDefault();
 
      $produit->setPhotoDefaut($photo->getId());
 
      return $this->renderPartial('produit/photoListe', array('photos' => $produit->getPhotos()));
    }
    else
    {
      $this->redirect404();
    }
  }
 
 
  /**
   * ajax pour effacer une photo
   *
   * @param sfWebRequest $request
   */
  public function executeAjaxPhotoDelete(sfWebRequest $request)
  {
    if($request->isXmlHttpRequest())
    {
      $photo = $this->getRoute()->getObject();
      $photo_id = $photo->getId();
      $photo->delete();
 
      return $this->renderPartial('produit/ajaxPhotoDelete', array('photo_id' => $photo_id));
    }
    else
    {
      $this->redirect404();
    }
  }
 
 
  /**
   * ajax pour avoir la liste des photos
   *
   * @param sfWebRequest $request
   */
  public function executeAjaxPhotoListe(sfWebRequest $request)
  {
    if($request->isXmlHttpRequest())
    {
      $produit = $this->getRoute()->getObject();
 
      return $this->renderPartial('produit/photoListe', array('photos' => $produit->getPhotos()));
    }
    else
    {
      $this->redirect404();
    }
  }
 
 
}

Produit.class.php

<?php
 
class Produit extends BaseProduit
{
 
  public function setPhotoDefaut($photoId)
  {
    Doctrine_Query::create()
    ->update('ProduitPhoto p')
    ->set('p.is_default', '?', false)
    ->where('p.produit_id = ?', $this->getId())
    ->execute();
 
    Doctrine_Query::create()
    ->update('ProduitPhoto p')
    ->set('p.is_default', '?', true)
    ->andWhere('p.id = ?', $photoId)
    ->execute();
 
    return true;
  }
 
  public function getPhotoDefault()
  {
    return Doctrine::getTable('ProduitPhoto')->getDefault($this->getId());
  }
 
}

ProduitPhotoTable.class.php

<?php
 
class ProduitPhotoTable extends Doctrine_Table
{
 
  public function getDefault($produit_id)
  {
    return $this->createQuery('c')
      ->andWhere('c.produit_id = ?', $produit_id)
      ->andWhere('c.is_default = ?', true)
      ->fetchOne();
  }
 
}

ProduitPhoto.class.php

<?php
 
class ProduitPhoto extends BaseProduitPhoto
{
 
  public function isDefault()
  {
    return (bool) $this->getIsDefault();
  }
 
}

Le problème !

A ce stade, tout est fini et en place pour que ca marche. Hors ca ne marche pas… Pourquoi ? Je rapelle le contexte, on est dans l’admin donc on est identifié et c’est là le problème. En effet swfUpload est une animation flash contenu dans le page mais qui va initialiser des requêtes http parallèles à celle utilisée par le navigateur. Et donc lorsque swfUpload se pointe à l’url « produit_photo » pour initialisé son upload, il se prend une belle erreur 403…

Le problème est connu des concepteurs de swfUpload et la solutions qu’ils préconisent est de forcé l’identifiant de session dans le script d’upload en faisant un session_id($session_id). C’est pourquoi on le fait passer dans la variable « post_params » à l’initialisation de swfUpload.

Pour faire la même chose dans symfony on ne peut pas le faire dans une action, car la session est déjà initialisée à ce niveau. On est obligé d’aller modifié le factories.yml et la calsse la classe sfSessionStorage pour aller forcer l’identifiant de session dans le cas ou on fait appel à l’action upload.

C’est un tip que j’ai trouvé sur le forum symfony qui était pour la version 1.0, et qui fonctionne toujours à la différence que le contexte n’est plus passé en paramètre dans la 1.2 et donc il faut aller le charger.

factories.yml

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

mySessionStorage.calss.php

<?php
 
class mySessionStorage extends sfSessionStorage
{
  public function initialize($options = null)
  {
    $context = sfContext::getInstance();
 
    //Shitty work-around for swfuploader
    if( $context->getActionName() == "upload")
    {
      $sessionName = $parameters["session_name"];
 
      if($value = $context->getRequest()->getParameter($sessionName))
      {
        session_name($sessionName);
        session_id($value);
      }
    }
 
    parent::initialize($options);
  }
}

Ça y est, cette fois ça marche !
Et vous avez une gestion d’images directement dans la fiche du produit qui est assez user-friendly

Merci d’avoir lu jusqu’au bout :p
Je reste à votre disposition pour toute questions ou suggestions
@bientôt !

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

• Mettre des balises <script> directement au milieu du html (un peu crade mais efficace)
• Faire un fichier .js « en dur » dans le dossier /web/js (mais là on perd la possibilité d’utiliser du php)
• Utiliser un slot dans le <head> du template
• Utiliser une vue

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

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

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

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

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

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

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

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

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

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

<script type="text/javascript" src="/actualites/index.js"></script>

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

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

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

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

<?php
 
class actuActions extends sfActions
{
 
  public function executeIndex(sfWebRequest $request)
  {
    if($request->getParameter('sf_format') != 'js')
    {
      $this->actus = Doctrine::getTable('Actu')->getLast();
    }
  }
 
}

Après, libre a chacun de voir si on doit utiliser la même action que la vue html ou si la vue javascript nécessite sa propre action.

En utilisant une action séparée pour la vue javascript on peut s’amuser à pousser le vice du camouflage en utilisant un routing qui fasse croire que l’on appelle un fichier .js (Attention si jamais un fichier avec le même nom existe réellement dans le répertoire /web/js c’est ce dernier qui sera inclus).

...
actu_index_js:
  url:   /js/actu.:sf_format
  param: { module: actu, action: index, sf_format: js }
...

Avantage de cette technique :

• Un code source html super « clean »

Inconvéniant :

• Pour une page html, on fait deux appels à symfony.
  A utiliser avec parcimonie et bien optimiser les actions pour ne pas faire des requêtes inutiles sur la base de donnée.

Vite fait, le schéma utilisé :

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

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

L’action :

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

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

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

Un programme qui semble très intéressant est ici : http://www.symfony-live.com/schedule

Si vous souhaitez participer aussi ne tardez plus à vous inscrire :  http://www.symfony-live.com/

Vous pourrez retrouver Yoann la bas.

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.

 
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 :

 
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

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

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.

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

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

 
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

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.')
    ));
  }
 
}

Stage Développeur PHP :

Compétence : Connaissance de PHP5, POO
Profil : Rigoureux, curieux.
Mission : Vous integrez notre équipe de développement sur la réalisation de projet Interne : Intranet/Site Internet.
Développement avec le Framework Symfony

Stage Marketing et gestion site Internet

Compétence : Connaissance d’Internet, bureautique
Profil : Appliqué, bonne rédaction
Mission : Vous travaillerez sur la visibilité des projets mis en ligne ainsi que sur les actions marketing et le référencement.

Envoyez CV : contact@lexik.fr

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.

• Les types de colonnes
• Les relations
• Les data validations
• Les behaviors

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

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 :

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

L’accesseur magique sera :

$ma_photo->getUtilisateur();

Alors que si on appelle la relation en minuscule :

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

L’accesseur magique sera

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

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.

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.

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

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

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 :

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 :

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 :

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

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 :

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:

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

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

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

 
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

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

 
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

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 :

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

<?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(<<<EOF
<b id="%s">%s</b>
<script type="text/javascript">
$(function() {
  $("#%s").editable(
    "%s",
    {
      indicator : 'Saving...',      
      type   : "text",
      submit : "OK",
      style  : "inherit",
      id       : 'ajaxfield_id'
  });
});
</script>
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.

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

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 »

# 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

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

// 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</h1> <?php echo $form['firstname']->render();?><br> <?php echo $form['lastname']->render();?><br> <?php echo $form['email']->render();?><br>

• saveEIPSuccess.php
  ^?View Code PHP

  <?php echo $value ?>

Formulaire

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

  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

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

Pré-requis

• Plugin sfFormExtraPlugin installé : sfFormExtraPlugin

Fichiers externes

• Télécharger jQuery UI
  (jquery-1.3.2.min.js, jquery-ui-1.7.1.custom.min.js)

  Vous pouvez télécharger une version « customizée » de jQuery UI ici :
  Télécharger JQuery UI

• Version française
  (uidatepicker-fr.js)

  Vous trouverez le patch français de ce plugin ici :

  Datepicker jQuery en français

• Intégration dans Symfony
  1. JS
     Copiez les fichiers :
     [jquery UI]/js/jquery-1.3.2.min.js
     [jquery UI]/js/jquery-ui-1.7.1.custom.min.js
     uidatepicker-fr.js
     directement dans [votre_projet]/web/js
  2. CSS
     • Copiez le fichier :
       [jquery UI]/css/jquery-ui-1.7.1.custom.css dans :
       [votre_projet]/web/css.
     • !! Attention !! :
       J’ai dû remplacer toutes les occurrences de :
       url(images/ par :
       url(../images/
  3. Images
     N’oubliez pas de copier le contenu de :
     [jquery UI]/css/smoothness/images dans :
     [votre_projet]/web/images

View.yml

N’oubliez pas de faire référence aux fichiers externes dans le view :

default:
  http_metas:
    content-type: text/html
 
  metas:
    #title:        symfony project
    #description:  symfony project
    #keywords:     symfony, project
    #language:     en
    #robots:       index, follow
 
  stylesheets:    [main.css, jquery-ui-1.7.1.custom.css]
 
  javascripts:    [jquery-1.3.2.min.js, uidatepicker-fr.js, jquery-ui-1.7.1.custom.min.js]
 
  has_layout:     on
  layout:         layout

sfWidgetFormJQueryI18nDate.class.php

J’ai modifié la classe sfWidgetFormJQueryDate pour qu’elle soit compatible avec un format de date français.
De plus, on peut facilement configurer les options du widget jQuery.

• Code source :
  Fichier : sfWidgetFormJQueryI18nDate.class.php
  Chemin : /plugins/sfFormExtraPlugin/lib/widget/
  ^?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 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112

  <?php /* * This file is part of the symfony package. * (c) Fabien Potencier <fabien.potencier@symfony-project.com> * * For the full copyright and license information, please view the LICENSE * file that was distributed with this source code. */   /** * sfWidgetFormJQueryDate represents a date widget rendered by JQuery UI. * * This widget needs JQuery and JQuery UI to work. * * @package symfony * @subpackage widget * @author Fabien Potencier <fabien.potencier@symfony-project.com> * @version SVN: $Id: sfWidgetFormJQueryDate.class.php 12875 2008-11-10 12:22:33Z fabien $ */ class sfWidgetFormJQueryI18nDate extends sfWidgetFormI18nDate { /** * Configures the current widget. * * Available options: * * * image: The image path to represent the widget (false by default) * * config: A JavaScript array that configures the JQuery date widget * * culture: The user culture * * @param array $options An array of options * @param array $attributes An array of default HTML attributes * * @see sfWidgetForm */   protected function configure($options = array(), $attributes = array()) { $this->addOption('image', false); $this->addOption('config', $options["config"]); $this->addOption('culture', $options["culture"]); $this->addOption('years', $options["years"]);   parent::configure($options, $attributes);   if ('en' == $this->getOption('culture')) { $this->setOption('culture', 'en'); } }   /** * @param string $name The element name * @param string $value The date displayed in this widget * @param array $attributes An array of HTML attributes to be merged with the default HTML attributes * @param array $errors An array of errors for the field * * @return string An HTML tag string * * @see sfWidgetForm */ public function render($name, $value = null, $attributes = array(), $errors = array()) { $prefix = $this->generateId($name);   $image = ''; if (false !== $this->getOption('image')) { $image = sprintf(', buttonImage: %s, buttonImageOnly: true', $this->getOption('image')); } return parent::render($name, $value, $attributes, $errors). $this->renderTag('input', array('type' => 'hidden', 'size' => 10, 'id' => $id = $this->generateId($name).'_jquery_control', 'disabled' => 'disabled')). sprintf(<<<EOF <script type="text/javascript">   function %s_read_linked() { \$("#%s").val(\$("#%s").val() + "/" + \$("#%s").val() + "/" + \$("#%s").val());   return {}; }   function %s_update_linked(date) { \$("#%s").val(date.substring(0, 2)); \$("#%s").val(parseInt(date.substring(3, 5), 10)); \$("#%s").val(date.substring(6, 10)); }   \$("#%s").datepicker(\$.extend({}, { minDate: new Date(%s, 1 - 1, 1), maxDate: new Date(%s, 12 - 1, 31), onSelect: %s_update_linked, beforeShow: %s_read_linked, %s showOn: "both" %s }, \$.datepicker.regional["%s"]));   </script> EOF , $prefix, $id, $this->generateId($name.'[day]'), $this->generateId($name.'[month]'), $this->generateId($name.'[year]'), $prefix, $this->generateId($name.'[day]'), $this->generateId($name.'[month]'), $this->generateId($name.'[year]'), $id, min($this->getOption('years')), max($this->getOption('years')), $prefix, $prefix, $this->getOption('config'), $image, $this->getOption('culture') ); } }

• Explication des modifications :
  1. Ligne 20 :
     Notre widget dérive désormais de sfWidgetFormI18nDate
     ^?View Code PHP

     20	class sfWidgetFormJQueryDate extends sfWidgetFormI18nDate

  2. Lignes 40, 41 et 42:
     On ajoute les options « config », « culture » et « years » avec le paramètre « options » de la fonction « configure » :
     ^?View Code PHP

     40 41 42

     $this->addOption('config', $options["config"]); $this->addOption('culture', $options["culture"]); $this->addOption('years', $options["years"]);

  3. Lignes 85 et 86
     • Il faut inverser l’ordre du jour et du mois pour être compatible avec un format français, ce qui revient dans un sprintf, à changer l’ordre des lignes dans le code.
     • Il faut faire un parseInt sur le mois pour transformer « 01″ en « 1″, parseInt est la fonction javascript permettant de caster une chaîne de caractères en Integer :
       Premier paramètre : la chaîne à caster (ici : date.substring(3, 5) )
       Deuxième paramètre : Le système numérique à utiliser (ici décimal : 10)
     ^?View Code PHP

     85 86

     \$("#%s").val(date.substring(0, 2)); \$("#%s").val(parseInt(date.substring(3, 5), 10));

  4. Lignes 95 et 109
     • On passe les options directement dans le premier argument.
       Le %s de la ligne 95 correspond au $this->getOption(‘config’) de la ligne 109
       Le %s de la ligne 98 correspond au $this->getOption(‘culture’) de la ligne 109
     • Ligne 109 : passage des options et da la culture au widget.
     ^?View Code PHP

     108	$prefix, $prefix, $this->getOption('config'), $image, $this->getOption('culture')

Exemple d’utilisation

• Schéma
  ^?View Code YML

  person: columns: [...] birthday: type: timestamp [...]

• Formulaire (Instanciation du widget)
  ^?View Code PHP

  [...] public function configure() { for($i = 1900; $i<2010; $i++) { $years[$i] = $i; } $this->widgetSchema['birthday'] = new sfWidgetFormJQueryI18nDate( array('config' => 'yearRange: \'1900:2009\', changeYear: true, changeMonth: true,', 'culture' => 'fr', 'years'=> array_combine($years, $years)) ); } [...]

• Aperçu
  

Sources

• Symfony Internationalisation and Localisation
• Symfony Widgets
• jQuery UI
• Remy Solnais jquery et datepicker en Français
• W3schools parseInt en Javascript
• PHP.net fonction sprintf
• ImageShack

Classe formulaire

Définition des widgets et des validators.

Action

Déclaration du formulaire.
ex :

$this->form = new ContactForm();

Template

Affichage.
ex :

<form action="&lt;?php echo url_for('contact/index') ?&gt;" method="post">
 
<input type="submit" />
</form>

Pré-requis :

• Le lien qui m’a permis de faire ce post :
  http://trac.symfony-project.org/wiki/HowToUseFCKeditor
• Un module admin doctrine nommé ici « contenu », avec un champ nommé « html » de type CLOB
• Le plugin sfFormExtraPlugin installé (http://www.symfony-project.org/plugins/sfFormExtraPlugin)

Intégrer FCK

• Télécharger les fichiers
  http://www.fckeditor.net/download
• Copier les dans web/js/fckeditor
• Modifier
  

  /apps/backend/config/settings.yml

  ^?View Code YAML

  ... .settings: rich_text_fck_js_dir: js/fckeditor ...

Créer un nouveau widget pour sfFormExtraPlugin

Créer ce fichier :

/plugin/sfFormExtraPlugin/lib/widget/sfWidgetFormTextareaFCK.class.php

<?php
/**
    * FCK Form widget
    *
    * @package    ***
    * @subpackage lib
    * @author     $LastChangedBy: PoWl $
    * @version    SVN: $Id: sfWidgetFormTextareaFCK.class.php 81 2008-12-08 00:39:59Z PoWl $
    */
 
class sfWidgetFormTextareaFCK extends sfWidgetFormTextarea
{
    /**
        * @param array $options     An array of options
        * @param array $attributes  An array of default HTML attributes
        *
        * @see sfWidgetForm
        */
    protected function configure ($options = array(), $attributes = array())
    {
        $this->addOption ('editor', 'fck');
        $this->addOption ('css', false);
 
        parent::configure ($options, $attributes);
    }
 
    /**
        * @param  string $name        The element name
        * @param  string $value       The value displayed in this widget
        * @param  array  $attributes  An array of HTML attributes to be merged with the default HTML attributes
        * @param  array  $errors      An array of errors for the field
        *
        * @return string An HTML tag string
        *
        * @see sfWidgetForm
        */
    public function render ($name, $value = null, $attributes = array(), $errors = array())
    {
        $editorClass = 'sfRichTextEditorFCK';
        if (!class_exists ($editorClass)) {
            throw new sfConfigurationException (sprintf ('The rich text editor "%s" does not exist.', $editorClass));
        }
 
        $editor = new $editorClass ();
        if (!in_array ('sfRichTextEditor', class_parents ($editor))) {
            throw new sfConfigurationException (sprintf ('The editor "%s" must extend sfRichTextEditor.', $editor));
        }
 
        $attributes = array_merge ($this->attributes, $this->getOptions ());
        $editor->initialize ($name, $value, $attributes);
        return $editor->toHTML ();
    }
}
?>

J’ai fait trois modifications dans le fichier proposé par le site dont je donne le lien plus haut :

1. Ligne 1 : Attention au cas ou le short tag n’est pas activé
2. Standardisation du nom de la classe (sfWidgetFormTextareaFCK)
3. Ligne 49 : Il faut modifier cette ligne pour pouvoir passer des attributs HTML par defaut au widget:
   ^?View Code PHP

   $attributes = array_merge ($this->attributes, $this->getOptions ());

Utilisation

Modifier le formulaire de Contenu :

/lib/form/doctrine/ContenuForm.class.php

$this->widgetSchema['html'] = new sfWidgetFormTextareaFCK(
  array(),
  array('height'=>'700','width'=>'800'
));
     ...

Configurer l’upload de fichiers

Remplacer le fichier situé dans :

/web/js/fckeditor/editor/filemanager/connectors/php/config.php

Par celui-là :

http://trac.symfony-project.org/attachment/wiki/HowToUseFCKeditor/config.new

Il y a 2 lignes importantes :
1. UserFilesPath
   ^?View Code PHP

   $Config['UserFilesPath'] = DIRECTORY_SEPARATOR . 'userfiles' . DIRECTORY_SEPARATOR ;

   que l’on transforme comme ceci :

   ^?View Code PHP

   $Config['UserFilesPath'] = /uploads/fck/ ;

2. UserFilesAbsolutePath
   ^?View Code PHP

   $Config['UserFilesAbsolutePath'] = $_SERVER[DOCUMENT_ROOT] . $Config['UserFilesPath'] ;

   Qu’il vous faut éventuellement modifier si la racine de votre projet n’est pas la même que celle de votre serveur:

   ^?View Code PHP

   $Config['UserFilesAbsolutePath'] = $_SERVER[DOCUMENT_ROOT] . /myProject/ . $Config['UserFilesPath'] ;

• http://trac.symfony-project.org/wiki/HowToUseFCKeditor
• http://www.symfony-project.org/plugins/sfFormExtraPlugin
• http://www.fckeditor.net/download

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

sudo apt-get install esmtp

Ou alors, vous le trouverez dans Synaptic.

Aprés quoi un petit coup de

sudo nano /etc/esmtprc

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

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

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://forum.symfony-project.org/index.php/m/66906/?srch=tinymce+3+steps#msg_66906

En français et expliqué plus en détails, ça donne :

Intégrer Tiny MCE

• Télécharger et copier :
  http://tinymce.moxiecode.com/download.php
  dans :

  /web/js/tinyMCE

• Modifier ce fichier :

  /apps/backend/config/settings.yml

  ^?View Code YML

  all: .settings: sf_rich_text_js_dir: js/tinyMCE

Installer le plugin sfFormExtraPlugin:

symfony plugin:install sfFormExtraPlugin

Modifier le widget sfWidgetFormTextareaTinyMCE.class.php

Il faut modifier le plugin !

/plugins/sfFormExtraPlugin/lib/widget/sfWidgetFormTextareaTinyMCE.class.php

Fichier :

<?php
class sfWidgetFormTextareaTinyMCE extends sfWidgetFormTextarea
{
  protected function configure($options = array(), $attributes = array())
  {
    $this->addOption('theme', 'advanced');
    $this->addOption('width');
    $this->addOption('height');
    $this->addOption('config', '');
  }
  public function render($name, $value = null, $attributes = array(), $errors = array())
  {
    $attributes = array_merge($this->attributes, $attributes); 
    ...

Utilisation

Modifier ce fichier :

/lib/form/doctrine/ContenuForm.class.php

<?php
class ContenuForm extends BaseContenuForm
{
  public function configure()
  {
      $this->widgetSchema['texte'] =  new sfWidgetFormTextareaTinyMCE(
      array(
        'width'=>550,
        'height'=>350,
        'config'=>'theme_advanced_disable: "anchor,image,cleanup,help"',
        'theme'   =>  sfConfig::get('app_tinymce_theme','advanced'),
      ),
      array(
        'class'   =>  'tiny_mce'
      )
    );
    $js_path = sfConfig::get('sf_rich_text_js_dir') ? '/'.sfConfig::get('sf_rich_text_js_dir').'/tiny_mce.js' : '/sf/tinymce/js/tiny_mce.js';
    sfContext::getInstance()->getResponse()->addJavascript($js_path);
  }
}