A l’heure où les environnements de développement pour PHP sont majoritairement basé sur Eclipse : PHP Development Tools, Aptana et Zend Studio, Netbeans quant à lui se faisait très discret dans le domaine des IDE PHP.

Voici la nouvelle version de NetBeans en release 6.8 avec des outils de développement pour PHP 5 fort intéressants :

Tout d’abord il existe une version de l’IDE entièrement dédié au développement PHP comme c’est le cas de la version All-In-One d’Eclipse.

- Il supporte également la version 5.3 de PHP

- Débugage de PHP dans l’IDE

- Exécution et pilotage de test-unitaires mis en place avec PHPUnit

- Support du Framework Symfony (autocompletion, exécution d’actions en ligne de commande depuis une console dans l’ide, support du YAML, …)

Nous allons nous intéresser au support de Symfony dans l’IDE et voir si son usage facile le développement avec le framework PHP français !

L’interface de NetBeans 6.8 est relativement simple, ergonome et traduite dans toutes les langues pour les non-anglophones.

1. Paramétrage de NetBeans pour PHP

Le paramétrage de NetBeans se fait en 3 étapes :

- Le chemin de l’exécutable « php.exe »
- Le chemin du script de PHPUnit (facultatif)
- Le chemin de la sandbox de symfony (symfony.bat ou symfony.sh)

Vous devez spécifier le chemin de votre serveur PHP, c’est à dire l’emplacement du « php.exe » de votre installation pour utiliser les fonctions de débugage, compilation et exécution de code PHP en « Command Line Interface ». Dans mon exemple, je donne le chemin d’accès de mon installation WAMP.

En suite, il vous faudra spécifier le chemin d’accès à la sandbox de Symfony, sous Windows il s’agit du fichier « symfony.bat ».

2. Création de votre projet Symfony

Pour créer votre projet Symfony, rien de plus simple, il suffit d’aller sur « Fichier -> Nouveau Projet » et de créer un nouveau projet « Application PHP ».

Donnez ensuite, un nom à votre projet, sélectionnez la version de PHP utilisée, dans notre cas, on pourra se contenter de la version 5.2.x.
N’oublier pas de donner le répertoire contenant le code source  du framework Symfony cela fonctionne avec n’importe quelle version du framework à priori sauf peut être pour la version en développement 2.0.

Pour ce qui est de la configuration de l’environnement de production pour le déploiement, nous n’avons pas à nous en soucier. On se contentera d’un environnement serveur en local.

Enfin on pourra spécifier que l’on veut utiliser le framework Symfony et que l’on veut générer une application « frontend » (application web principale destinée aux visiteurs du site) et une application « backend » (application dédiée à l’administration et au backoffice de l’application principale).

3. Dans la pratique

Voici comment se présente notre projet Symfony sous Netbeans 6.8. Nous avons un très bon éditeur de YML / YAML avec coloration syntaxique, autocompletion et schéma hiérarchique

On pourra également utiliser l’outil de génération de code en ligne de commande de Symfony en allant sur « MySymfonyProject -> click-droit -> Run Symfony Command ».

On a le résultat de l’exécution de la ligne de commande dans le partie console de NetBeans cet outil est très pratique pour exécuter les tests-unitaires de LIME le framework de test intégré à Symfony.

On niveau du développement « pur », on constate que l’autocompletion répond bien à la plupart des besoins de développeurs : les objets des vues, contrôleurs comme $sfWebRequest, $sfWebResponse, $view peuvent être appeler sans problème avec une intelliSense et même avec une petite documentation.

Conclusion

Ce support du framework Symfony est très intéressant à la fois pour la communauté des développeurs Symfony mais aussi pour NetBeans qui pourra peut être se faire une meilleure réputation dans le développement PHP car il faut le rappeler Symfony est le framework de développement PHP le plus utilisé avec Zend Framework . Les fonctionnalités de NetBeans vis à vis de ce framework sont très basiques mais relativement utiles. On regrettera peut être une meilleure intégration du framework de test unitaire et une génération de code plus importante. Peut-être vaut-il le coup d’être utiliser à la place d’Eclipse ou Aptana dans une optique de développement Symfony ? Ou aurons-nous du mal à nous séparer de nos bons vieux plugins sur Eclipse (pour Subversion, Database Explorer, PDT, Smarty, jQuery) ? Pour ma part, NetBeans a gagné ma confiance, je lui trouve une bonne ergonomie et une grande simplicité d’utilisation. Il existe une autre solution  pour le support de Symfony mais qui est quant-à-elle payante : il s’agit de PHPEdit il faut compter environ 219€ pour une version avec le support de Symfony et presque 300 € pour le support de PHPUnit et SVN.

