Dans mon code, je testais l’égalité entre 2 chaines de caractères ("0000000123" et "000123") et ça me retournait true alors que j’attendais false.

En réfléchissant 2 minutes, voici ce que php effectue:

1. est-ce que la chaine A est identique à la chaine B: non
2. est-ce qu’en castant la chaine A et/ou B, j’arrive à trouver une égalité: oui

En effet, en castant les 2 chaines en entier, on obtient 123 et l’égalité est trouvée.

Comment faire alors pour que PHP retourne false ? En utilisant l’opérateur === qui teste non seulement l’égalité mais vérifie également qu’ils sont de même type. En réalité, ça teste l’égalité sans faire de cast. En conséquence de quoi, == est très légèrement plus lent que ===. En d’autres termes, si vous codez bien connaissez exactement le type de vos données, préférez === car il est plus rapide.

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 :)

Du coup, j’ai étendu la classe SoapClient pour que ca se reconnecte automatiquement et ca donne:

class SoapClientSessionnable extends SoapClient {
    private $wsdl;
    private $options;
 
    public function __construct($wsdl, $options = array()) {
        $this->wsdl     = $wsdl;
        $this->options  = $options;
 
        parent::__construct($wsdl, $options);
    }
 
    public function __wakeup() {
        $this->__construct($this->wsdl, $this->options);
    }
}

Bon, c’est un peu crade de rappeler le constructeur, mais je n’ai trouvé aucune méthode qui connecte le client SOAP… et puis ca a le mérite de fonctionner :)

Du coup, ca s’utilise de la même façon que le client SOAP de base:

$client = new SoapClientSessionnable(
    'http://host.com/path/to/wsdl',
    array(
        // Options
        'trace'         => 1,
        'soap_version'  => SOAP_1_1,
        ....
    )
);

Pensez quand même à mettre $client en session pour qu’il soit réutilisable dans la page suivante :)

1ère solution: installer Postfix ou Sendmail, 2 gros bazookas pour une petite mouche.

2ème solution: installer nullmailer ou installer esmtp. Chez moi, nullmailer ne marchant pas pour des raisons obscures et sombres, j’ai installé esmtp qui fonctionne à merveille.

Installation:
sudo apt-get install esmtp

Configuration:
sudo vim /etc/esmtprc

Il suffit d’indiquer un serveur smtp (celui de son FAI, par exemple), éventuellement un login/pass au besoin.

Pour l’utiliser avec gmail, en revanche, c’est un poil plus complexe, mais la documentation d’esmtp est bien faite.

Enfin, pour terminer, il suffit de faire un lien symbolique de /usr/bin/sendmail vers esmtp comme suit pour que tout fonctionne parfaitement:
sudo ln -s /usr/bin/esmtp /usr/bin/sendmail

• 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

D’après vous, en PHP, que peut bien retourner
date('d/m/Y', strtotime('0000-00-00')), hein ?

Moi, au début, je pensais que ça allait me sortir EPOCH, donc quelque chose qui aurait dû ressembler à 01/01/1970.

Que nenni! Cela affiche 30/11/1999.

Ah… il a fallu chercher… et une fois trouvé, c’est tout à fait logique.

Cela part d’un bug PHP^[1] du parser de PHP qui ne fait aucune différence entre l’année ’0′, ’00′, ’000′ ou ’0000′ et qu’il traduit inévitablement en l’an 2000. A partir de là, dans la gymnastique microprocessoromentale de PHP, il se passe les choses suivantes:

• 0000-00-00 devient 2000-00-00
• 2000-00-00 n’existe pas, il prend le 00 du mois et décide donc que c’est le mois précédent: 1999-12-00^[2]
• 1999-12-00 n’existe pas, il prend le 00 du jour et décide que c’est le jour précédent: 1999-11-30^[3]

Nous voila donc propulsé fin novembre 1999.

Conclusion:

• il vaut mieux avoir NULL plutôt que ’0000-00-00′ pour une date non utilisée
• pour avoir rapidement la fin d’un mois, il suffit de se mettre au jour 00 du mois suivant. Exemple: si on veut le 31 aout 2010, il suffit d’avoir ’2010-09-00′, strtotime se chargera de revenir un jour en arrière.

Notes

[1] Contrairement à ce qui est écrit dans le rapport de bugs et ses commentaires, le bug existe toujours en PHP5

[2] De la même manière, si vous aviez le mois 13, il passerait à janvier de l’année suivante

[3] De la même manière, si vous aviez le 32 janvier, il passerait au 1er févier et si c’était le 40 janvier, vous arriveriez au 9 février.