Si vous utilisez Doctrine comme Object Relational Mapper (ORM), vous connaissez certainement les behaviours Timestampable, Sluggable ou encore SoftDelete. Les extensions Doctrine vous permettent justement d’en ajouter de nouveaux très facilement, en quelques clics ou lignes de commande.

Aujourd’hui, je vous propose d’installer et d’utiliser l’extension Taggable. Cette dernière permet d’ajouter des tags sur les modèles de votre choix. L’intérêt peut être de faire des recommandations ou retrouver des éléments relatifs à un autre.

Commençons d’abord par installer l’extension Taggable :

1. Placez-vous dans le dossier racine de votre projet symfony.

   cd /chemin/vers/le/projet/symfony/

2. Créez un dossier doctrine_extension dans lib.

   mkdir lib/doctrine_extension

3. Téléchargez l’extension Taggable avec subversion.

   svn co http://svn.doctrine-project.org/extensions/Taggable/branches/1.2-1.0 lib/doctrine_extension/Taggable

4. Videz le cache symfony (peut-être plus nécessaire mais c’est encore un réflexe chez moi).

   php symfony cc

5. Activez l’extension Doctrine :
   • Éditez le fichier config/ProjectConfiguration.class.php
   • Si vous ne l’avez pas encore, créez la méthode configureDoctrine

       public function configureDoctrine(Doctrine_Manager $manager)
       {
       }

   • Ajoutez le code ci-dessous dans la méthode.

         Doctrine::setExtensionsPath(sfConfig::get('sf_lib_dir').'/doctrine_extension');
         $manager->registerExtension('Taggable');

Voilà l’extension avec maintenant installée et activée. Voyons maintenant, comment l’utiliser. Pour cela je vais prendre un exemple très simple avec des articles qui possèdent des tags.

1. Définissez le modèle Article en copiant le contenu ci-dessous dans un fichier config/doctrine/10_articles.yml
   [yaml]Article:
   actAs:
   Taggable:
   columns:
   title: { type: string(255), notnull: true, notblank: true }
   body: { type: clob, notnull: true, notblank: true }
   [/yaml]
2. Ajoutez des fixtures en copiant le contenu ci-dessous dans un fichier data/fixtures/10_articles.yml
   [yaml]Article:
   Article_1:
   title: Mon premier article
   body: |
   Hello World !
   Ceci est mon premier article.
   tags: hello, world, article 1

   Article_2:
   title: Mon second article
   body: |
   Hello World !
   Ceci est mon second article.
   tags: hello, world, article 2
   [/yaml]

3. Créez les fichiers php associés au modèle et chargez les fixtures avec la commande suivante :

   php symfony doctrine:build --all --and-load

4. Créez un module Article dans l’application frontend

   php symfony generate:module frontend article

5. Éditez le fichier apps/frontend/modules/article/actions.class.php et remplacez le code de la méthode executeIndex par le code ci-dessous

       $this->articles = Doctrine::getTable('Article')->findAll();
       $this->popular_tags = Doctrine::getTable('TaggableTag')->getPopularTags();

6. Éditez le fichier apps/frontend/modules/article/indexSuccess.php et collez le code ci-dessous

   <h1>Articles</h1>
   
   <h2>Liste des articles</h2>
   <?php foreach ($articles as $article): ?>
     <h3><?php echo $article->title ?></h3>
     <p><?php echo nl2br($article->body) ?></p>
     <p>Tags : <?php echo $article->getTagsString() ?></p>
   <?php endforeach ?>
   
   <h2>Tags populaires</h2>
   <ul>
   <?php foreach ($popular_tags as $tag): ?>
     <li><?php echo $tag->name ?> (<?php echo $tag->total_num ?>)</li>
   <?php endforeach ?>
   </ul>

Si vous avez utilisez la sandbox symfony 1.4 pour suivre ce tutoriel, vous ne devriez pas avoir de problème. Toutefois, il existe quelques subtilités dans l’utilisation de l’extension Taggable que j’ai rencontré lors de son utilisation dans un projet réel. Je les mets ci-dessous, si vous en avez d’autres n’hésitez pas à le signaler dans les commentaires.

