Prendre un Café - Tag - bestpractices

Optimize your Doctrine Workflow with Specialized Queries

NiKo — Tue, 15 Sep 2009 19:14:00 +0200

I’m currently working on a big Symfony project, with a lot of Doctrine models and complex queries to write. I found a way to organize all of them in an object-oriented and cleaner way than using the traditionnal addNamedQuery() and createNamedQuery() methods workflow^[1].

The idea is to create dedicated query classes for a given model ; this way, you can provide useful methods to build the business-related parts of your query.

As usual, the theory is more understandable with a concrete example. Let’s consider this simple Doctrine model^[2] :

Disclaimer: The provided examples have been written in a hurry, so mistakes might have been not detected by my attentive proof-reading

 yaml
BlogAuthor:
  columns:
    id:
      type: integer(4)
      primary: true
      autoincrement: true  
    name:
      type: string(255)
  relations:
    Post:
      type: one
      class: BlogPost
      local: id
      foreign: author_id

BlogPost:
  columns:
    id:
      type: integer(4)
      primary: true
      autoincrement: true
    author_id:
      type: integer(4)
      notnull: true
    title:
      type: string(255)
    content:
      type: string(65535)
  relations:
    Author:
      type: one
      class: BlogAuthor
      local: author_id
      foreign: id
    Comments:
      type: many
      class: BlogComment
      local: id
      foreign: post_id

BlogComment:
  columns:
    id:
      type: integer(4)
      primary: true
      autoincrement: true
    post_id:
      type: integer(4)
      notnull: true
    author:
      type: string(255)
    content:
      type: string(5000)
  relations:
    Post:
      type: one
      class: BlogPost
      local: post_id
      foreign: id

Now let’s imagine a Query class dedicated to query the BlogPost table:

 php
<?php 
class BlogPostQuery extends Doctrine_Query
{
  static public function create($conn = null, $class = null)
  {
    return parent::create($conn, 'BlogPostQuery')
      ->from('BlogPost p');
  }
  
  public function addPosts($fields = 'p.*')
  {
    return $this->addSelect('p.*');
  }
  
  public function addComments($fields = 'c.*')
  {
    return $this
      ->addSelect($fields)
      ->leftJoin('p.Comments c')
      ->addGroupBy('c.id');
  }
  
  public function addAuthors($fields = 'a.*')
  {
    return $this
      ->addSelect($fields)
      ->leftJoin('p.Author a')
      ->addGroupBy('a.id');
  }
  
  public function addCommentsCount($alias = 'nb_comments')
  {
    return $this
      ->addSelect(sprintf('COUNT(c.id) as %s', $alias))
      ->addGroupBy('c.id');
  }
  
  public function filterByAuthorName($authorName)
  {
    return $this
      ->andWhere('a.name = ?', $authorName);
  }
}

So how can we use this query object? Here are some sample uses:

 php
// Retrieve all posts
$posts = BlogPostQuery::create()
  ->addPosts()
  ->fetchArray();

// Retrieve all posts with comments
$posts = BlogPostQuery::create()
  ->addPosts()
  ->addComments()
  ->fetchArray();

// Retrieve all posts with comments and their count per post
$posts = BlogPostQuery::create()
  ->addPosts()
  ->addComments()
  ->addCommentsCount('yataa')
  ->fetchArray();

// Retrieve all post with chuck as its author and related comments
$posts = BlogPostQuery::create()
  ->addAuthors()
  ->addPosts()
  ->addComments()
  ->filterByAuthorName('chuck')
  ->fetchArray();

// and so on...

Of course, this example of use is not really relevant as our model is really simple, but when you’re dealing with dozens of internationalized objects, it can help cleaning your model classes, controllers and improving the organization of your work.

Update and important precisions

Some people are having negative feedback regarding this technique, claiming it will encourage people using the custom query object directly in the controllers; that’s absolutely not the case as the queries are to be used only within the model layer, for example in the BlogPostTable class:

 php
