Découvrez Diem, un CMS. Ou plutôt, un CMF pour Content Management Framework. Open Source, le projet affiche fièrement sa ligne de conduite : conçu pour les sites – pas si simples. Basé sur le framework symfony 1.4 (au lieu de la 1.1 dans la précédente mouture), Diem va en effet vous permettre de mettre en place vos systèmes de gestion de contenu totalement sur mesure. Un effort a été fait sur l’interface d’administration, le SEO, l’édition inline, les outils pour développeurs, les performances… Bref, un beau projet qui promet.

Si vous êtes à la recherche d’une solution de gestion de contenu parfaitement calquée sur vos besoins spécifiques, vous devriez faire un tour du côté de Diem et des modules fournis.

Site officiel

NetBeans 6.8 vient de sortir en version stable comme l’annonçait précédemment un sympathique lecteur / commentateur (rev). Pour fêter cela, je viens de passer une petite heure à créer un thème aux couleurs utilisées par Sensio Labs pour les snippets made in symfony (exemple). J’ai adapté les couleurs pour le code PHP, HTML, YAML, SQL, JavaScript et XML.

Télécharger maintenant !

Pourquoi ?

Pourquoi donc me suis-je mis à délaisser Eclipse au profit de NetBeans ? Ma motivation remonte à l’annonce d’un début d’intégration de symfony au sein de l’IDE, c’est à dire il n’y a pas trop longtemps. J’avais eu l’occasion de tester NetBeans il y a 3 ou 4 ans, pour le comparer à Eclipse qui me semblait alors plus puissant, notamment pour certains plugins que j’utilisais.

Aujourd’hui, dans un projet qui contient de très nombreux fichiers (symfony) NetBeans se montre subjectivement plus rapide pour autocompléter et documenter les appels de méthodes. Je regrette le non-support des interfaces fluent sur plusieurs lignes, mais bon… Au niveau de l’intégration du framework, je ne sais pas encore si j’arriverai à abandonner mon terminal et son ZSH, mais il y a du mieux au sein de l’IDE :

Symfony via le menu contextuel

Autre résultat de cette intégration fort intéressant, la possibilité de switcher entre une vue et son contrôleur :

Passer d'un contrôleur à la vue associée

Pour ne pas dérouter les utilisateurs d’Eclipse, un mapping du clavier de l’IDE rival est disponible ; on notera également un mapping Emacs redoutable ! Par défaut, les raccourcis claviers sous MacOSX sont désastreux, avec des inversions entre les touches SHIFT, CTRL et Pomme. Fort heureusement NetBeans propose une configuration extrêmement poussée du clavier, je vous laisse découvrir les différentes assignations possibles. Enfin, petit agrément appréciable au quotidien que je découvre avec NetBeans, l’affichage dans la marge des modifications effectuées depuis la dernière version. Un exemple visuel :

Une marge qui fait la diff' !

En passant le curseur sur cette marge, l’IDE nous indique les modifications effectuées. L’équivalent sous Eclipse est amplement moins pratique,

Le mot de la fin

Je n’ai sûrement pas encore fait le tour des avantages (et des inconvénients) de NetBeans, et voilà un bon prétexte pour continuer à pousser son utilisation plus loin. La première semaine d’utilisation me donne pleinement satisfaction après un petit moment passé dans les préférences pour personnaliser la coloration syntaxique, les raccourcis claviers et le formatage automatique.

Piwam est historiquement basé sur Propel. Parce qu’il est né avec symfony 1.0, et qu’à ce moment là, il « fallait » apprendre Propel, très en vogue.Mais la donne a changé, Doctrine est devenu l’ORM par défaut dans symfony, l’avenir du projet est bien plus certain que celui de Propel. J’ai donc décidé de changer d’ORM pour Piwam, et j’ai décidé de vous faire part de cette excitante expérience.

Les gros changements

Au premier abord, la logique de Doctrine déroute. La sélection des enregistrements se fait avec une approche de « méta-langage », le DQL, à l’instar de ce qui se fait dans Hibernate (pour les Javatistes) et le HQL. Adepte de l’approche 100% objet, j’y trouvais là un premier reproche par rapport à un Propel clair et loin de tout langage SQL. Ainsi pour sélectionner une liste d’utilisateurs qui sont dans le groupe « 42″, on procèdera de la sorte :

