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 !

Remarque : L'exemple suivant est traité avec PHP 5 et SQLite (def. wikipédia).

Nature de l'exemple : Prenons un exemple simple, vous traitez des projets et des employés. Vous gérez un système permettant d'assigner des employés sur un ou plusieurs projets (jusque la rien de compliqué). La contrainte est la suivante : il ne peut y avoir plus de quatre employés assignés à un projet.

Accéder à une base de donnée SQLite via PHP

Vous avez deux possibilités pour accéder à une base de donnée SQLite, la méthode procédurale (qui est à éviter si vous coder en PHP 5) et la méthode objet, méthode que je vais présenter.

Remarque : Votre base de donnée doit forcément se trouver avec un droit d'accès 777.

Méthode procédurale :

$db = sqlite_open("db/gestionProjet.db");

Méthode objet :

$sqlite = new SQLiteDatabase("db/gestionProjet.db");

Information : Il est possible de faire passer deux paramètres de plus, le mode d'accès qui pour le moment est ignoré des bibliothèques de SQLite (valeur par défaut 0666), et un message d'erreur affiché dans le cas où la base n'arrive pas à être ouverte.

Résolution de la contrainte (ancienne méthode)

Avant, nous aurions simplement exécuté une requête allant compter le nombre de participants actuel au projet, si le chiffre était inférieur à quatre, alors nous aurions laissé faire la requête d'insertion d'un participant, dans le cas contraire nous aurions directement affiché un message d'erreur.

Information : La table qui contient les employés participants à des projets s'appelle participer et le champ de cette table qui fait lien avec un projet s'appelle partProjet.

Voici le code :

$nb = $sqlite->singleQuery("select count(*) from participer where partProjet=".$_POST['projet']."");
if ($nb < 4) {
     // Requête d'insertion
} else {
     // Message d'erreur (cause : il faut moins de quatre participants pour un projet)
}