<?php
class BlogPostTable extends Doctrine_Table
{
  static public function getPostsWithCommentsByAuthor($authorName)
  {
    return BlogPostQuery::create()
      ->addPosts()
      ->addComments()
      ->filterByAuthorName($authorName)
      ->fetchArray()
    ;
  }
}

And in a controller:

 php
class blogActions extends sfActions
{
  public function executeListByAuthor(sfWebRequest $request)
  {
    $this->posts = BlogPostTable::getPostsWithCommentsByAuthor($request->getParameter('author'));
  }
}

Notes

[1] … or raw queries written directly within controllers, but you may know that this is really bad

[2] I’m using Doctrine 1.2 beta (bundled with upcoming symfony 1.3) in the provided example.

Ce billet intitulé Optimize your Doctrine Workflow with Specialized Queries a été rédigé par Nicolas Perriault et publié sur le blog Prendre un Café sous licence Creative Commons BY-NC-SA.

30 Symfony Best Practices, the slides from my talk at SymfonyDay Cologne '09

NiKo — Fri, 04 Sep 2009 20:50:00 +0200

Hey there, it’s been a while, huh?

Today I gave a talk about Symfony best practices at the Symfony Day event in Cologne, Germany; you can get the slides on slideshare or directly browse them below:

The Symfony Day event has been purely awesomely incredibly well organized, many kudos and thanks to Interlutions and to all the attendees. You’re all great people. Thanks.

Ce billet intitulé 30 Symfony Best Practices, the slides from my talk at SymfonyDay Cologne '09 a été rédigé par Nicolas Perriault et publié sur le blog Prendre un Café sous licence Creative Commons BY-NC-SA.

Comment faire fuir à coup sûr vos utilisateurs ?

NiKo — Sun, 24 Aug 2008 15:45:00 +0200

C’est bien connu, il est déjà sufisament dur de faire (re)venir des utilisateurs sur vos services en ligne pour ne pas les faire partir à la moindre occasion. C’est pourtant ce que fait un site dédié à la guitare que j’ai tenté de consulter récemment. Connaissant les tendances dérivistes des services juridiques de certaines entités, je m’abstiendrai donc de faire un lien hypertexte direct vers ce dernier, et même de le citer textuellement^[1].

Je tombe sur ce site, qui propose apparemment moult ressources sur l’instrument et qui m’intéressent potentiellement, mais au moment de consulter l’article objet de ma convoitise, on me notifie du message suivant :

Jusque-là, rien de profondément choquant même si on peut imaginer que nombre d’internautes ne s’embêteront pas à créer un compte pour consulter la ressource et passeront à la concurrence^[2].

Allez, je suis dans un bon jour, je demande la création d’un compte. Je me retrouve face à un formulaire assez copieux, exigeant bien entendu des informations hautement nécessaires pour consulter un tutoriel de guitare comme ma localisation géographique, mon nom de famille, ma date de naissance, sans oublier bien entendu les inévitables propositions d’abonnement à des newsletter très étroitement liées à la pratique de la guitare :

Sentant le SPAM arriver à grand pas, je rentre mon email suffixé pour détecter a posteriori le service à l’origine d’éventuels courriels indésirables reçus. Ben non :

Vous noterez le plus fort, c’est que non seulement le service n’est pas à même de valider convenablement une adresse email (le signe + est acceptable), mais en plus on me soupçonne ouvertement de SPAM potentiel.

Normalement, à ce stade, je me casse sur Mars, comme on dit. Mais pour la beauté de l’exercice, je corrige mon adresse email, pérsévère en entrant un mot de passe et valide à nouveau le formulaire :

Oui, cela commence à faire beaucoup. Je ne réexpliquerai pas ici pourquoi limiter les caractères dans les mots de passe est idiot, cela a déjà été fait ici-même précédemment.

Toujours dans la perspective de poursuivre cette expérience amusante, j’arrive enfin à valider le formulaire sans retours d’erreur et m’identifie donc sur le service pour consulter la ressource en question. Patatra :