class UserTable extends Doctrine_Table
{
  /**
   * Retrieve users who belong to the group $id
   *
   * @param integer $id
   * @return array of User
   */
  public static function getForGroupId($id)
  {
    $q = Doctrine_Query::create()
           ->from('Member m')
           ->where('m.group_id = ?', $id);

    return $q->execute();
  }
}

Finalement, cette manière de faire rappelle les habitudes prises en HQL et s’avèrent agréables à utiliser en PHP.  On notera par ailleurs que la table hérite tout de suite de Doctrine_Table ; nous n’avons plus accès aux méthodes statiques auto-générées par Propel (doSelect(), doCount()…). À vous de les ré-implémenter !

À l’instar de Propel, Doctrine propose de méthode pour hydrater les résultats : sous forme d’objets ou sous forme de tableaux. Remplacez alors l’appel à ->execute() par ->fetchArray(). Un benchmark réalisé sur AmicalementWeb présente des gains de performances non négligeables pour la seconde méthode. Dans le cadre de Piwam, je suis néanmoins resté sur ma gestion d’objets, pour éviter d’avoir à réécrire les templates, et parce que les performances sous Piwam ne sont pas un point critique.

Les trucs cools de Doctrine

On s’aperçoit très vite qu’il y a plein de choses super cools dans Doctrine. Je veux parler par exemple de l’export / import ultra-facilité dans différents formats (XML, YML, Json), des post- et pré- méthodes, ou encore un comportement géographique ! La possibilité d’ajouter des plugins nous confortent encore plus quant au choix d’avoir abandonné Propel ! L’intégration à symfony est elle aussi bien poussée, à tel point qu’il est possible d’exécuter des requêtes DQL directement depuis la ligne de commande via la tâche doctrine:dql.

Ma méthodologie

Plutôt que de « bidouiller » le fichier schema.yml de Propel, j’ai décidé de laisser Doctrine générer un nouveau schema.yml à partir de la structure actuelle de la base de donnée.
> php symfony doctrine:build-schema
Après avoir renommé les noms des relations et supprimé les relations à double sens qui alourdissaient inutilement la lecture et créaient une trop forte dépendance entre les classes, en avant pour la génération des fichiers Model. Tout comme pour Propel, on dispose de tâches puissantes et explicites, avec la possibilité (youpi !) de regénérer uniquement certaines classes du modèle.

Vous remarquerez que le nom des classes générées a changé. Du moins, l’équivalent des classes « Peer » de Propel, maintenant suffixées par « Table » comme dans mon exemple. Vous pouvez envisager une session de chercher/remplacer automatisée dans votre liste de contrôleurs, c’est ce que j’ai fais et c’est plutôt rapide et efficace. J’ai opté pour ce choix afin de rester dans la « logique » Doctrine. L’autre solution ? Renommer ces classes avec les anciens noms donnés par Propel.

Si votre application comporte très majoritairement des requêtes basiques de sélection / insertion / mise à jour, la ré-écriture des méthodes est relativement rapide. MAIS, c’est relativement énervant de se voir refaire un travail déjà effectué, et assez peu automatisable, en créant de surcroît un nouveau risque d’erreur.

Note d’auteur

Je ne sais pas si c’est un fait ou un hasard, mais en cherchant de la documentation sur Doctrine, je suis tombé sur pléthore de sites montrant des exemples de requêtes intégrés… dans leur contrôleur. Je ne me souviens pas avoir vu autant d’horreurs en faisant des recherches Propeliennes !

Le soucis des formulaires

Ne prenez pas peur, c’est un tout petit soucis. Et oui, pour peu que vos formulaires intègrent de la logique « Propel » (vérification d’unicité, listes de sélections générés via des Criteria, etc.) vous allez devoir mettre à jour chacun de ces formulaires. C’est en qui me concerne la partie que je considère comme la plus énervante.

Mon avis