• Pour utiliser la table TaggableTag vous devez obligatoirement avoir chargé une autre table utilisant l’extension. Dans mon exemple, si vous inversez les deux lignes de la méthode executeIndex, vous obtiendrez une belle exception « Couldn’t find class TaggableTag ».
• Si vous essayez de supprimer un élément « Taggable », une exception sera levée. En effet, les tags associés à l’objet doivent être supprimés avant l’objet lui-même. Vous pouvez soit utiliser l’évènement preDelete pour supprimer les tags avant l’objet soit appliquer le patch que j’ai proposé dans l’issue tracker de Doctrine pour ajouter un onDelete CASCADE sur la relation.
• Les relations many-to-many entre votre modèle « Taggable » et les tags sont ajoutées à la volée, il faut donc « charger » le modèle avant l’utilisation d’une de ces relations. Ainsi, si vous voulez afficher un nuage de tags avec la méthode getPopularTags, il faudra charger chaque modèle « Taggable » où alors vous n’aurez que les tags populaires des modèles déjà chargés.

En conclusion, l’extension Taggable est très intéressante mais il subsiste quelques défauts qui peuvent bloquer son utilisation dans un projet concret. Si j’ai réussi à corriger les problèmes 1 et 2, le 3e reste non résolu pour le moment. La solution serait d’ajouter les relations dans les fichiers php générés par Doctrine lors de la création des modèles. Pas sûr que ce soit possible dans l’état actuel…

« Symfony 1.3 Web Application Development » compte un peu plus de 200 pages que je viens tout juste de terminer. Alors, convaincu ou déçu ? Voici mon avis…

Symfony dans tous ses états

Contraire à ce que je pensais avant la lecture du livre, le public visé n’est pas les développeurs utilisant déjà symfony et ayant envie d’en savoir plus sur la version 1.3 du framework. Non, le livre est plutôt destiné aux personnes qui ont envie de commencer à utiliser symfony et d’apprendre à l’utiliser.

Le livre est très complet et couvre les principales fonctionnalités proposées par le framework symfony : MVC, ORM, templates, admin generator, form framework, cache, ou encore internationalisation (i18n). Autant dire qu’à la fin de la lecture, le développeur dispose d’une bonne connaissance du framework et est fin prêt pour commencer un nouveau projet avec. Si il trouve symfony un peu faible en fonctionnalités (rappelons que le but de Symfony c’est de fournir ce qui est commun à 99% dans tous les projets web), il y a même un chapitre sur l’intégration de composants du Zend Framework ou de eZ Components. Un très bon point à mon avis.

Vous avez dit symfony 1.3 ?

Malgré cela, « Symfony 1.3 Web Application Development » souffre malheureusement de quelques défauts…

Tout d’abord, on trouve un certain nombre de fautes par ci par là, tant au niveau du texte qu’au niveau code. Si vous appliquez à la lettre le code présent dans le livre votre application ne fonctionnera pas. Rien de très grave, un développeur avec un minimum de connaissance en PHP n’aura aucun mal à les repérer et à les corriger…

Ensuite, bien que symfony 1.3 soit présent dans le titre, il s’agit plus d’un livre sur la version 1.2. En effet, à part des screenshots et quelques détails, je dois bien avouer que je n’ai pas vu grand chose de la nouvelle mouture du framework et c’est bien dommage. Le livre est sorti un peu trop vite, les grandes nouveautés de la version 1.3 n’étaient alors pas encore disponibles. Ainsi, par exemple, sur la partie « envoi de mails », le livre est déjà obsolète. On pourrait également regretter l’utilisation Propel malgré que Doctrine soit l’ORM par défaut de symfony 1.3.

Conclusion

Que penser du livre « Symfony 1.3 Web Application Development » ? Tout dépend de votre profil et de vos attentes. Si vous connaissez déjà symfony et que vous voulez connaître la version 1.3, passez votre chemin ce n’est pas le but du livre. Au contraire, si vous êtes développeur PHP et que vous avez envie d’apprendre à l’utiliser, allez-y ! Le livre est bien écrit et les choses sont bien expliquées. Une fois la lecture terminée, si vous voulez utiliser à fond Symfony 1.3, jetez un coup d’œil à la page What’s new in symfony 1.3/1.4 pour découvrir les nouveautés, cela terminera votre apprentissage.

En résumé, un bon livre qui permettra à tout ceux qui n’utilisent pas encore symfony d’appréhender l’outil sans difficulté.

Acheter « Symfony 1.3 Web Application Development » chez PacktPublishing
Acheter « Symfony 1.3 Web Application Development » sur Amazon.fr

Tout d’abord, qu’est-ce qu’un composant dans Symfony ? Il s’agit en quelque sorte d’une action qui est réutilisable entre les différents modules de l’application. A la différence des « partials », qui sont « que » des templates, les composants contiennent de la logique : le plus souvent, récupérer un ou plusieurs modèles.