Non seulement la création d’un compte était obligatoire, mais maintenant il faut s’abonner (c’est à dire payer) pour consulter la ressource en question, chose qui n’avait été aucunement stipulée auparavant. Sachant bien entendu qu’à ce stade, je n’ai toujours aucune idée de la qualité des contenus proposés par le site.

Bref, je leur souhaite malgré tout un avenir comptable radieux, même si je ne peux m’empêcher de pouffer à l’idée du chiffre d’affaire généré par le se(r)vice.

Notes

[1] Mais les curieux trouveront bien entendu sans peine le site en question.

[2] Sur le Web, vous avez quasiment systématiquement un concurrent qui propose la même chose que vous gratuitement. C’est comme ça, et c’est aussi un peu pour ça que c’est chouette.

Ce billet intitulé Comment faire fuir à coup sûr vos utilisateurs ? a été rédigé par Nicolas Perriault et publié sur le blog Prendre un Café sous licence Creative Commons BY-NC-SA.

Mes conventions de codage...

NiKo — Wed, 23 Jul 2008 21:21:00 +0200

... sont celles des projets sur lesquels je me greffe. C'est en effet pour moi une forme de respect que d'appliquer les standards de codage partagés par une communauté (ou une équipe) de développeurs : ainsi, on maximise les chances de se comprendre et on minimise les coûteuses phases de communication entre geeks introvertis^[1]

En effet, rien de plus pénible que de reprendre le code de quelqu'un qui a pris des libertés avec des conventions établies à ce niveau, l'apothéose étant obtenue avec ce genre de code :

 php
<?php
  class Ma_superClasse {

    function dire_coucou ( $popol) {
  echo 'coucou ' . $popol   . ' !' ;
}
     function DireAuRevoir($Popol )
{ print "Au revoir $Popol !";
     }
  }

Je force bien évidemment ici le trait, mais tout le monde est déjà tombé sur ce genre de code illisible, qui multiplie par 10 votre temps d'intervention sur ce dernier et divise par 1000 votre passion pour la TMA.

Bien entendu, il peut arriver de produire du code sur un projet ne nécessitant l'utilisation d'aucune brique logicielle existante. Auquel cas vous pouvez librement appliquer vos propres standards de codage, l'important étant ici qu'ils soient cohérents et constamment appliqués. S'il peuvent être ceux d'un projet open source existant reconnu, cela augmentera la sympathie potentielle à votre égard de futurs intervenants sur votre code

Je noterai quand même en vrac quelques bonnes pratiques générales globalement reconnues et appréciées :

être explicite,
indenter son code,
documenter son code,
à choisir entre les deux, privilégier la lisibilité à la concision,
utiliser des noms de variables, de classes, de méthodes, de fonctions et d'arguments parlants,
utiliser des noms anglophones,
utiliser des motifs de conception connus.

Personnellement, j'ai mes petites préférences et tout comme Oncle Tom - qui m'a gentiment refilé cette chaîne^[2] - j'ai tendance à appliquer les standards de codage de symfony, que je trouve homogènes et cohérents. Mais ce sont là bien évidemment essentiellement des questions de goûts et de couleurs.

Notes

[1] Voire les trolls genre les tabulations ça pue, vive l'indentation à trois espaces...

[2] Salopard, ça va se payer !

Ce billet intitulé Mes conventions de codage... a été rédigé par Nicolas Perriault et publié sur le blog Prendre un Café sous licence Creative Commons BY-NC-SA.

Demander à restreindre les caractères utilisés dans les mots de passe est idiot

NiKo — Wed, 04 Jun 2008 12:25:00 +0200

Voulant créer un compte sur un nouveau service en ligne, j'ai eu la désagréable surprise d'obtenir ce message d'erreur au moment de la validation de mon mot de passe :

Password may only contain alphanumeric characters

Pour les anglophobes, on me demande de n'utiliser que des caractères alphanumériques pour mon mot de passe.

