Tout en haut de votre(vos) schema.yml, ajoutez les lignes suivantes:

options:
  collate: utf8_unicode_ci
  charset: utf8

Malheureusement, les fichiers schema.yml des plugins ne seront pas affecté car il faut que ce bout de code soit répété en haut de chaque schema.yml.

Heureusement, [MA]Pascal m’a donné une astuce de sioux qui permet de résoudre ce problème. Il suffit d’utiliser l’héritage des tables dans Doctrine. Par exemple, voici ce que ca donnerait pour le plugin sfDoctrineGuardPlugin:

sfGuardGroupUtf8:
  inheritance:  { extends: sfGuardGroup, type: simple }
  options:      { collate: utf8_unicode_ci, charset: utf8 }

sfGuardGroupPermissionUtf8:
  inheritance:  { extends: sfGuardGroupPermission, type: simple }
  options:      { collate: utf8_unicode_ci, charset: utf8 }

sfGuardPermissionUtf8:
  inheritance:  { extends: sfGuardPermission, type: simple }
  options:      { collate: utf8_unicode_ci, charset: utf8 }

sfGuardRememberKeyUtf8:
  inheritance:  { extends: sfGuardRememberKey, type: simple }
  options:      { collate: utf8_unicode_ci, charset: utf8 }

sfGuardUserUtf8:
  inheritance:  { extends: sfGuardUser, type: simple }
  options:      { collate: utf8_unicode_ci, charset: utf8 }

sfGuardUserGroupUtf8:
  inheritance:  { extends: sfGuardUserGroup, type: simple }
  options:      { collate: utf8_unicode_ci, charset: utf8 }

sfGuardUserPermissionUtf8:
  inheritance:  { extends: sfGuardUserPermission, type: simple }
  options:      { collate: utf8_unicode_ci, charset: utf8 }

[MA]Pascal me disait même qu’il étendait les fonctionnalités des plugins de cette façon, mais je ne sais pas dans quelle mesure on peut étendre une classe d’un plugin et espérer que cela fonctionne encore…

[MA]Pascal, si tu passes par là et si tu veux bien nous expliquer :p

Contrairement à d’autres framework qui réinventent la roue, symfony s’appuie sur des librairies externes qui ont fait leur preuve. C’est précisément le cas pour l’ORM.

Dans ses premières versions, symfony n’intégrait que Propel et le changement d’ORM était relativement difficile, malgré l’existence d’un plugin Doctrine, car certains outils du framework, notament l’Admin Generator, s’appuyait uniquement sur Propel.

Depuis la version 1.1, Propel est un plugin et ne fait plus parti du core de symfony. Depuis la version 1.2, l’Admin Generator peut utiliser indifféremment Propel ou Doctrine. C’est une très bonne nouvelle pour la communauté. Du coup, chaque développeur peut choisir l’ORM qui lui convient le mieux… mais aussi se poser la question fatidique « Quel est le meilleur ORM ? »

Cette question, je me la suis, moi-même posée.

Pour y répondre, il faut prendre en compte plusieurs points (liste non exhaustive et non ordonnée):

• la facilité d’apprentissage
• la rapidité de développement
• les capacités offertes par l’ORM (vs les besoins qu’on a)
• la rapidité d’exécution

Et c’est sur ce dernier point (pas forcément le plus important) que je suis me suis penché car j’ai lu à divers endroits que Doctrine était sacrément plus lent que Propel.

J’ai donc commencé à faire quelques benchmark. Ou plutôt une « plateforme » de benchmark qui n’attend que vous pour être complétée. En effet:

• étant débutant avec symfony, propel et doctrine, je ne peux garantir que tout soit bien optimisé, j’ai donc besoin de l’aide de demi-dieu de symfony et/ou propel et/ou doctrine
• à plusieurs nous arriverons mieux à faire un benchmark suffisamment complet et représentatif du type de requête utilisé dans un site web.

J’ai donc publié le code sur googlecode et l’accès au svn vous sera ouvert sur simple demande (mail/msn/gtalk de contact en haut à droite de ce blog).