Pour revenir à la question, le problème n’est pas de gérer la validation à proprement parler, Symfony va s’en occuper grâce au forms framework mais plutôt de savoir où envoyer le visiteur une fois le formulaire soumis et comment, à la fin, le rediriger sur la page initiale, celle où il a rempli le formulaire.

Une solution possible est de créer une action spécifique pour valider le formulaire et d’ajouter un champ caché « referer » contenant l’url de la page initiale. Dans le fonctionnement, c’est relativement simple, le formulaire du composant pointe vers l’action et lorsque les données saisies sont valides, l’utilisateur est redirigé vers le valeur du champ « referer ».

Pour les intéressés, vous trouverez ci-dessous le contenu des différents fichiers pour l’utilisation d’un formulaire en composant. C’est prévu pour fonctionner avec Symfony 1.2.

1. Le formulaire (lib/form/TestForm.class.php)

   < ?php
   class TestForm extends sfForm
   {
   	public function configure()
   	{
   		$this->setWidgets(array(
   			'name'    => new sfWidgetFormInput(),
   			'referer' => new sfWidgetFormInputHidden(),
   		));
    
   		$this->setValidators(array(
   			'name'    => new sfValidatorString(),
   			'referer' => new sfValidatorString(array('required' => false)),
   		));
    
   		$this->widgetSchema->setNameFormat('test-form[%s]');
   	}
   }

2. Le composant (apps/frontend/modules/mymodule/actions/components.class.php)

   < ?php
   class mymoduleComponents extends sfComponents
   {
   	public function executeTestForm(sfWebRequest $request)
   	{
   		$this->form = new TestForm(array(
   			'referer' => $request->getUri()
   		));
   	}
   }

3. Le template du composant (apps/frontend/modules/mymodule/templates/_TestForm.php)

   <h2>My Form</h2>
   <form action="<?php echo url_for('test-form') ?>" method="post">
     <table>
       < ?php echo $form ?>
     </table>
     <input type="submit" value="Send" />
   </form>

4. L’action (apps/frontend/modules/mymodule/actions/actions.class.php)

   < ?php
   class mymoduleActions extends sfActions
   {
   	public function executeTestForm(sfWebRequest $request)
   	{
   		$this->form = new TestForm(array(
   			'referer' => $request->getUri()
   		));
    
   		if ($request->isMethod('post'))
   		{
   			$this->form->bind($request->getParameter($this->form->getName()));
    
   			if ($this->form->isValid())
   			{
   				$this->redirect(
   					$this->form->getValue('referer') ? $this->form->getValue('referer') : 'homepage'
   				);
   			}
   		}
   	}
   }

5. Le template de l’action (apps/frontend/modules/mymodule/templates/TestFormSuccess.php)

   < ?php include_partial('TestForm', array('form' => $form)) ?>

6. La règle de routage (apps/frontend/config/routing.yml)

   test-form:
     url:    /test-form
     param:  { module: mymodule, action: TestForm }

Une fois tous les fichiers créés, il ne reste plus qu’à inclure le composant dans un template, par exemple apps/frontend/layout.php, en ajoutant ceci :

< ?php include_component('mymodule', 'TestForm') ?>

Ici, le formulaire ne sert absolument à rien, la valeur saisie n’est pas utilisée. Il s’agit juste d’un exemple pour montrer le principe.

Note : Attention WordPress à ajouté un espace entre < et ?php

Tout bon développeur qui se respecte, je ne laisserai pas ce genre de paramètre perdu dans la logique métier. Tout d’abord parce que ça n’a absolument rien à faire là et ensuite parce qu’il ne serait pas facile de modifier le paramètre plus tard. Une bonne pratique est donc de créer un fichier à part pour stocker ces paramètres…

Dans symfony, il y a un fichier de paramètres pour les applications (apps/monapp/config/app.yml) et un pour les modules (apps/monapp/modules/monmodule/config/module.yml) mais pour tout le projet il n’y aucun fichier pré-défini par défaut. Heureusement, symfony est un framework très flexible et l’on peut ainsi ajouter un nouveau fichier de config en quelques lignes seulement…

Pour les intéressés, voici la procédure :

1. Créez un fichier nommé config_handlers.yml dans le dossier config
2. Copiez dans le fichier précédemment créé le code ci-dessous :

   config/project.yml:
     class:		sfDefineEnvironmentConfigHandler
     param:
       prefix: project_