Ce n'est pas la première fois que je tombe sur la mise en place de pareil procédé. Quel est l'intérêt d'imposer cette limitation ? Je pense que plus un mot de passe utilise une plage de caractères diversifiée, plus il est sécurisé. Je peux éventuellement imaginer les problèmes que pourraient poser l'utilisation de caractères codés sur deux octets, ou encore l'angoisse d'une faille XSS potentielle chez les plus paranos, mais de là à interdire purement et simplement les tirets, underscores, espaces^[1], je trouve ça tout simplement idiot à tomber par terre.

Voila, c'est dit.

Edit : Quelques astuces sur la sécurisation des mots de passe.

Notes

[1] Alors que l'utilisation de deux espaces dans un mot de passe est très sécurisante

Ce billet intitulé Demander à restreindre les caractères utilisés dans les mots de passe est idiot a été rédigé par Nicolas Perriault et publié sur le blog Prendre un Café sous licence Creative Commons BY-NC-SA.

QOTD

NiKo — Sun, 04 May 2008 16:38:00 +0200

Une belle quote comme ça, je me la note dans un coin pour la ressortir la prochaine fois qu'on trolle sur les performances du framework X ou du langage Y :

Languages, libraries and frameworks don't scale. Architectures do.

En français approchant :

Les langages de programmation, les librairies et les frameworks ne tiennent pas la charge. Les architectures, si.

(via, apparement attribuable à Cal Henderson)

Ce billet intitulé QOTD a été rédigé par Nicolas Perriault et publié sur le blog Prendre un Café sous licence Creative Commons BY-NC-SA.

Symfony 1.1 beta, tour du propriétaire - L'internationalisation (i18n)

NiKo — Thu, 13 Mar 2008 11:52:00 +0100

Dans la liste des tâches nouvellement ajoutées en Symfony 1.1, on remarque une section dédiée à l'internationalisation :

i18n
  :extract            Extracts i18n strings from php files
  :find               Finds non "i18n ready" strings in an application

Et oui, la fonctionnalité dont tous les gens qui ont un jour travaillé sur des applications internationalisées en Symfony 1.0 ont rêvé a enfin été ajoutée : une tâche d'extraction des chaînes de caractères à traduire, avec génération et mise à jour des fichiers de traductions XLIFF

Si vous avez suivi les précédents tutoriels, vous devez disposer d'un projet sf11test, d'une application main et d'un module contact.

On va activer la gestion de l'internationalisation dans l'application en éditant le fichier de configuration apps/main/config/settings.yml comme suit :

[...]
all:
  [...]
  .settings:
    [...]
    i18n:                   on
    [...]
    standard_helpers:       [Partial, Cache, Form, I18N]
    [...]
    default_culture:        en

On part du principe que la langue par défaut sera l'anglais (en). Ajoutons quelques chaînes internationalisées dans le template apps/main/modules/contact/templates/indexSuccess.php au moyen du helper __() :

 php
<h2><?php echo __('Contact us') ?></h2>
<p><?php echo __('Drop us a message using the form below:') ?></p>
<form action="<?php echo url_for('contact/index') ?>" method="post">
  <table>
    <?php echo $form ?>
    <tr>
      <td></td>
      <td><input type="submit" value="<?php echo __('Send your message') ?>" /></td>
    </tr>
  </table>
</form>

Maintenant, lançons la commande d'extraction des chaînes à traduire pour notre future version française, en lui demandant poliment de générer automatiquement le fichier de traduction et de supprimer automatiquement les entrées orphelines :

 $ ./symfony i18n:extract --auto-save --auto-delete main fr
>> i18n      extracting i18n strings for the "main" application
>> i18n      found "3" new i18n strings
>> i18n      found "0" old i18n strings
>> i18n      saving new i18n strings
>> i18n      deleting old i18n strings

Le fichier apps/main/i18n/fr/messages.xml a été généré, examinons son contenu :

 xml
<?xml version="1.0"?>
<xliff version="1.0">
  <file source-language="EN" target-language="fr" datatype="plaintext"
    original="messages" date="2008-03-13T11:13:45Z"
    product-name="messages">
    <body>
      <trans-unit id="1">
        <source>Contact us</source>
        <target></target>
      </trans-unit>
      <trans-unit id="2">
        <source>Drop us a message using the form below:</source>
        <target></target>
      </trans-unit>
      <trans-unit id="3">
        <source>Send your message</source>
        <target></target>
      </trans-unit>
    </body>
  </file>