Résolution de la contrainte (utilisation d'un déclencheur)

Gràce à SQLite, il est possible de mettre en place un déclencheur (trigger), il est spécifié pour ce dernier dans quelle condition et sur quelle table il sera appelé automatiquement. La condition spécifie si l'action se fera lors d'une insertion (insert), d'une modification (update) ou d'une suppression (delete) ensuite il faut préciser sur quelle table se fera cette vérification. Par la suite automatiquement, lors d'une insertion sur la table spécifié, par exemple, un traitement viendra s'exécuter.

On peut de plus accéder aux données de la requête qui a amené au traitement du déclencheur.

• Lors d'une insertion, on utilisera le mot clé new avant le champ que l'on cherche à récupérer.
• Lors d'une modification, on utilisera old pour accéder à la valeur qui va être remplacée, et new pour accéder à la valeur de remplacement.
• Lors d'une suppression, on utilisera old pour accéder à la valeur qui va être supprimée.

Information : Je ne connais pas trop le langage SQL de SQLite qui permet de faire les déclencheurs, j'ai appris qu'il était fortement semblable au PL SQL de Oracle. Pour ma part j'ai repris un exemple pour m'inspirer de mes déclencheurs.

Il faut ensuite mettre en place un déclencheur de ce style :

create trigger verifNbreParticipants before insert on participer for each row
begin
select case
when (select count(*) from participer where partProjet=new.partProjet)>=4 then raise (fail, 'Erreur nombre participants')
end;
end;

Information : Exécutez simplement une requête à la base de donnée contenant ce déclencheur pour l'activer.

A partir de la, refaites votre insertion, jusqu'à ce qu'il y ai quatre participants pour un projet. Vous verrez apparaître une belle erreur en haut de votre navigateur :

Warning: SQLiteDatabase::query() [function.query]: Erreur nombre participants

On reconnaît tout de même le message d'erreur que l'on a prévu dans le déclencheur :

raise (fail, 'Erreur nombre participants')

Redéfinition des messages d'erreurs en PHP

On ne va pas laisser cette vieille erreur en haut du navigateur quand même ?! La méthode set_error_handler() nous permet de redéfinir les messages d'erreurs de PHP. Il suffit de lui passer en paramètre le nom de la fonction qui prendra en charge les messages d'erreurs.

Information : Vous trouverez plus d'information sur cette fonction et sur les paramètres spécifiés ci-dessous, ici.

Créons une fonction de gestion des erreurs :

function gestionErreur($errno, $errstr, $errfile, $errline) {
     if (ereg("Erreur nombre participants", $errstr)) {
          $erreur = "Il ne peut pas y avoir plus de quatre développeurs sur un même projet.";
     }
}

A partir de la vous pouvez faire afficher cette erreur à l'endroit où vous voulez et avec votre propre mise en page, comme ceci :

Conclusion

Ce style de programmation permet de bien séparer les tàches et les traitements.
Verdict : je langi vraiment que ce soit implémenté sous MySQL.

Mais tout d'abord, qu'est ce qu'un moteur de template ?

Le moteur de template est un moyen élégant de séparer la forme, de la programmation (le fond). D'un côté vous aurez votre programmation PHP / ASP / etc. (dans notre cas PHP) et de l'autre vos différents fichiers templates correspondants à un modèle de mise en page.
La conception du projet d'une part, et la conception des pages d'autre part seront grandement facilité.
Immaginez une page PHP sans echo ""; ^^
Dans la même optique, fini les " au milieu du HTML :)
Quelques exemples parmis bien d'autres qui vous facilitent la vie lors de l'utilisation d'un moteur de template.

Rôle du moteur de template

Le moteur de template va simplement afficher la page que vous souhaitez, en d'autre terme, vous passerez en paramètre le nom du fichier à afficher et le moteur de template se charge du reste.
Vous avez en plus de cela la possibilité de faire afficher la valeur de retour d'une variable, chose pratique sinon vos pages aurez été statique :) Il vous faudra donc choisir un formalisme de notation des variables pour votre moteur de template. Dans l'exemple suivant, le voici : {variable}. La variable {variable} devra donc être remplacée par une valeur. Ce procédé se fait dans votre programmation PHP, juste avant d'afficher le contenu d'un fichier template.

Les données de la classe de votre moteur de template

En premier lieu votre fichier devra comporter l'entête de la classe, c'est à dire :

<?php
class template {}
?>

Les données vous aideront sans doute à comprendre ce qu'il faut stocker pour que le moteur de template fonctionne, les voici :

private $repertoireTemplate;
private $contenuAAfficher;
private $variablesAssigneesCle;
private $variablesAssigneesValeur;

$repertoireTemplate contient le chemin vers le répertoire contenant vos fichiers template.
$contenuAAfficher représente le contenu de votre fichier template à afficher.
$variablesAssigneesCle c'est le nom de la variable du moteur de template à remplacer, dans notre cas ci-dessus ({variable}), il faudrait donc mettre en clé "variable".
$variablesAssigneesValeur; représente les valeurs de remplacement des variables du moteur de template.

Le contructeur de la classe

function __construct($repertoire) {
     $this->repertoireTemplate = $repertoire;
     $this->contenuAAfficher = "";
     $this->variablesAssigneesCle = array();
     $this->variablesAssigneesValeur = array();
}

Ce constructeur reçoit qu'un paramètre, le chemin vers le répertoire de vos fichiers templates.
Vous allez maintenant voir à quoi ressemble l'entête de votre fichier PHP :

<?php
require("template.class.php"); // moteur de template
$tpl = new template("templates/");
?>

Assigner une valeur PHP à une variable du moteur de template

La fonction suivante vous permettra d'assigner une clé à une valeur, la clé est le nom de votre variable dans le moteur de template, tandis que la valeur peut être une variable PHP, le résultat d'une requête, une simple chaîne de caractère.

function ajouteAccolade($val) {
     return "{".$val."}";
}

function assigner($cle, $valeur) {
     $cle = $this->ajouteAccolade($cle);
     array_push($this->variablesAssigneesCle, $cle);
     array_push($this->variablesAssigneesValeur, $valeur);
}

La fonction ajouteAccolade($val) est en lien avec la notation des variables que nous avons choisi. Si vous souhaitez la changer, c'est ici que ça se passe :)
assigner($cle, $valeur) quant à elle rajoute au tableau de clé et de valeur, les valeurs passées en paramètres. C'est à partir de ce tableau de clé et de valeur que nous ferons ensuite le changement des variables du moteur de template, juste avant d'afficher le contenu. Pour l'exemple (dans votre fichier PHP) :

$test = "Gnome";
$tpl->assigner("test", $test);

Afficher le contenu d'un fichier template et remplacer les variables par des valeurs

Voici le code de la fonction :

function ajouterTemplate($fichier) {
$this->contenuAAfficher = file_get_contents($this->repertoireTemplate.$fichier);
}

function afficher($fichier) {
     $this->ajouterTemplate($fichier);
     $this->contenuAAfficher = str_replace($this->variablesAssigneesCle, $this->variablesAssigneesValeur, $this->contenuAAfficher);
     echo $this->contenuAAfficher;
     $this->contenuAAfficher = "";
     $this->variablesAssigneesCle = array();
     $this->variablesAssigneesValeur = array();
}

La fonction ajouterTemplate($fichier) récupére tout le contenu du fichier template. afficher($fichier) quant à elle remplace les valeurs des clés par les valeurs des valeurs ^^ et affiche le résultat. Il faut penser à réinitialiser les variables à vide, sinon votre texte va se cumuler et je ne traiterai pas ce modèle de template ici. Certains en effet permettent d'enregistrer le contenu de plusieurs fichiers templates et de les afficher tous à la fin.
Toujours avec la même simplicité, voila comment faire afficher le contenu d'un fichier template dans votre navigateur. Tout d'abord il vous faut éditer votre premier fichier template :

Hello World! 
(Ca fait geek ça) 
{test} applets are nice!

Vous enregistrerez ce dernier dans votre répertoire de templates sous un nom quelconque.
Du côté PHP, voici ce que ça donne :

<?php
require("template.class.php"); // moteur de template
$tpl = new template("templates/");
$test = "Gnome";
$tpl->assigner("test", $test);
$tpl->afficher("nomdufichiertemplate.tpl");
?>

{test} va être remplacé par Gnome dans notre exemple, ce qui donnera au final :

Hello World!
(Ca fait geek ça)
Gnome applets are nice!

Code complet du moteur de template

<?php

class template {
	private $repertoireTemplate;
	private $contenuAAfficher;
	private $variablesAssigneesCle;
	private $variablesAssigneesValeur;

	function __construct($repertoire) {
		$this->repertoireTemplate = $repertoire;
		$this->contenuAAfficher = "";
		$this->variablesAssigneesCle = array();
		$this->variablesAssigneesValeur = array();
	}

	function ajouterTemplate($fichier) {
		$this->contenuAAfficher = file_get_contents($this->repertoireTemplate.$fichier);
	}

	function assigner($cle, $valeur) {
		$cle = $this->ajouteAccolade($cle);
		array_push($this->variablesAssigneesCle, $cle);
		array_push($this->variablesAssigneesValeur, $valeur);
	}

	function ajouteAccolade($val) {
		return "{".$val."}";
	}

	function afficher($fichier) {

		$this->ajouterTemplate($fichier);
		$this->contenuAAfficher = str_replace($this->variablesAssigneesCle, $this->variablesAssigneesValeur, $this->contenuAAfficher);
		echo $this->contenuAAfficher;
		$this->contenuAAfficher = "";
		$this->variablesAssigneesCle = array();
		$this->variablesAssigneesValeur = array();
	}

	function setRepertoireTemplate($repertoire) {
		$this->repertoireTemplate = $repertoire;
	}
}

?>

Conclusion

Les moteurs de templates du style Smarty ou Templeet, vous permettront évidemment de faire beaucoup plus, puiqu'il vous sera possible d'intégrer un code ressemblant au PHP directement dans vos fichiers templates, ce qui vous permettra par exemple d'effectuer une boucle foreach ou un if. Ces moteurs de template compilent un fichier PHP à partir des informations renseignées dans le fichier template. Ils conservent donc une trace et permettent un système de cache.

Donc le moteur de template que je viens de vous présenter là est beaucoup moins complet, mais ne fait que 45 lignes de codes lol :)

Pour information, cette technique n'est peut être pas la meilleure, ou peut être déjà connue, je ne sais pas, mais bon, on fait partager, ce qu'on peut faire partager :)
j'espère que cet article n'est pas trop décousu et qu'il vous aidera.