3. Créez le fichier config/project.yml et ajoutez quelques paramètres. Par exemple :

   all:
     website:
       name: Mon site internet

4. Il faut maintenant charger les paramètres pour chaque application du projet.
   • Modifiez le fichier config/ProjectConfiguration.class.php
   • Ajoutez une fonction loadProjectConfig :

     	protected function loadProjectConfig()
     	{
     		static $load = false;
      
     		if (!$load && $this instanceof sfApplicationConfiguration)
     		{
     			require $this->getConfigCache()->checkConfig('config/project.yml');
     			$load = true;
     		}
     	}

   • Chargez le fichier de config en ajoutant le code ci-dessous dans la méthode setup de la classe :

     			$this->loadProjectConfig();

5. C’est fini !

Vous pouvez maintenant, dans les applications de votre projet, accéder aux paramètres définis dans project.yml en utilisant sfConfig::get('project_...').

Attention, si comme moi vous écrivez des tests automatisés pour vos projets, pour les tests unitaires, il faudra ajouter un ligne afin de charger le fichier de config personnalisé :

$configuration = ProjectConfiguration::getApplicationConfiguration('frontend', 'test', true);

Je vous conseille d’ailleurs d’écrire un bootstrap avec cette ligne plutôt que de la copier/coller dans chaque fichier de test

Voilà maintenant quelques jours que j’ai commencé à utiliser le framework symfony… J’avais déjà testé dans le passé deux autres frameworks, à savoir Ruby On Rails et Zend Framework. Ils ne m’avaient pas vraiment convaincu en terme de rapidité de développement. Je précise toutefois que je les avais utilisé à leur début, les choses se sont sûrement améliorées mais j’avais très envie de tester symfony

Découverte de symfony

Pour faire mes premiers pas avec symfony, après avoir procédé à  l’installation de la version 1.1, je me suis dirigé vers le tutoriel My First Project. Il est plutôt bien fait, tout est expliqué en détails. Cela dit, je ne l’ai pas fait en entier, après avoir appris les bases du framework, je suis parti sur le tutoriel Askeet.

Le tutoriel Askeet est très bien fait et pour une fois on ne nous propose pas créer une bibliothèque/dvdthèque ou un blog mais une application dans le genre de Yahoo! Answers. Le petit problème avec ce tutoriel c’est qu’il est écrit pour le version 1.0 de symfony et que moi je voulais utiliser la dernière version, la 1.1. Bon, en réalité, on peut réussir à s’en sortir avec la 1.1, il faudra adapter le code parfois. Le plus gros du travail concerne les formulaires mais c’est alors l’occasion de lire le tutoriel symfony Forms in Action et de le mettre en pratique. Ça a été très instructif ! J’ai arrêté le tutoriel après une dizaine de jours (le tutoriel est organisation sous la forme d’un calendrier de l’Avant) estimant en avoir assez vu pour savoir si j’allais utilisé symfony ou non.

Mon avis

La première chose qui m’a surpris, dans le bon sens, avec symfony c’est les outils de débuggage. En effet, il est possible d’afficher tout un cas d’informations comme les requêtes SQL exécutées, les logs ou encore la configuration très facilement. Ces outils se présentent sous la forme d’une barre en haut à droite qui vous suit partout.

Ensuite, symfony est d’une facilité déconcertante ! En quelques lignes on se génère les classes « models », on créé une application , un module, une page. Des bonnes connaissances en programmation orientée objet sont toutefois nécessaires.

Un autre détail que j’ai trouvé très bien, c’est le « Form Framework ». Il permet de gérer un formulaire très simplement. Il suffit de définir les champs et les validateurs à appliquer, le framework va alors s’occupe de générer le formulaire, de valider les données lors de l’envoi et le cas échéant retourner le formulaire avec les erreurs et les valeurs précédemment saisies pré-remplies.

Il y a un point sur lequel je suis assez partagé : le testeur de symfony. Peut-être suis-je trop habitué à SimpleTest ? Je pense que je reviendrais sur ce point dans un prochain billet (avec un plugin pour l’améliorer ?).

Conclusion

En seulement quelques jours, je n’ai pas pu découvrir toutes les fonctionnalités de symfony. Toutefois, j’en ai vu assez pour savoir qu’il est très puissant, assez facile à prendre en main (pour un développeur maitrisant la POO) et extensible. Je n’en ai pas parlé mais on peut ajouter des plugins et il en existe déjà de nombreux (voir la liste des plugins symfony).

