Bref comme vous vous en doutez ce blog va s'orienter de plus en plus vers Symfony puisque je fais en sorte qu'il prenne place dans ma vie professionnelle.

Côté ligne éditoriale, je veux renforcer le côté articles, ils sont et resteront rares, j'essaie de les détailler suffisamment et ceci me prends beaucoup de temps. D'où le fait que j'ai ajouté un système de brèves qui me permet de sortir du cadre des articles, avec cette dernière par exemple.

Pour le flux RSS principal, pas de souci, puisque c'est feedburner qui s'en occupe, pour les autres et notamment celui des commentaires, je vous conseille d'aller jeter un oeil en bas de la page à propos.

Côté design, celui-ci est beaucoup plus simple que le précédent, plus épurée, il repose essentiellement sur une mise en avant des contenus, ce qui pêchait auparavant (surtout en terme de largeur pour l'affichage des articles). Dans les originalités on trouve surtout un code couleur par catégorie (bleu pour PHP, rouge pour CSS, vert pour le Javascript et gris foncé pour Webdesign) et on retrouve les titres positionnés à gauche du contenu des articles.

Et côté bonne nouvelle, le précédent design sera prochainement disponible en téléchargement sous la forme d'un template libre ou wordpress.

Avec la récente acquisition d'un Canon 50D et d'un 17-40 j'ai pas mal de photos à trier, retoucher et mettre en ligne sur mon Flickr, et je reviens dès que possible avec des articles !

(il se peut que des bugs aient échappés à mon attention, n'hésitez pas à me les signaler en commentaire)

L'objectif de cet article est de vous présenter sfForm en tant que framework sans Symfony, avec ses compagnons de route, à savoir ses widgets et ses validateurs. Evidemment mon but n'est pas de vous conseiller d'utiliser cette technique car vous ne bénéficierez pas de toutes les fonctionnalités liés à Symfony, notamment le lien entre le formulaire et l'ORM. De plus dans cet exemple il y a des appels aux variables supersglobales ce qui n'est pas recommandé, etc. Mais ceci peut être utile si vous travaillez sur un code existant sur lequel vous ne pouvez envisager une refonte totale et sur lequel vous avez une problématique autour des formulaires, sfForm peut y répondre en tant que tel.

Dans un premier temps il nous faut inclure les librairies. J'ai choisi, pour cet exemple relativement simple d'utiliser le système d'autoloading fourni dans Symfony. Cette intégration dépend de votre projet, si vous utilisez déjà l'autoloading, il vous faudra l'adapter à l'inclusion des librairies de sfForm...

require_once dirname(__FILE__) . '/lib/symfony/autoload/sfCoreAutoload.class.php';
sfCoreAutoload::register();

La classe de définition du formulaire sfForm est identique à celle que l'on pourrait trouver dans un projet Symfony, je laisse donc de côté cette étape, vous pouvez vous référer à la documentation. Vous trouverez cependant la classe dans l'archive attachée à cet article et dans une fenêtre modale ci-dessous :

<?php
class ContactForm extends sfForm
{
  protected static $subjects = array('Subject A', 'Subject B', 'Subject C');

  public function configure()
  {
    $this->setWidgets(array(
      'name'    => new sfWidgetFormInput(),
      'email'   => new sfWidgetFormInput(),
      'subject' => new sfWidgetFormSelect(array('choices' => self::$subjects)),
      'message' => new sfWidgetFormTextarea(),
    ));

    $this->setValidators(array(
      'name'    => new sfValidatorString(array('required' => false)),
      'email'   => new sfValidatorEmail(array(), array('invalid' => 'Email address is invalid.')),
      'subject' => new sfValidatorChoice(array('choices' => array_keys(self::$subjects))),
      'message' => new sfValidatorString(array('min_length' => 4), array(
        'required'   => 'The message field is required',
        'min_length' => 'The message "%value%" is too short. It must be of %min_length% characters at least.',
      )),
    ));

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

    $this->widgetSchema->setFormFormatterName('list');
  }
}

Quant à la partie de notre code qui va gérer le traitement de la requête entrante, le formulaire et la réponse (notre contrôleur en résumé), nous allons étudier le code habituel d'une action Symfony pour en déceler les éléments indisponibles dans notre application from scratch.
Code habituel de l'action du formulaire avec Symfony :

public function executeIndex(sfWebRequest $request)
{
  $this->form = new ContactForm();

  if ($request->isMethod('post'))
  {
    $this->form->bind($request->getParameter('poll', array()));

    if ($this->form->isValid())
    {
      // traitement base de données ou email

      // redirection vers une page de confirmation
      $this->redirect('contact/confirmation');
    }
  }
}

Ci-dessous une liste de contraintes pour adapter cela sans Symfony :

• $this->form nous permet de passer un objet à la vue, nous n'en avons plus besoin une simple variable $form suffira (attention néanmoins à la visibilité de cette variable et qu'elle ne soit pas écrasée ailleurs dans votre code...) ;
• nous n'avons plus l'objet $request, lui qui nous permet de récupérer des informations venant de la requête utilisateur, tels que des paramètres GET ou POST, nous allons le remplacer par un accès direct à la variable superglobale $_POST ;
• enfin $this->redirect() pourra être remplacé par un header("Location").

Ce qui nous amène à ce code :

$form = new ContactForm();

if (!empty($_POST))
{
  $form->bind((is_array($_POST['contact'])) ? $_POST['contact'] : array());
  if ($form->isValid())
  {
    // traitement base de données ou email
    $values = $form->getValues();

    // redirection vers une page de confirmation
    header("Location: confirmation.php");
    exit;
  }
}

Forcément c'est moins propre qu'avec Symfony... ;-)
Voici la structure de notre micro-projet :