</xliff>

Il ne nous reste plus qu'à traduire nos chaînes en remplissant les balises <target></target> en conséquence pour traduire notre application en français. Si l'on venait à modifier notre template en supprimant, modifiant ou ajoutant de nouvelles chaînes, la tâche d'extraction se chargerait de mettre à jour nos fichiers de traduction en conséquence, tout en préservant le travail déjà effectué

Ce billet intitulé Symfony 1.1 beta, tour du propriétaire - L'internationalisation (i18n) a été rédigé par Nicolas Perriault et publié sur le blog Prendre un Café sous licence Creative Commons BY-NC-SA.

Symfony 1.1 beta, tour du propriétaire - Les formulaires

NiKo — Tue, 11 Mar 2008 10:50:00 +0100

Nous venons de voir la procédure d'installation de la beta1 de Symfony 1.1. Nous allons maintenant rentrer un peu plus dans les détails des nouvelles fonctionnalités en commençant par les formulaires.

La gestion des formulaires avec Symfony 1.1

La nouvelle gestion des formulaires est l'une des fonctionnalités majeures de cette nouvelle mouture du framework. Elle propose une séparation claire entre couche de contrôle, couche de définition et couche de présentation des données, soit un bon vieux pattern MVC des familles.

Pour illustrer ces fonctionnalités, nous allons retrousser nos manches et créer un formulaire de contact basique. On commence par initialiser un nouveau module contact dans l'application main de notre projet sf11test initié précédemment :

$ ./symfony generate:module main contact

Création d'une classe de formulaire

Nous allons créer une classe qui représentera notre formulaire de contact, que nous stockerons dans le fichier apps/main/lib/ContactForm.class.php. Cette classe étendra la classe de base sfForm et surchargera sa méthode de configuration afin de définir les champs de formulaire et les différents validateurs associés. Nous définirons quatre champs (appelés widgets en Symfony 1.1) :

Le nom de l'expéditeur, sous la forme d'un champs de saisie textuelle (<input type="text"/>)
Son adresse email, également sous la forme d'un champs de saisie textuelle
Le sujet de son message, sous la forme d'une boîte de sélection (<select/>)
Le texte de son message, sous la forme d'un champs texte multilignes (<textarea/>)

 php
<?php
class ContactForm extends sfForm
{
  public function configure()
  {
    // Widgets
    $topics = sfConfig::get('app_contact_topics', array());
    $widgetSchema = new sfWidgetFormSchema(array(
      'topic'   => new sfWidgetFormSelect(array('choices' => $topics)),
      'name'    => new sfWidgetFormInput(),
      'email'   => new sfWidgetFormInput(),
      'message' => new sfWidgetFormTextarea()
    ));
    $widgetSchema->setNameFormat('contact[%s]'); // HTML field names format
    $this->setWidgetSchema($widgetSchema);

    // Validators
    $this->setValidators(array(
      'topic'   => new sfValidatorRegex(array('pattern' => '/[a-z_]/')),
      'name'    => new sfValidatorString(array('min_length' => 2,
                                               'max_length' => 45)),
      'email'   => new sfValidatorAnd(array(new sfValidatorEmail(),
                                            new sfValidatorString(array('max_length' => 100)))),
      'message' => new sfValidatorString(array('min_length' => 10)),
    ));
  }
}

Au passage, nous ajoutons les sujets possibles de message dans le fichier de configuration apps/main/config/app.yml :

all:
  contact:
    topics:
      carrots_request: Do you have carrots?
      eggs_request:    Do you have eggs?

Marquons un arrêt pour examiner de plus près ce que nous venons d'écrire :