Pour conclure sur ce bref retour, qui s’est fait dans un cadre propre à un et un seul projet (Piwam), je dirais que switcher de Propel vers Doctrine n’est pas anodin mais peut s’opérer sans douleur. Avoir des tests en place permet de s’assurer du fonctionnement une fois la procédure achevée. Je recommanderais à ceux qui veulent opérer de la sorte sur un projet conséquent de procéder par itérations, et d’intégrer chaque classe Propel les unes après les autres, quitte à se retrouver avec un mélange improbable de classes. Bien avant cela, je pense que la migration vers Doctrine est loin d’être systématique et que Propel n’est pas mort. Comprenez par là que si votre estimation du temps nécessaire pour migrer est bien supérieur à votre temps disponible, n’hésitez même pas et restez Propeliste. Au pire, commencez une nouvelle branche de votre projet avec Doctrine.

En revanche, pour de gros projets débutés parfois sous symfony 1.0, qui ont effectué une mise à jour vers 1.1, puis 1.2, il va falloir s’assurer que TOUT a bien été mis en place pour éviter que la migration tourne au désastre. Symfony 1.3 assure en effet la rétro-compatibilité, mais la mouture 1.4 ne pardonne pas (clone de la 1.3, mais les éléments deprecated sont supprimés).

C’est alors là que le billet devient intéressant, puisque je vous annonce que Fabien Potencier a eu l’idée de mettre en place une tâche « project:validate« , qui effectue une multitude de vérifications pour que tout se passe en douceur. À essayer avec la dernière version !

La version alpha de symfony 1.3 a été présentée récemment. Comme prévu, un bon lot de nouveautés fait son apparition, mais quelles sont elles ? Je vous propose un petit résumé sauce Ze-Technology, avec les nouveautés principales, basé sur la liste mentionnée sur le site officiel.

• SwiftMailer 4.1 est maintenant la bibliothèque d’ e-mailing par défaut
• escaping_strategy est mis à true par défaut, de même que csrf_secret
• Lorsque le label d’un champ de formulaire est auto-généré, le suffixe _id est retiré. Le champ author_id aura ainsi pour label « Author »
• De nouveaux chouettes widgets I18n pour faciliter le choix de la langue, de la devise, du pays et du fuseau horaire par l’utilisateur.
• La méthode sfForm::useFields() permet d’indiquer rapidement les seuls champs d’un formulaire à afficher.
• Possibilité de lancer uniquement les tests qui ont échoué
• Possibilité de reconstruire partiellement un schema de BDD avec Doctrine, en spécifiant les modèles associés
• Possibilité de supprimer des fichiers des classes de modèle en CLI

Toutes les nouveautés sont plutôt pertinentes, les 2 derniers points font partie des choses qui vont rendre la maintenance du schema de données encore plus agréable. N’hésitez pas à consulter la liste complète pour plus d’exemples et une liste exhaustive.

Si vous êtes utilisateur du framework symfony, vous avez sûrement déjà du lire les centaines « d’astuces » à connaître pour personnaliser les pages d’erreur 404, changer le nom du cookie, gérer les fichiers logs en production… mais connaissez-vous tous ces points, et surtout les avez vous retenus ? Non, n’ouvrez pas votre livre de référence pour bachoter, symfony-check s’en charge pour vous.

Cette excellente initiative retrace les différents points à vérifier avant de lancer votre application symfony en production. Le tout classé par catégorie. Et si vous ne savez pas comment fixer un point particulier, le site web vous guide pour y parvenir et parfaire ainsi votre projet. http://symfony-check.org

En attendant, vous pourrez prochainement retrouver en ligne mon article sur l’utilisation de XDebug et du debugger Eclipse, publié il y a quelques mois.

Sommaire du magazine

Sismo est un outil d’intégration continue développé par Sensio Labs (vous savez, symfony…). L’intégration continue, c’est la possibilité de détecter tout ce qui ne va pas au fil des versions. Du vert ou du rouge, ça passe ou ça ne passe pas, Sismo présente une interface très simple permettant de contrôler le comportement de ses projets au fil des releases. Fabien Potencier a annoncé sur le groupe de discussion « symfony developers« , une éventuelle disponibilité de ce projet libre à la fin du mois de juin.

Une démonstration en ligne du produit est disponible sur http://ci.symfony-project.org. Hâte d’essayer cette alternative à Xinc et consorts.