• lib/
  • symfony/
    • autoload/
    • form/
    • validator
    • widget
  • ContactForm.class.php
• index.php

C'est terminé, notre code est fonctionnel, nous avons apprivoisé sfForm pour l'utiliser dans notre projet avec nos autres librairies. Vous trouverez ci-dessous le code complet du fichier index.php :

<?php
/**
 * Symfony autoloading
 */
require_once dirname(__FILE__) . '/lib/symfony/autoload/sfCoreAutoload.class.php';
sfCoreAutoload::register();

/**
 * Contact form example
 */
require_once dirname(__FILE__) . '/lib/ContactForm.class.php';
$form = new ContactForm();

if (!empty($_POST))
{
  $form->bind((is_array($_POST['contact'])) ? $_POST['contact'] : array());
  if ($form->isValid())
  {
    // traitement base de données ou email
    $values = $form->getValues();

    // redirection vers une page de confirmation
    header("Location: confirmation.php");
    exit;
  }
}

?>
< !DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <title>Contact form example with sfForm</title>
  </head>
  <body>
<form action="index.php" method="post">
<ul>
        <?php echo $form ?>
<li>
<input type="submit" value="Submit" /></li>
</ul></form>

  </body>
</html>

Télécharger les sources

Pour aller plus loin et notamment pour comprendre la modularité des composants de Symfony, je vous conseille la lecture des slides de la conférence de Fabien Potencier, lors du forum PHP 2008, intitulée "Découpler votre code pour assurer la réutilisabilité et la maintenabilité".

J'avais envie de vous parler de Symfony et Zend Framework, il s'agit de 2 framework PHP apportant un développement pérenne, rapide et agile. Loin de moi l'idée de vous donner la définition d'un framework, ni même son utilité, bien des ressources existent sur Internet, à commencer par cet article. Je vais plutôt m'attacher à vous présenter leur gestion des formulaires. L'exercice sera donc de créer un formulaire type avec ces 2 frameworks, ce qui nous permettra d'une part de comparer le code, et d'autre part de mesurer le temps qui aura été nécessaire.

Le but étant d'obtenir un formulaire généré donc facilement maintenable, un formulaire évidemment validé (à la fois pour contrôler les données saisies et pour nous éviter d'éventuelles failles), et enfin un formulaire internationalisé.

Petite pub au passage, pour mesurer mon temps j'ai utilisé la très sympathique application Kronos édité par une petite boite Montpellièraine.

Sommaire

• Descriptif du formulaire
• Comparaison de codes
• Avantages / inconvénients sfForm
• Avantages / inconvénients Zend_Form
• Bilan
• Conclusion
• Téléchargement
• Ressources

Descriptif du formulaire

Dans le cadre de cet exercice, j'ai défini d'une part les champs du formulaire, et d'autre part certaines contraintes techniques afin de compliquer légèrement la tâche.
Attaquons le vif du sujet, voici les champs de notre formulaire :

Les contraintes techniques (essentiellement sur la forme) sont les suivantes :