Nous avons ajouté 4 widgets à notre formulaires,
Nous avons défini et paramétré leurs validateurs associés,
- Au passage, vous noterez qu'il est possible de spécifier plusieurs validateurs pour un même champs, comme c'est ici le cas pour le champs email
Nous avons défini le format de nommage des champs de formulaire et choisi une syntaxe à base de tableau pour manipuler plus aisément les données dans notre action,
Nous avons déporté une partie de la configuration textuelle dans un fichier externe dédié, pour en faciliter la maintenance.

N'oublions pas de purger le cache de Symfony, car nous venons d'ajouter un nouvel objet php :

$ ./symfony cc

Interaction avec le formulaire depuis le contrôleur de l'application

Éditons maintenant le fichier apps/main/modules/contact/actions/actions.class.php pour y définir l'action par défaut du module^[1] :

 php
<?php
class contactActions extends sfActions
{
  public function executeIndex(sfWebRequest $request)
  {
    $form = new ContactForm();
    if ($request->isMethod('post')) // If HTTP method is POST
    {
      // Bind submitted values to the contact form instance
      $form->bind($request->getParameter('contact'));
      // Validate the form
      if ($form->isValid()) 
      {
        // Retrieve submitted values
        $values = $form->getValues(); 
        // ... Send your message here using submitted values
        // Then redirect user to the homepage with a one-shot message
        $this->getUser()->setFlash('notice', 'Message sent');
        $this->redirect('@homepage');
      }
    }
    // Publish form instance to the view
    $this->form = $form;
  }
}

Ici, dans l'ordre :

On instancie un objet de formulaire de contact
Si la méthode HTTP est POST :
- On assigne les paramètres de la requête correspondant aux champs du formulaire de contact à ce dernier
- On lance la validation, et si c'est valide :
  - On effectue les opérations nécessaires (traitement, redirection, etc.)

Vous noterez que tous les sinon sont gérés automatiquement par le framework de façon transparente (mais ces comportements par défaut sont toujours surchargeables) :

Par défaut le formulaire présenté sera vierge^[2],
Les champs seront automatiquement préremplis en cas d'erreur de validation,
Les erreurs seront contextualisées par rapport aux champs.

Rendu du formulaire dans la vue

Enfin, il nous reste à créer un template pour présenter le formulaire et éventuellement afficher un message à l'utilisateur, dans notre vue gérée au travers du fichier apps/main/modules/contact/templates/indexSuccess.php :

 php
<?php if ($sf_user->hasFlash('notice')): ?>
  <p class="notice"><?php echo $sf_user->getFlash('notice') ?></p>
<?php endif; ?>

<form action="<?php echo url_for('contact/index') ?>" method="post">
  <table>
    <?php echo $form ?>
    <tr>
      <td></td>
      <td><input type="submit" /></td>
    </tr>
  </table>
</form>

Si on charge la page /main_dev.php/contact, on a le résultat suivant :

Au passage si vous regardez la source, une protection anti CSRF est automatiquement gérée de façon transparente.

Bien entendu, le mode de rendu par défaut utilise un tableau pour la mise en forme, mais il existe un autre décorateur plus sémantique à base de liste. Pour l'utiliser, modifions notre classe ContactForm :

 php
<?php
class ContactForm extends sfForm
{
  public function configure()
  {
   // ...
    $this->widgetSchema->setFormFormatterName('list');
  }
}

Il conviendra bien entendu d'adapter le template pour enlever les balises tables. On peut aussi imaginer de créer notre propre décorateur HTML. Par exemple, créeons la classe sfWidgetFormSchemaFormatterDiv comme suit :

 php
<?php
class sfWidgetFormSchemaFormatterDiv extends sfWidgetFormSchemaFormatter
{
  protected
    $rowFormat       = "<div class=\"form-row\">\n  %error%%label%\n  %field%%help%\n%hidden_fields%</div>\n",
    $errorRowFormat  = "<div class=\"form-errors\">\n%errors%</div>\n",
    $helpFormat      = '<div class="form-help">%help%</div>',
    $decoratorFormat = "<div>\n  %content%</div>";
}