Il s’agit avant tout d’un projet Symfony 1.2 qui utilise le design pattern MVC, Doctrine et Symfony.

Le projet a l’air très prometteur, il est toujours en version de test mais on peut dors-et-déjà le télécharger sur le site Officiel : http://www.sympalphp.org

Le CMS a l’air tout aussi complet qu’un Drupal, Spip ou Joomla et s’intègrera parfaitement avec les applications Symfony.

Voici 2 screencasts présents sur le site officiel pour illustrer le fonctionnement de l’application :

Doctrine ORM PHP 5 dors et déjà présent sur le framework Symfony, prépare une nouvelle version majeure du projet : Doctrine 2.0

Cette nouvelle version exclusivement compatible avec PHP 5.3 au minimum s’avère assez prometteuse et assez ambitieuse.

Petit rappel sur Doctrine : ce projet a été conçu tout comme Propel (basé sur Active Record) dans un but de créer un ORM relativement puissant et extrèmement riche en fonctionnalités : tests unitaires automatiser sur les classes relationnelles, schéma des bases en YML, génération de code automatique, système de cache avancé, plugins, gestion des contraintes d’intégrités avancée, load-balancing, profiler, outils de performances, validations des données en fonction du schéma, … Bref un véritable équivalent de Hibernate en PHP 5.

Le projet est principalement supporté par Sensio Labs (framework Symfony).

La prochaine version (Doctrine 2.0) sera basée sur PHP 5.3, elle utilisera les nouveaux drivers de PHP, et promet de véritable amélioration au niveau des performances.

Voici des benchmarks des performances de Doctrine 2.0 par rapport à sa version précédente :

PHP 5.2.8

#	Seconds	Memory
1	24	129170.648438 KB
2	23	129164.078125 KB
3	23	129176.851562 KB

PHP 5.3.0alpha4-dev

D’autre part, Doctrine deviendra beaucoup moins coûteux en code et sera moins verbeux.

En effet, Symfony offre un helper pour mettre en place un datepicker mais l’intégration de ce dernier avec un formulaire n’est pas évidente.

Pour palier ce problème, il existe un plugin qui facilite cette intégration. Il s’agit de sfFormExtraPlugin que l’on peut télécharger à cette adresse : http://www.symfony-project.org/plugins/sfFormExtraPlugin.

sfFormExtraPlugin propose des widgets additionnels pour sfForms dont notamment un Widget sfWidgetFormJQueryDate qui permet de créer un champ « Date » que l’on peut saisir via le DatePicker de jQuery.

Ajout du Widget sur le formulaire :

Après l’installation du plugin SfFormExtraPlugin, on instancie un widgetFormJQueryDate comme dans l’exemple ci-dessous :

On peut y passer 3 options :

- config : correspond à une instruction Javascript pour paramétrer directement le datepicker de jQuery
- culture : permet de choisir la langue du calendrier (anglais par défaut)
- format : format de sortie du calendrier, dans l’exemple j’ai mis la convention française jour/mois/année.

Coté template :

Il suffit tout simplement d’afficher le contenu du formulaire, en ajoutant bien évidemment le jQuery Framework avec la page, dans mon cas je l’ai inclus à l’aide d’un helper.

Lors d’une conférence Live Meeting en partenariat avec SUPINFO, Fabien Potencier nous a présenté le framework Symfony.

Je travaille actuellement sur ce framework pour mon stage et j’ai bien évidemment assisté à la conférence.

Après une présentation théorique de la plateforme de développement, Fabien nous a donné des précisions sur l’avenir du framework et notamment sur les ORM Propel et Doctrine.
Le conseil est de ne pas migrer une application existante sur Doctrine car cela serait inutile et trop couteux selon Fabien. En revanche, s’il s’agit d’une nouvelle application, le choix de Doctrine est plus judicieux.

En effet, Symfony se tournera de plus en plus vers Doctrine et même de façon définitive dans sa version 2.0 qui ne supportera plus Propel.

Le support des versions 1.x de Symfony sera assurer jusqu’en 2013 ce qu’il laisse une bonne marge de manoeuvre aux utilisateurs de Propel.

Fabien Potencier rappella plusieurs fois que Symfony est un framework destinée à une application professionnel et qu’il est le reflet de besoin d’entreprises qui souhaitent industrialiser leurs applications PHP. C’est cette origine du framework qui le distingue de ses concurrents notamment par rapport à Zend.