Symfony est un outil que je pourrais utiliser pour réaliser un projet sans problème. C’est très agréable de développer avec !

Et maintenant, il me tarde de créer mes premières tasks, de tester le système d’évènements, d’utiliser l’internationalisation (i18n), créer mon premier plugin, de tester les tasks i18n:extract, pour extraire les chaînes à traduire, et i18n:find pour trouver les chaînes non-traduites, …

Mootools est une librairie javascript qui permet, notamment, d’utiliser AJAX et de créer de jolis effets sur un site web. Jusque là rien de nouveau, il en existe déjà un certain nombre sur internet mais l’une des qualités de mootools est d’être léger ce qui le point faible actuel des autres frameworks…

La page de téléchargement de Mootools permet de se créer un framework personnalisé en choisissant uniquement les fonctions que l’on souhaite. On a ainsi une librairie javascript qui correspond vraiment à ses besoins.

La documentation de la librairie est également une belle réussite : claire, précise et complète.

La version 1 de Mootools est disponible depuis quelques jours sur mootools.net

Ces derniers jours, j’ai commencé à m’intéresser aux frameworks PHP. Le plus récent est le Zend Framework. On entend beaucoup parler de lui en ce moment sur Internet. J’ai rapidement regardé le code et la liste des fonctionnalités, rien ne semble si exceptionnel que ça. Faut-il le tester pour découvrir ce qui fait de lui un framework si intéressant ?

Au sujet des frameworks PHP, JournalDuNet a publié mardi un article intéressant : 10 frameworks PHP

Sinon, Wikipédia propose une liste de frameworks PHP.

La première étape consiste à installer Ruby et Rails sur son PC (ou Mac ). Je les ai installé de façon « manuelle » mais j’ai appris après qu’il existait une sorte d’EasyPHP pour RoR : Instant Rails. Je ne l’ai pas testé mais à priori, ça fonctionne. Si l’installation manuelle intéresse certaines personnes, je pourrai faire un autre billet ;-).

Premiers pas
Ruby On Rails installé, je peux enfin passer à l’action. Je me suis d’abord créer un dossier rails sur mon disque de développement. Ce dossier contiendra toutes les applications Rails. Maintenant via l’invite de commandes (cmd.exe), je me place dans le dossier (dans mon cas c’est rails) et je créé ma première application via la commande :
rails mon_appli

Un ensemble de dossiers et de fichiers a normalement été créé. Vous pouvez maintenant accéder à votre première application. Pour cela, placez-vous dans le dossier mon_appli (cd mon_appli) puis lancez la commande :
ruby script\server

En allant à l’adresse http://127.0.0.1:3000/ vous devriez voir une page de bienvenue ^^
Surtout ne fermez pas l’invite de commandes !

C’est bien beau tout ça mais comment je créé une page ?
C’est tout simple :

1. Lancez une nouvelle invite de commandes
2. Placez vous dans le dossier mon_appli
3. Lancez la commande ruby script\generate controller Fabien_IBF
4. Allez dans le dossier mon_appli (plus via cmd.exe) puis dans app et enfin dans controllers.
5. Clic droit sur le fichier fabien_ibf_controller.rb et cliquez sur Modifier.

Le contenu du fichier devrait être le suivant :
class FabienIBFController > ApplicationController
end
En-dessous de :
class FabienIBFController > ApplicationController

Ajoutez :
def index
render_text "Ma première page"
end

Votre page est visible à l’adresse : http://127.0.0.1:3000/Fabien_IBF

Si vous voulez une page ‘ma_page_2′, il suffit d’ajouter en-dessous :
def ma_page_2
render_text "Ma deuxième page"
end

Vous pouvez la voir à l’adresse suivante : http://127.0.0.1:3000/Fabien_IBF/ma_page_2

Conclusion
Je m’arrête là mais RoR permet de faire bien plus. Je vous invite à tester Typo un moteur de blog très sympa.

Pour un framework aussi récent (la version 1.0 est sortie le 14 décembre 2005), je trouve que Ruby On Rails s’en sort bien. RoR permet de gagner beaucoup de temps dans le développement d’une application web (voir la vidéo « Créer un blog en 15 minutes » sur le site officiel du framework). Pour le moment le problème c’est les hébergeurs. A ma connaissance, en France, seul Typhon propose des offres avec Ruby On Rails. Espérons que d’autres hébergeurs s’y mettent aussi rapidement…

Je vais continuer à explorer ce framework et qui sait peut-être que je sortirai bientôt ma première application RoR ^^