Encore une fois, modifions notre classe ContactForm pour l'utiliser (après avoir purgé le cache symfony, comme il se doit) :

 php
<?php
class ContactForm extends sfForm
{
  public function configure()
  {
   // ...
    $this->widgetSchema->setFormFormatterName('div');
  }
}

Rendu des widgets

Vous me direz, un simple <?php echo $form ?> n'est pas très satisfaisant du point de vue de l'intégration HTML, qui nécessite bien souvent de prendre la main finement sur le code html généré. Le framework de formulaires de Symfony 1.1 apporte une solution en permettant de générer le rendu de chacun des widgets de façon indépendante

Imaginons par exemple que nous souhaitions gérer spécifiquement la présentation du champ name de notre formulaire ; notre template devient alors :

 php
<?php if ($sf_user->hasFlash('notice')): ?>
  <p class="notice"><?php echo $sf_user->getFlash('notice') ?></p>
<?php endif; ?>

<form action="<?php echo url_for('contact/index') ?>" method="post">
  <table>
    <?php echo $form['topic']->renderRow() ?>
    <tr>
      <th><?php echo $form['name']->renderLabel() ?></th>
      <td>
        <?php echo $form['name']->renderError() ?>
        <?php echo $form['name']->render(array('class' => 'toto')) ?>
      </td>
    </tr>
    <?php echo $form['email']->renderRow() ?>
    <?php echo $form['message']->renderRow() ?>
    <tr>
      <td></td>
      <td><input type="submit" /></td>
    </tr>
  </table>
</form>

Vous noterez qu'on accède ici aux différents widgets du formulaire au moyen de clés de tableaux classiques ; c'est tout simplement car la classe sfForm implémente l'interface ArrayAccess de la SPL. C'est très pratique !

Le nerf de la guerre : la génération de formulaires à partir d'objets Propel

Ayant été à une lointaine époque un fervent adepte de PEAR::FormBuilder, brique permettant de générer des formulaires à partir d'instance d'objets de données ORM, j'étais curieux de voir comment cette fonctionnalité demandée par les développeurs depuis longtemps allait être implémentée dans Symfony 1.1 au travers de l'ORM Propel, bundlé par défaut^[3].

Après avoir configuré un accès à notre SGBD préféré^[4], nous allons définir une table contact_demand dans notre fichier config/schema.yml pour y stoker nos demandes de contacts :

 php
propel:
  contact_demand:
    id:
    name:    { type: varchar, size: 45, required: true }
    email:   { type: varchar, size: 100, required: true }
    topic:   { type: varchar, size: 255, required: true }
    message: { type: longvarchar, required: true }
    created_at:

On lance rapidement la tâche de création de la table et des objets ORM associés :

$ ./symfony propel:build-all
$ ./symfony cc

Maintenant, allons faire un tour dans le répertoire lib/model pour voir ce qui a été généré. Surprise, des objets de formulaires ont été automatiquement créés pour nous !

Jetons un oeil plus particulièrement au fichier lib/form/base/BaseContactDemandForm.class.php :

 php
<?php
class BaseContactDemandForm extends BaseFormPropel
{
  public function setup()
  {
    $this->setWidgets(array(
      'id'         => new sfWidgetFormInputHidden(),
      'name'       => new sfWidgetFormInput(),
      'email'      => new sfWidgetFormInput(),
      'topic'      => new sfWidgetFormInput(),
      'message'    => new sfWidgetFormTextarea(),
      'created_at' => new sfWidgetFormDateTime(),
    ));

    $this->setValidators(array(
      'id'         => new sfValidatorPropelChoice(array('model' => 'ContactDemand', 'column' => 'Id', 'required' => false)),
      'name'       => new sfValidatorString(),
      'email'      => new sfValidatorString(),
      'topic'      => new sfValidatorString(),
      'message'    => new sfValidatorString(),
      'created_at' => new sfValidatorDateTime(array('required' => false)),
    ));

    $this->widgetSchema->setNameFormat('contact_demand[%s]');

    $this->errorSchema = new sfValidatorErrorSchema($this->validatorSchema);

    parent::setup();

  }

