Prendre un Café

Ah la la. C'est assez rare pour être souligné, mais je viens de me battre avec Symfony pendant près de deux heures avec un problème assez déroutant de prime abord : lorsque dans une action vous faites quelque chose d'aussi anodin que ceci :

public function executeBar()
  {
    try
    {
      // Some stuff here, if successful redirect user to somewhere else
      $this->setFlash('notice', 'Action was successful');
      $this->redirect('@whatever_route');
    }
    catch (Exception $e)
    {
       $this->getRequest()->setError('errors', 'Something has failed somewhere, sorry dude');
       $this->logMessage('Big boo boo occured: '.$e->getMessage(), 'err');
       return sfView::SUCCESS;
    }
  }

Et bien dans ce cas là, la redirection s'opère MAIS l'ensemble du rendu sera tout de même produit et envoyé au navigateur ^[1] - ce qui peut s'avérer très couteux sur un site internet au final ^[2]. La raison en est très simple, la méthode redirect() de la classe sfActions met fin à l'execution par ce moyen que l'on peut qualifier de hardi :

public function redirect($url, $statusCode = 302)
  {
    $url = $this->getController()->genUrl($url, true);
    if (sfConfig::get('sf_logging_enabled'))
    {
      $this->getContext()->getLogger()->info('{sfAction} redirect to "'.$url.'"');
    }
    $this->getController()->redirect($url, 0, $statusCode);
    throw new sfStopException();
  }

Oui, vous avez bien lu, on interrompt le script en levant une exception, ici de type sfStopException. Le problème, c'est que dans mon exemple précédent, la méthode redirect() est appellée dans un bloc try { } catch { }, et donc l'exception levée est interceptée et l'action n'est au final pas stoppée. Vicieux, hein ?

Pour régler le problème, on peut par exemple toujours effectuer ses appels à la méthode redirect() en dehors d'un block try { } catch { } ^[3], ou encore tester le type de l'exception levée. Dans notre exemple, cette dernière solution ressemblerait à ça :

public function executeFoo()
  {
    try
    {
      // Some stuff here, if successful redirect user to somewhere else
      /// ...
      $this->setFlash('notice', 'Action was successful');
      $this->redirect('@whatever_route');
    }
    catch (sfStopException $e)
    {
      return sfView::HEADER_ONLY;
    }
    catch (Exception $e)
    {
      $this->getRequest()->setError('errors', 'Something has failed somewhere, sorry dude');
      $this->logMessage('Big boo boo occured: '.$e->getMessage(), 'err');
      return sfView::SUCCESS;
    }
  }

C'est pas super sexy, mais ça fonctionne, et ça a le mérite de m'inspirer deux morales à cette histoire :

1. tester le type des exceptions que l'on catche, c'est bien
2. lever une exception pour arrêter un script, c'est super cracra et mériterait éventuellement d'être patché

Edit: Je m'exprime mal, c'est pas super cracra, c'est juste que ça introduit une petite complexité supplémentaire. Mais l'utilité de la chose est bien entendu totalement avérée si on a besoin d'effectuer des opérations particulières avant la fin du script ( ce qui est rarement le cas, enfin chez moi).

Tiens, ça faisait longtemps...

• Un petit tour d'horizon des possibilités de HTML 5. Évolution très prometteuse du vieux et abscons HTML 4, la date de sortie supposée (dans 10 ou 15 ans dixit l'auteur) refroidit cependant, et c'est dommage...
• Javascript 2 pointe le bout de son nez, basé sur la version 4 de la spécification ECMAScript. Au programme, entre autres réjouissances, classes, interfaces, namespaces et packages : MIAM (et surtout, ENFIN.)
• Quelques unes des nouvelles fonctionnalités retenues pour implémentation dans la version 5.3 de PHP : namespace support (megayeah), OpenID support in ext/openssl (megayeah), late static binding (yeah), SQLite 3 support in ext/sqlite (cool), mysqlnd library in the core (cool)... Mais que restera t-il à PHP 6 ?
• CouchDB, un serveur de base de document accessible via une API REST JSON très prometteuse avec un exemple de mise en oeuvre simple et efficace.
• Côté Symfony :
  • Une chouette exploration des fonctionnalités de gestion de formulaires et de leur validation dans la prochaine version 1.1 du framework.
  • Un chouette projet de forum basé sur le framework et quelques plugins a vu le jour : Motilee. Contributions bienvenues.
  • Fabien Potencier, créateur et mainteneur de Symfony a ouvert son blog, et on y trouve déjà quelques petites astuces intéressantes.

Suite à l'émergence des frameworks web, beaucoup d'équipes de développement ont décidé de leur utilisation sans toujours bien réaliser les tenants et aboutissants liés la démarche, croyant souvent avoir enfin trouvé une méthode miracle pour produire vite et bien. Il peut en résulter de sévères déconvenues, quel que soit le framework, le langage ou la plateforme retenus.