• le formulaire ne sera pas généré en tableau, mais en liste à puces ;
• les "labels" des champs obligatoires seront suivi d'une étoile rouge ;
• les champs "prénom" et "nom" doivent être côte à côte (flottants donc) ;
• le champ "date de naissance" doit apparaître sous la forme de sélecteurs (on pourra éventuellement y ajouter un datepicker en javascript) ;
• la case à cocher de l'inscription à la newsletter doit apparaître avant le "label" ;
• la "vue" devra être la plus courte possible pour être flexible autant sur le fond que sur la forme.

Et enfin, voici un screenshot du rendu souhaité :

Comparaison de codes

Dans Symfony un formulaire est généré via la classe "sfForm", chaque éléments du formulaire se nommera un "widget", ils proviennent naturellement de la classe "sfWidget".

Dans Zend Framework un formulaire est généré via la classe "Zend_Form", chaque éléments du formulaire se nommera "element", ils proviennent de la classe "Zend_Form_Element".

Passons à la description du code et surtout à la comparaison des 2 écritures :

Formulaire de contact avec Zend_Form

/**
 * Formulaire de contact avec Zend_Form du Zend Framework
 */
public function init()
{
    $this->setName('contact-form')
         ->setAttrib('id', 'contact-form');

    $this->addElement('select', 'subject', array(
        'label' => 'subject',
        'required' => true,
        'multiOptions' => array('' => '', 1 => 'commercial', 2 => 'technical')
    ));

    $this->addElement('text', 'firstname', array(
        'label' => 'firstname',
        'required' => true,
        'validators' => array('alnum')
    ));

    $this->addElement('text', 'lastname', array(
        'label' => 'lastname',
        'required' => true,
        'validators' => array('alnum')
    ));

    $this->addElement('text', 'email', array(
        'label' => 'email',
        'required' => true,
        'validators' => array('EmailAddress')
    ));

    $this->addElement('textarea', 'message', array(
        'label' => 'message',
        'rows' => 5,
        'cols' => 50,
        'required' => true
    ));

    $this->addElement('text', 'birthday', array(
        'label' => 'birthday',
        'description' => 'birthdayDescription'
    ));
    // date validator
    $this->getElement('birthday')->addValidator(new Zend_Validate_Date(null, Zend_Registry::get('Zend_Translate')->getLocale()));

    $this->addElement('checkbox', 'newsletter', array(
        'label' => 'newsletter'
    ));

    $this->addElement('submit', 'submit', array(
        'label' => 'submit'
    ));

    /**
     * Decorators
     */
    $this->clearDecorators();

    $this->addDecorator('FormElements')
         ->addDecorator('HtmlTag', array('tag' => '
<ul>', 'class' => 'form'))
         ->addDecorator('Form');

    $this->setElementDecorators($this->_defaultDecorator);

    $this->getElement('firstname')->setDecorators($this->_floatLeftDecorator);
    $this->getElement('lastname')->setDecorators($this->_floatRightDecorator);
    $this->getElement('newsletter')->setDecorators($this->_inlineDecorator);
    $this->getElement('submit')->setDecorators($this->_submitDecorator);

    return $this;
}
</ul>

Formulaire de contact avec sfForm

/**
 * Formulaire de contact avec sfForm de Symfony
 */
public function configure()
{
  $subjects = array('' => '', 1 => __('commercial'), 2 => __('technical'));
  $years = range(date('Y') - 10, date('Y') - 100);

  $this->setWidgets(array(
    'subject'      => new sfWidgetFormSelect(array('choices' => $subjects)),
    'firstname'    => new sfWidgetFormInput(array(), array('maxlength' => 30)),
    'lastname'     => new sfWidgetFormInput(),
    'email'        => new sfWidgetFormInput(),
    'message'      => new sfWidgetFormTextarea(array(), array('cols' => 50, 'rows' => 5)),
    'birthday'     => new sfWidgetFormDate(array('format' => '%day%/%month%/%year%', 'years'  => $years)),
    'newsletter'   => new sfWidgetFormInputCheckbox(array()),
  ));

  $this->widgetSchema->setLabels(array(
    'subject'      => 'subject',
    'firstname'    => 'firstname',
    'lastname'     => 'lastname',
    'email'        => 'email',
    'message'      => 'message',
    'birthday'     => 'birthday',
    'newsletter'   => 'newsletter',
  ));

  $this->setValidators(array(
    'subject'      => new sfValidatorChoice(array('choices' => array_keys($subjects))),
    'firstname'    => new sfValidatorString(array('required' => true)),
    'lastname'     => new sfValidatorString(array('required' => true)),
    'email'        => new sfValidatorEmail(array('required' => true), array('invalid' => 'Veuillez indiquer un email valide')),
    'message'      => new sfValidatorString(array('required' => true)),
    'birthday'     => new sfValidatorDate(array('required' => false, 'date_format' => '/^[0-9]{2}\-[0-9]{2}\-[0-9]{4}$/', 'with_time' => false), array()),
    'newsletter'   => new sfValidatorString(array('required' => false)),
  ));

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

  $this->widgetSchema->setFormFormatterName('list');
}

Contrôleur du Zend Framework

/**
 * Action du contrôleur de traitement du formulaire (Zend Framework)
 */
public function indexAction()
{
    // création d'une instance du formulaire
    $form = new Contact(array(
        'action' => $this->view->url(array('action' => 'index')),
        'method' => 'post'
    ));

    // vérification de la validité des données
    if ($this->_request->isPost() && $form->isValid($this->_request->getPost())) {
        // récupération des données
        $values = $form->getValues();

        // traitement des données...

        // redirection vers la page de remerciements
        $this->_redirect('index/success');
        exit;
    }

    $this->view->form = $form;
}

Contrôleur de Symfony

/**
 * Action du contrôleur de traitement du formulaire (Symfony)
 */
public function executeIndex($request)
{
  // création d'une instance du formulaire
  $this->form = new ContactForm();

  if ($request->isMethod('post'))
  {
    $this->form->bind($request->getParameter('contact'));
    // vérification de la validité des données
    if ($this->form->isValid())
    {
      // récupération des données
      $values = $this->form->getValues();

      // traitement des données...

      // redirection vers la page de remerciements
      $this->redirect('form/success');
    }
  }
}

Vue du Zend Framework

<?php echo $this->form ?>

Vue de Symfony

<form name="form" action="<?php echo url_for('form/index') ?>" method="post">
<ul class="form">
    <?php echo $form['subject']->renderRow() ?>
<li class="left">
      <?php echo $form['lastname']->renderError() ?>
      <?php echo $form['firstname']->renderLabel() ?>
      <?php echo $form['firstname']->render() ?>
    </li>
<li class="right">
      <?php echo $form['lastname']->renderError() ?>
      <?php echo $form['lastname']->renderLabel() ?>
      <?php echo $form['lastname']->render() ?>
    </li>

    <?php echo $form['email']->renderRow() ?>
    <?php echo $form['message']->renderRow() ?>
    <?php echo $form['birthday']->renderRow() ?>
<li>
      <?php echo $form['newsletter']->render() ?>
      <?php echo $form['newsletter']->renderLabel(null, array('class' => 'inline')) ?>
    </li>
<li>
<input type="submit" name="submit" id="submit" value="<?php echo __('submit') ?/>" /></li>
</ul>
</form>

Avantages /
inconvénients
sfForm

Avantages /
inconvénients
Zend_Form

Bilan

Question temps, j'ai mis un peu plus de 4h pour réaliser ce formulaire avec Symfony et pas loin de 5h avec Zend Framework. En sachant que je n'ai pas compté le temps de mise en place du projet, ce temps étant annexe à l'exercice et d'autant plus car la logique de création d'un projet est assez différente entre Symfony et Zend Framework. Symfony est ce que l'on appelle un "full stack framework" (comprendre tu dézippes, tu as toute l'arborescence de ton projet), tandis que Zend Framework laisse libre la structuration de son projet, il donne seulement quelques recommandations.

Ce temps a été découpé en relecture de la documentation, création du formulaire et mise en place d'un layout.
On peut trouver le temps de réalisation un peu long en comparaison d'un formulaire généré "from scratch", pour autant avec ces 2 librairies je dispose de nombreux composants, de nombreux validateurs, d'une bonne sécurité et surtout d'une flexibilité.

Enfin dans les 2 cas, je n'ai pas pleinement rempli les contraintes de départ de mon exercice :

Conclusion

On peut constater que la manière de créer un formulaire avec ces 2 composants est relativement semblable, tout du moins elle l'est sur un exemple aussi simple. Une fois que la logique est comprise, on peut assez facilement passer de l'un à l'autre.

Au delà de l'aspect coeur de réalisation, j'entends par là design pattern mis en oeuvre ou encore logique interne, j'ai surtout le sentiment que ces 2 composants diffèrent sur la forme :

sfForm et Zend_Form se différencient principalement au niveau de la génération de la partie vue :

• sfForm par le biais des "formatter" propose seulement un gabarit général de présentation du formulaire. Les cas particuliers, les affichages spécifiques seront à votre charge dans la vue, nous allons voir ci-dessous comment ce choix est justifié.
• Zend_Form quant à lui donne la possibilité de créer de multiples "decorators" qui décrivent chacun un comportement du formulaire. En résumé, vous pouvez définir un "decorator" par défaut (qui agira au même titre qu'un "formatter") ainsi que des "decorators" spécifiques à chaque rendu graphique.

Génération complète du formulaire

On peut se demander l'intérêt d'une génération complète du formulaire, voici quelques exemples :

• pour chaque champ ajouté dans le formulaire, il faudra penser à l'ajouter dans la vue (et gare aux erreurs sur le nom des champs) ;
• si je fais une modification générale sur le gabarit, il me sera nécessaire de la répercuter au niveau spécifique du formulaire, par exemple si je ne souhaite plus gérer mon formulaire via des listes à puces mais plutôt avec des div ou des listes de définitions, il me sera nécessaire de modifier le "formatter" du formulaire ainsi que la vue (si j'oublie, j'aurais de belles erreurs xhtml...) ;
• plus fréquent, j'ajoute un champ upload, il me faudra penser à ajouter l'entête enctype dans le formulaire... ;

Tout ceci manque un peu de modularité en somme, utiliser un outil de génération des formulaires devrait nous permettre de nous décharger de ce genre de "soucis", le framework doit les prendre en charge pour nous.

Différence entre formatter et decorators

Les "formatters" de Symfony gèrent le comportement de l'intégralité du formulaire, il n'est pas possible (à ma connaissance) de personnaliser le "formatter" d'un "widget" en particulier. Sous Zend Framework les "decorators" interviennent au niveau général du formulaire et au niveau de chaque "element", je trouve ce système plus modulaire, je m'explique : l'avantage principal que je vois à cette technique, c'est que je peux préparer les comportements spécifiques de mes formulaires (élément à gauche, élément à droite, élément sans label, élément en ligne pour une case à cocher par exemple, etc.) et je les utilise ensuite librement dans mes formulaires, sans avoir à modifier ma vue.

Après quelques recherches et notamment à la lecture de l'article "Les formulaires Symfony 1.1 et le pattern MVC" du blog de Fabien Potencier, j'apprends que ce choix a été fait dans un respect du pattern MVC, et on peut y lire :

"Mais il faut garder à l'esprit que echo $form est juste un raccourci sympathique. Il est très pratique pour créer un prototype rapide mais la plupart du temps, vous voudrez avoir un contrôle plus important sur le rendu du formulaire et sur la disposition des différents widgets dans la page. Et c'est là que le nouveau système est vraiment puissant. Le travail des intégrateurs est grandement simplifié."

J'en suis venu à me demander si le système des "decorators" du Zend Framework respectait le patten MVC, mais je pense que oui, puisqu'ils décrivent des comportements de rendu graphique (en l'occurence HTML) au même titre que le "formatter" de Symfony... Qu'en pensez vous ?

On continue avec une deuxième justification de ce choix dans la documentation officielle de sfForm, nous avons là un scénario de travail en équipe, où développeurs et intégrateurs travaillent en parallèle sur le même projet grâce à ce système découpé.

Certes l'analyse est bonne mais sur ce point je trouve Zend_Form intéressant étant donné que je suis à la fois développeur et intégrateur sur mes projets, c'est donc naturellement moi qui définit les différents "décorators", donc les différents comportements possibles de mes formulaires. A l'inverse une équipe qui travaillera sur le modèle défini ci-dessus sera peut être gênée par ce modèle car c'est aux développeurs d'agir sur les "decorators" et non aux intégrateurs...

Avis perso

Téléchargement

Télécharger l'exercice avec Symfony

Télécharger l'exercice avec Zend Framework

(par simplicité je n'ai pas configuré ces 2 projets pour fonctionner avec un virtual host, ils sont tous 2 gérés avec des adresses relatives)

Ressources

Voilà pour cet article, beaucoup risquent de trouver que je survole de très haut les fonctionnalités de ces 2 composants, le but n'était pas de donner un tutoriel avancé, mais plutôt de se donner un exercice (avec ses facilités et ses contraintes) et de tenter de s'approcher au maximum du résultat escompté avec ces 2 composants. Le but final est plutôt de donner envie aux développeurs qui ne connaissent ni Symfony, ni Zend Framework de tenter l'expérience, car l'un comme l'autre, ces frameworks donnent lieu à un développement beaucoup plus agréable !