url du projet: http://benchsymfonyorm.googlecode.com

Le projet contient un répertoire pour chaque ORM avec, à l’intérieur, un projet symfony.

J’ai séparé chaque ORM dans un projet différent car l’utilisation de Propel et Doctrine pourrait fausser les résultats.

Les benchs sont tous dans des task afin que le serveur web n’influe pas sur les résultats.

Les remarques constructives sont évidemment les bienvenues. Les trolls velus totalement interdits et carrément supprimés des commentaires s’ils montrent le bout de leur nez.

Comme dit plus haut, je ne prétends pas avoir faire un système parfait et les améliorations sont donc les bienvenues… en fait, c’est un peu le but de ce projet :)

• CakePHP, dont les numéros de version à rallonge sont une source de franche poilade pour tout mon boulot (la dernière version stable est la 1.1.15.5144). J’avais essayé, il y a quelques mois, de dompter la bête… sans succès.
• CodeIgniter, comme CakePHP, j’avais essayé, sans succès, de comprendre ce framework.
• Jelix, lancé par Laurent Jouanneau, un framework français qui à l’air plutot interressant mais dont la documentation est pauvre et incomplète alors que la version 1.0 beta2.1 vient de sortir.
• Symfony, développé par une société française… en anglais. la communauté est assez grande. Tout comme ses camarades CakePHP et CodeIgniter, impossible de comprendre quoi que ce soit à ce framework il y a quelques mois.
• PHP On Trax, développé dans l’optique de faire un Ruby On Rails avec PHP.
• Seagull, non testé
• Zend Framework, développé par Zend, The PHP Company.
• Pleins d’autres…

Je n’ai pas du tout testé Jelix à cause de sa documentation à trou. PHP On Trax non plus: je n’aime pas RoR, il y a peu de chance pour que PHP On Trax me plaise. Pas plus pour Seagull dont le nom ne m’attire pas (oui, je sais c’est pas une excuse valable… et pourtant). CakePHP, CodeIgniter et Symfony m’ont paru beaucoup trop obscurs, même leurs tutoriels mon blog en 5 minutes ne me convainquaient pas Quant à Zend Framework, je me suis plongé dedans aussitôt, j’ai aimé, j’ai développé des applications avec, y compris à mon boulot… et pourtant.

Le gros défaut de Zend Framework

Zend Framework est aux Framework PHP ce que PHP est aux langages de programmation. C’est simple, il y a une excellente documentation, une grande communauté et… on peut faire tout et n’importe quoi. De la même manière qu’on peut coder comme un porc ou comme un dieu avec PHP, on peut utiliser le ZF comme PEAR en utilisant des bibliothèques par ci, par là, on peut suivre ou non l’architecture proposée par Zend, on peut utiliser le concept MVC ou pas. Bref, le ZF est, tout comme PHP, beaucoup trop permissif pour un framework. Au final, on peut très vite se retrouver avec un site qui n’est pas du tout facile à maintenir, un comble pour un framework.

Alors on utilise quoi?

Je ne saurais rien imposer. Mais après moult tests et avec de l’acharnement, je pense avoir trouver mon bonheur avec Symfony. Le gros problème de Symfony, c’est son tutoriel de prise en main qui m’a fait fuir alors que le framework lui-même est une perle car, et ça se sent, il répond exactement à bon nombre de problématiques que l’on peut rencontrer dans des applications Web professionnelles. En lisant la documentation de Symfony^[1] (je n’ai pas fini, j’en suis au chapitre 9), j’ai rencontré des solutions à des problèmes que l’on rencontre à mon boulot. ce qui n’était pas le cas avec ZF où il fallait au contraire créer tout un tas de plugins ou d’helpers.

SF remplace ZF ?

Oui. Je projette de migrer vers Symfony l’application que j’ai commencé sur ZF au boulot (sur mon temps libre, sinon mon patron va me tuer) Je compte aussi commencer la traduction en français du manuel de SF.

Notes

[1] Que ceux qui disaient que je ne lisais pas l’anglais remarque bien que l’intégralité de ce manuel est en anglais et qu’il n’en existe pas de version française