Experimental-Symfony.com. Experimentation autours du framework PHP Symfony

Netbeans 6.8 intègre un support pour Symfony. Rien de révolutionnaire mais les petits plus qui devraient faire de NetBeans l'IDE de prédilection des développeurs Symfony : 

• Auto-complétion dans les vues

• Raccourcies pour le passage Action->Vue et Vue->Action

• Accès rapide aux commandes Symfony
  

Le screencast (Via Le blog de NetBeans for PHP ) :

2 problèmes, et j'en reviens toujours à mon casse tête pour arriver à travailler avec 2 versions différentes de Symfony, le plugin semble ne pas fonctionner avec Symfony 1.0 et ne permet pas de gérer plusieurs versions de Symfony (la configuration du client Symfony se fait au niveau des options générales de l'IDE et non au niveau des options du projet).

J'ai peu développé depuis 1 an et demi, alors quand j'ai du reprendre le dev pour le site de notre agence de référencement, Symfony 1.2 était disponible en version stable. Je me suis donc retrouvé avec 4 sites en production sous version 1.0 et de nouveaux projets à concevoir sous 1.2.

Habitué à travailler en local avec PEAR sous Windows XP et WAMP, je me suis retrouvé face à un casse-tête, faire coexister 2 versions de PEAR. Plusieurs problèmes se sont alors posés : impossible de faire coexister 2 versions de PEAR avec une seule version de PHP et impossible d'installer 2 versions de WAMP. C'est très loin d'être idéal mais la solution la plus simple que j'ai trouvé est la suivante : 

- Installer WAMP -> Initialiser PEAR -> Installer Symfony 1.0 (qui tourne parfaitement même avec le versions les plus récentes de PHP).

- Supprimer toutes les variables relatives à PHP et PEAR dans Panneau de configuration\système\Avancé\Variables d'environnement et reporter ces variables dans un fichier symfony10.cmd. Votre fichier devrait ressembler à celui ci :

REM Ajoute les commandes php de wamp
SET PHPCOMMANDS=C:\wamp\bin\php\php5.2.9-1
SET PHP_PEAR_SYSCONF_DIR=C:\wamp\bin\php\php5.2.9-1
SET PHP_PEAR_INSTALL_DIR=C:\wamp\bin\php\php5.2.9-1\pear
SET PHP_PEAR_DOC_DIR=C:\wamp\bin\php\php5.2.9-1\docs
SET PHP_PEAR_BIN_DIR=C:\wamp\bin\php\php5.2.9-1
SET PHP_PEAR_DATA_DIR=C:\wamp\bin\php\php5.2.9-1\data
SET PHP_PEAR_PHP_BIN=C:\wamp\bin\php\php5.2.9-1\.\php.exe
SET PHP_PEAR_TEST_DIR=C:\wamp\bin\php\php5.2.9-1\tests

SET OLDPATH=%PATH%
SET PATH=%PHPCOMMANDS%;%OLDPATH%

- Installer XAMPP -> Initialiser PEAR -> Installer Symfony 1.2

- Nettoyer à nouveau les variables d'environnement Windows et créer un fichier symfony12.cmd :

REM Ajoute les commandes php de xampp
SET PHPCOMMANDS=C:\xampp\php
SET PHP_PEAR_SYSCONF_DIR=C:\xampp\php
SET PHP_PEAR_INSTALL_DIR=C:\xampp\php\pear
SET PHP_PEAR_DOC_DIR=C:\xampp\php\docs
SET PHP_PEAR_BIN_DIR=C:\xampp\php
SET PHP_PEAR_DATA_DIR=C:\xampp\php\data
SET PHP_PEAR_PHP_BIN=C:\xampp\php\.\php.exe
SET PHP_PEAR_TEST_DIR=C:\xampp\php\tests

SET OLDPATH=%PATH%
SET PATH=%PHPCOMMANDS%;%OLDPATH%

Voilà, il ne vous reste plus qu'à lancer la commande correspondant à la version de Symfony que vous souhaitez utiliser. 

2 jours que je me prends la tête avec des problèmes d'encodage sur mes blogs... Le premier problème vient de l'encodage de ma base de données MySQL. Je n'ai pas encodé mes tables en utf8 alors que c'est le jeu de caractère utilisé par sfSimpleBlog... Je m'en suis rapidement rendu compte, mais comme apparemment Symfony réencode les données issues de la base, le résultat était parfait et j'ai laissé courir. Erreur... ON NE RIGOLE PAS AVEC L'ENCODAGE ou on s'en mord très vite les doigts. 

