sfProjectAnalyserPlugin : est-ce que ton code est beau ?

0 gravatar Par Grégoire Marchal - 16/09/2010

Si tu crois être un boss de Symfony, si tu penses que ton code respecte les standards les plus stricts, si tu es sûr que toutes tes méthodes sont documentées, si tu ne fais jamais de sfContext::getInstance(), alors tu peux te mesurer au terrible sfProjectAnalyserPlugin !

Ce plugin permet en effet de mesurer la qualité et la volumétrie d'un projet. Il peut compter le nombre d'applications, de modules, d'actions d'un projet, vérifier la longueur des fonctions et des templates, lève des alertes dès qu'il repère des choses anormales, et bien d'autres choses encore.

Ce n'est pas juste un jouet pour sortir quelques statistiques sur son travail. Tout son intérêt réside dans son utilisation en tant qu'outil d'intégration continue. Imaginez que vous commenciez un tout nouveau projet Symfony : si chaque matin, après votre nesquik, vous lancez l'analyse de votre projet et si vous suivez les précieux conseils donnés dans la page de résultat, vous aurez au final un code beau, propre et facile à maintenir ! Vous serez alors le roi du pétrole et vous pourrez faire un énorme don aux gentils développeurs de ce plugin, sans qui vous ne seriez rien !

Et si vous ne le trouvez pas assez strict (ou trop strict, honte sur vous :)), pas de problème ! Il est entièrement paramétrable via son fichier YAML.

L'analyse se lance en une simple commande Symfony :

symfony project:analyse --application="frontend" --env="dev" > analysis.html

Elle génère un rapport sous la forme d'un simple fichier HTML que vous pouvez bien sûr visualiser dans votre navigateur favori :

sfProjectAnalyserPlugin sur sf sandbox

Pour davantage d'informations, rendez-vous sur la page du plugin sfProjectAnalyserPlugin.

PS : vous l'aurez peut-être deviné, je fais partie des développeurs de ce magnifique plugin ! Même si ma contribution n'a été que très modeste pour le moment... (je vais me rattraper Loïc !)

Symfony et Doctrine : connexions multiples

6 gravatar Par Grégoire Marchal - 02/09/2010

Bon, ok, pour un premier article, je ne me lance pas dans un concept super compliqué et inconnu de tous, certes. Considérons ça comme un rodage ! Je vais donc tâcher de faire un petit article sur ma récente première utilisation de connexions multiples à des bases de données, avec Symfony 1.4 et Doctrine 1.2.

A la base, mon projet se connectait à une seule base, la configuration classique, la routine. Un beau jour, j'ai eu besoin d'aller mettre à jour la valeur d'un champ dans une autre base de données. Deux possibilités se présentaient :

  • utiliser les infâmes fonctions mysql_*() comme dans les années 80 (bon, c'est peut-être pas si vieux, mais presque)
  • découvrir le monde merveilleux des connexions Doctrine multiples

Ne m'étant jamais penché sur ce point, j'avais peur que la seconde option soit trop lourde. Mais conseillé par mes collaborateurs d'SQL Technologies, la tâche s'est avérée finalement très simple.

Premièrement, il a fallu modifier le fichier config/databases.yml afin qu'il prenne en compte la seconde connexion :

# databases.yml
all:
  connection1:
    class:        sfDoctrineDatabase
    param:
      ...
  connection2:
    class:        sfDoctrineDatabase
    param:
      ...

J'ai ensuite introspecté cette seconde base pour que Symfony génère son schéma (vous pouvez le faire à la main si vous êtes courageux !) :

symfony doctrine:build-schema

Et là, magie : dans le fichier config/doctrine/schema.yml, on voit désormais que chaque table est liée à une des deux connexions grâce au paramètre... "connection" !

MyTable1:
  connection: connection1
  columns:
    ...
MyTable2:
  connection: connection2
  columns:
    ...

Et lorsque l'on reconstruit le modèle, la magie opère ! Dans les fichiers Base*.class.php du modèle, une nouvelle ligne est apparue, permettant "d'attacher" chaque classe du modèle à sa connexion :

// BaseMyTable1.class.php
// Connection Component Binding
Doctrine_Manager::getInstance()->bindComponent('MyTable1', 'connection1');

Et c'est tout ! On peut alors utiliser nos objets presque sans se soucier d'où proviennent et où vont les données.

// stupid actions
$oObject1 = Doctrine::getTable('MyTable1')->find(7);
$oObject2 = Doctrine::getTable('MyTable2')->find(42);
$oObject2->setName($oObject1->getTitle())->save();

Vive Doctrine, et vive Symfony !