Concernant Symfony, il en va de même ; et si on peut bien entendu trouver énormément d'avantages à son utilisation sur un projet, il faut également bien avoir conscience des contraintes qu'un développement sur sa base implique, sous peine de se retrouver dans le mur assez rapidement.

Symfony n'est pas un CMS

Il est immédiatement tentant de retenir Symfony pour tout type de projet tellement il est agréable de développer sur sa base. Cependant, pourquoi systématiquement réinventer une roue qui tourne peut-être déjà fort bien ailleurs ? L'idée ici est de s'interroger sur la réelle nécessité de recourir à un développement spécifique ; en effet, même si coder en Symfony est très encadré, il n'empêche que la logique métier est entièrement à définir par l'équipe de développement ^[1]. Plus particulièrement concernant les problématique de gestion de contenus, le besoin métier sur le projet est-il suffisamment conséquent, ou un CMS comme Drupal, SPIP, ezPublish ou Joomla couvre t-il nativement l'ensemble du périmètre fonctionnel cible ? ^[2]

Un développement spécifique introduira le plus souvent beaucoup plus d'exigences, de compétences et de compléxité qu'une intégration basée sur un outil de gestion de contenus autonome existant (et digne de ce nom). L'idée est bel et bien de renoncer à se faire plaisir à tout prix pour se situer au plus près de la réalité du besoin.

Bien entendu, je me fais aussi ici l'avocat du diable. Pour avoir joué avec les principaux CMS PHP open source du marché et connaissant la propension naturelle d'un client à enrichir au gré de l'avancement projet le périmètre fonctionnel souhaité ^[3], je préfère allègrement à titre personnel me baser sur un framework comme Symfony afin de rester agile et parer à toute éventualité. Mais je sais aussi quelles sont mes compétences réelles sur le sujet, et dès qu'une équipe dont je ne cerne pas le niveau entre en ligne de compte, généralement les problèmes commencent. Ça tombe bien, c'est justement l'objet du prochain chapitre

Symfony est exigeant

Non, Symfony ne transformera pas magiquement un mauvais développeur en bon développeur... même s'il peut y contribuer à terme

Plus sérieusement, le but réel de l'utilisation d'un framework est bel est bien de vous rendre plus efficace et productif, certainement pas de vous compliquer la vie ou de vous faire perdre du temps.

Il faut bien prendre conscience que le temps de montée en compétence sur l'utilisation du framework - déjà naturellement exigeante - requière également pour certains une montée en compétence en programmation tout court. Et cette dernière, si elle peut se faire sur un projet, peut également allègrement le plomber. Un développeur débutant bidouilleur PHP mettra fatalement plus de temps qu'un codeur expérimenté à appréhender l'ensemble des possibilités introduites par PHP5, la programmation orientée objet, les motifs de conception, mais aussi le respect des bonnes pratiques notamment liées au travail collaboratif ou que sais-je encore.

Le risque à court terme est de voir le code du projet grevé dans sa qualité et sa maintenabilité. À moins bien entendu de prendre en compte en amont cette charge inhérente à la formation, mais on connait tous la réalité professionnelle et commerciale du milieu qui est le notre

Symfony ne vous dispense pas d'organiser votre projet

Oui, Symfony fait la part belle aux conventions et prémâche énormément le travail redondant à tout projet de type web. La vie des (bons) développeurs est grandement facilitée, et on peut vraiment gagner rapidement beaucoup de temps. Mais une grave erreur serait de sous-estimer la charge liée à l'organisation et la gestion de la vie du projet.

Par exemple, ce n'est pas en mettant plus de développeurs sur un projet Symfony (ou autre d'ailleurs) que celui-ci sera développé plus vite. Au contraire, même ; tout codeur avec un tant soit peu d'expérience professionnelle a déjà rencontré ce type de cas de figure : on vend un projet de 100 jours de développement, on se fixe un retroplanning ambitieux avec une mise en ligne à 20 jours ouvrés, et on staffe donc arithmétiquement cinq développeurs à plein temps en pensant que le résultat sera totalement équivalent au travail qu'aurait fourni un unique développeur en 100 jours de développement pour concevoir l'intégralité du code de l'application résultante.

Bien entendu, c'est illusoire et généralement, le projet se termine sur des dépassements conséquents et le mécontentement du client ^[4]. Et pour cause, la déperdition d'énergie utilisée à la communication sur le projet est fonction du nombre d'acteurs présents sur ce dernier. Et on peut staffer trois chefs de projet à plein temps pour canaliser tout ça, c'est d'une part économiquement peu viable et d'autre part totalement inefficace, ces derniers devant perdre également beaucoup de temps à se synchroniser entre eux, puis avec les membres de l'équipe.

Moralité

Non, Symfony n'est pas le remède miracle aux lacunes organisationnelles des structures en charge de la réalisation d'un projet, mais bien un outil exigeant qu'il faut savoir appréhender de la bonne façon en prenant en compte le plus en amont possible ces problématiques. Le gain réel et indiscutable d'efficacité apporté par l'utilisation d'un framework comme Symfony est à ce prix