Ensuite conceptuellement sfSimpleBlog n'est pas exempt de défauts. Il est bizarre qu'une version "url friendly" de chaque titre de post soit enregistrée dans la base de données alors que ce n'est pas le cas pour les tags. Du coup pour peu que le développeur qui choisit d'installer ce plugin ne réfléchisse pas beaucoup, il s'en mord très vite les doigts (j'avais plus de doigts j'ai attaqué les moignons).

Et enfin il existe un problème récurrent avec php, l'utilisation du couple de fonctions urlencode/urldecode fait disparaitre l'encodage unicode. Visiblement le système de routing de Symfony ne corrige pas ce problème. Et le développeur qui n'a plus ni doigts, ni moignons, verse une petite larme...

Je crois que le jour où je serais parfaitement à l'aise avec l'encodage de caractères le développement web n'aura plus aucun charme pour moi.

Jusqu'à présent les utilisateurs anglophobes de Symfony n'ont que 2 façons d'échanger à propos de leur framework préféré :

• la mailing-list  

• le cannal IRC fr  

Une communauté francophone devrait rapidement voir le jour avec comme support un portail ( ce portail devrait être accessible à l'url www.symfony.fr ).

L'idée me plaît beaucoup. Je suis parfaitement à l'aise pour lire l'anglais mais quand il s'agit de m'exprimer c'est autre chose... Je ne me vois même pas faire un rapport de bugs de peur de ne pas pouvoir orienter les développeurs correctement...

Donc avoir un réel espace d'échange francophone je suis pour. Pour autant je ne suis pas totalement convaincu du résultat. Lorsque j'ai débuté le développement avec Symfony j'ai été un peu désarçonné par la mutiplicité des ressources disponibles (forum+wiki+mailing list+documentation officielle+Symfony cookbook+snippets repository+canaux irc+tutoriel Askeet). Si ce nouveau portail permet réellement une meilleure collaboration des utilisateurs francophones expérimentés et une meilleure orientation des utilisateurs débutants, super. Mais si nous ne parvenons qu'à mettre en ligne quelques ressources supplémentaires, ce sera une belle perte de temps...

Pour l'instant des idées sont échangées à propos de la création de ce portail sur le groupe Google suivant :

• symfony-fr-portail

Ce blog est basé sur le plugin sfSimpleBlog. Ce plugin offre les fonctionnalités de base d'un blog, sans fioriture. Personnellement ça me convient parfaitement.

Je n'étais pas décidé à passer des heures sur le template de mon blog, j'ai donc opté pour le minimum syndical : 1 image pour le logo, 1 image pour le background, 5 images pour les titres des menus, 1 police différente du template par défault et 1 couleur différente pour les liens.

La mise en place tout de même n'a pas été évidente. Certains éléments du layout par défault ne sont pas isolables avec des sélecteurs css. Il a donc fallu que je retouche aux templates du plugin.

Le templating n'est pas vraiment un point fort de Symfony. La logique est assez facile à comprendre mais à l'utilisation ça n'est pas très agrèable. Les fichiers web (images, css, javascript) sont isolés dans un répertoire spécifique. Les templates (nom donné à tous les fragments html) sont dispersés dans toutes l'application. Et tout incite à la multiplication de ces fragments (pour la réutilisabilité, pour isoler les fragments ne nécéssitant pas de logique métier pour être généré...). Au final on se retrouve très souvent à travailler un design avec 10 fichiers html ouverts et un seul fichier css (parce que ça n'est pas simple de travailler avec 10 fichiers html et 10 feuilles de style...), alors que ce que j'apprécie c'est exactement l'inverse. 

Mais ce défault majeur a évidement son pendant positif. Le framework est construit autours d'une architecture en cascade. Tous les éléments définis à un niveau d'une application sont redéfinissables au niveau inférieur. Le système de plugins de fait pas exception. Véritable sur-couche, il est facile de réécrire les templates d'un plugin ou d'étendre son comportement. C'est ce que j'ai fait sur ce blog. J'ai redéfini à l'intérieur de mon application l'ensemble des templates de la colonne droite et le layout principal.

Bon le résultat n'est pas grandiose... je ne suis pas graphiste mais ça fait plaisir de se sentir chez soi :)

• sfSimpleBlog

• La vue avec Symfony