  public function getModelName()
  {
    return 'ContactDemand';
  }
}

Cela ne vous rappelle rien ? C'est presque quasiment ce que nous avions écrit manuellement précédemment dans notre classe ContactForm. On notera également la présence dans le fichier lib/form/ContactDemandForm.class.php de la classe ContactDemandForm, cette dernière héritant de BaseContactDemandForm.class.php, ce qui nous permettra de surcharger tout ou partie de ses méthodes pour adapter le formulaire généré à nos besoins.

En l'occurrence, il nous faut adapter un peu la méthode configure() pour retrouver notre sélecteur de sujets et réappliquer nos validateurs. Voici le code de la classe ContactDemandForm modifiée en conséquence :

 php
<?php
class ContactDemandForm extends BaseContactDemandForm
{
  public function configure()
  {
    // Widgets
    $topics = sfConfig::get('app_contact_topics', array());
    $this->setWidgets(array(
      'id'      => new sfWidgetFormInputHidden(),
      'topic'   => new sfWidgetFormSelect(array('choices' => $topics)),
      'name'    => new sfWidgetFormInput(),
      'email'   => new sfWidgetFormInput(),
      'message' => new sfWidgetFormTextarea()
    ));

    // Validators
    $this->setValidators(array(
      'id'         => new sfValidatorPropelChoice(array('model'    => 'ContactDemand',
                                                        'column'   => 'Id',
                                                        'required' => false)),
      'topic'      => new sfValidatorRegex(array('pattern' => '/[a-z_]/')),
      'name'       => new sfValidatorString(array('min_length' => 2,
                                                  'max_length' => 45)),
      'email'      => new sfValidatorAnd(array(new sfValidatorEmail(),
                                               new sfValidatorString(array('max_length' => 100)))),
      'message'    => new sfValidatorString(array('min_length' => 10)),
      'created_at' => new sfValidatorDateTime(array('required' => false)),
    ));

    $this->widgetSchema->setNameFormat('contact_demand[%s]');
    $this->errorSchema = new sfValidatorErrorSchema($this->validatorSchema);
  }
}

On va maintenant modifier notre action pour prendre en compte notre nouvelle classe de formulaire liée à notre objet Propel :

 php
<?php
class contactActions extends sfActions
{
  public function executeIndex(sfWebRequest $request)
  {
    $form = new ContactDemandForm();
    if ($request->isMethod('post')) // If HTTP method is POST
    {
      // Bind submitted values to the contact form instance
      $form->bind($request->getParameter('contact_demand'));
      // Validate the form
      if ($form->isValid())
      {
        // Save submitted values in form's ContactDemand object
        $form->save();
        // Then redirect user to the homepage with a one-shot message
        $this->getUser()->setFlash('notice', 'Message sent');
        $this->redirect('@homepage');
      }
    }
    // Publish form instance to the view
    $this->form = $form;
  }
}

Ainsi, un simple $form->save() nous permet de persister en base les données soumises par l'utilisateur au travers du formulaire autogénéré. Un sacré gain de productivité en phase de prototypage, assurement !

En conclusion

Voilà, ce n'est bien évidemment là qu'une infime partie de ce que peut faire le nouveau système de gestion de formulaires de Symfony 1.1, mais c'est un peu à reculons que l'on retourne à l'ancien système

Notes

[1] Nous ne créons pas de route pour le moment, même si ce serait là une bonne pratique, afin de ne pas surcharger inutilement le contenu de ce tutorial, déjà bien assez dense comme ça

[2] On aurait bien entendu pu proposer des valeurs par défaut.

[3] Le mécanisme de génération de code devrait permettre de proposer facilement la même fonctionnalité pour Doctrine prochainement.

[4] Je vous laisse le soin de vous référer au tutoriel existant sur ce même blog

Ce billet intitulé Symfony 1.1 beta, tour du propriétaire - Les formulaires a été rédigé par Nicolas Perriault et publié sur le blog Prendre un Café sous licence Creative Commons BY-NC-SA.