Archives du mot-clé symfony 1.2

Mise à jour de la liste des contribution à symfony de PMSIpilot

La liste des modestes contributions à symfony a été mise à jour sur pmsipilot.org. On a trouvé deux trois petites choses 😉 et proposé pas mal de patchs.

http://www.pmsipilot.org/2010/03/25/contributions-a-symfony/

Nous utilisons maintenant symfony 1.4 qui propulsera la prochaine version majeure de nos outils de pilotage.

Migration d’un gros projet symfony de la version 1.2 à 1.4

Lors du symfony live 2010 (non, je ne vous ferais pas un compte rendu de symfony live 2010, il y en a de très bien déjà partout sur l’internet) beaucoup de personnes ont interpellées la core team au sujet des problèmes de compatibilité descendante avec symfony.

Récemment, dans ma société, j’ai migré un projet de symfony 1.2 à 1.4. Pas un petit, 220 000 lignes de code (hors symfony, code généré et plugins). A vrai dire, vu comme ça, je me disais que ça marcherait jamais.

J’ai utilisé les documents suivants :

J’ai commencé par mettre à jour lib/vendor/symfony en 1.3 et fait tourner la tache ./symfony project:upgrade1.3.  La plupart des YLM ont été modifiés correctement, tous les héritages des formulaires, la gestion de la disparition du common filter … tout ça a été fait automatiquement pour moi ! project:validate m’a ensuite indiqué la liste des méthodes et fonctions dépréciées. Un peu de surcharge de méthodes, de récupération de vieux helpers, et voila. En quelques heures le projet était d’équerre. Ceci fait, j’ai ensuite migré vers la 1.4.

Le plus pénible à gérer fut la fin de la gestion des tableaux dans les méthodes de sfParameterHolder. project:validate a bien indiqué les classes des contrôleurs à changer mais n’a pas pu chercher dans les autres classes les (maintenant) mauvaises utilisations des tableaux. Pour ça, les tests ont bien aidé, et le reste de l’équipe à résolu quelques occurrence de ce problème les jours suivant.

Pour ma part, des migrations comme ça j’en veux bien tout le temps !

Je travaille avec symfony depuis la version 0.6.3, et je ne l’ai jamais trouvé aussi facile à utiliser.

Au boulot, moi, j’utilise Facebook !

Mais c’est pour améliorer les performances de nos applications grâce à un plugin développé par un de mes brillants collègues : elXHProfPlugin.

Mon équipe l’utilise sans douleurs depuis plusieurs semaines et avec de nombreux gains à la clef. C’est la démocratisation du profiling qui, jusqu’alors, était plus réservé aux CP techniques tant sa mise en place, avec xdebug, était pénible.

Plus d’informations sur le .org de PMSipilot.

Faire des liens entre applications dans un projet symfony, revue des trois méthodes proposées

Avec Symfony 1.0, faire un lien d’une application vers une autre application représentait un vrai challenge. La solution la moins horrible consistait à parser le fichier routing.yml et faire 10 000 bidouilles que je vous cacherais ici. Dans Symfony 1.0 le contexte était géré via le pattern singleton dans une variable statique ; impossible d’en instancier un autre. De plus, le système de route était trop couplé au framework pour l’utiliser plus indépendamment.

Ces deux évolutions (instanciation de plusieurs contextes possible et découplage du système de routing) en symfony 1.2 on permis enfin de gérer des liens inter application proprement

A ma connaissance il y a trois façons aujourd’hui de faire des liens entre différentes applications dans un même projet Symfony. Dans ces trois cas, on sent que les développeurs ont cherché à répondre à  ce même besoin selon des contraintes qui leurs étaient propres.

Lire la suite

Obtenir la liste des autorisations de votre projet Symfony : le plugin omCredentialsMap est disponible

Suite à la publication d’une tache permettant de lister les autorisations dans un projet symfony, j’ai packagé l’ensemble dans un plugin et libéré ça dans le repository de Symfony.

C’est disponible ici : http://www.symfony-project.org/plugins/omCredentialsMapPlugin

Exemple de sortie du plugin :

 pmsipilot  admin           anonymiseur : admin_mco_donnees
 pmsipilot  admin                atypie : acces_dossiers_medicaux AND acces_mco
 pmsipilot  admin    baseMessageAccueil : acces_mco
 pmsipilot  admin             coherence : admin_mco_donnees
 pmsipilot  admin                 datim : acces_dossiers_medicaux AND acces_mco
 pmsipilot  admin             detailRss : acces_dossiers_medicaux AND acces_mco
   portail  accueil               index : OFF
   portail  accueil            saveData : OFF
   portail  default  checkcalculencours : OFF

Les colonnes représentent respectivement : l’application, le module, l’action et les credentials associés. Merci de consulter le REAME pour plus d’infos. Tout retour est le bienvenu.

Obtenir la liste des autorisations de votre projet Symfony

Dans le cadre de mon boulot, voici une petite tâche Symfony (1.2), développée dans le but de vous afficher une liste de tous les modules/actions ainsi que les credentials symfony associés.

J’ai fait ça rapidement mais cela semble pas trop mal marcher. La sortie vous indique également les droits correspondants aux modules associés à vos applications. Toutefois, seul les modules activés dans tous les environnements (la section all de settings.yml) seront découverts. Cela peut être utile pour découvrir les actions non protégés et prévenir le « url hacking ».

Pour la faire fonctionner, il suffit de déposer le fichier php contenu dans le zip attaché à cet article dans le repertoire lib/task de votre projet Symfony 1.2 et l’appeler en ligne de commande.

credentialMapTask.class.php

Utiliser le système d’évènements de Symfony

Le système d’évènements de Symfony est une avancée particulièrement intéressante dans le framework. Toutefois, la documentation officielle est un peu spartiate sur le domaine. Voici donc un exemple pratique plus didactique pour utiliser les évènements.

Le système d’évènement de Symfony est basé sur le motif de programmation observer qui est un grand classique du genre.

Tout d’abord, il faut enregistrer le listener. On peut le faire à peu près n’importe ou, par exemple dans le preExecute du code d’un contrôleur, ou plus globalement dans le fichier config/ProjectConfiguration.class.php qui va gérer la configuration globale de votre projet.

    
class ProjectConfiguration extends sfProjectConfiguration
{
  public function setup()
  {
    // listener
    if (!sfConfig::get('already_event_connected', false))
    {
      $this->getEventDispatcher()->connect('a.name', 'aclass::dosomething');
      sfConfig::set('already_event_connected', true);
    }
  }
}

Ce code vous assure que le listener sera enregistré une unique fois. En effet, si il est enregistré deux fois, a chaque notification il sera exécuté deux fois ….

Ensuite, n’importe ou dans votre code, vous pouvez « lancer » cet évènement. Par exemple, dans le code d’un contrôleur.

    // notification
    sfContext::getInstance()->getEventDispatcher()->notify(new sfEvent(get_class($this), 'a.name', 
    array(
      'a_var' => $foo,
      'another_var' => $bar,
    )));

La fonction de callback, ici une méthode statique, récupère un objet sfEvent en paramètre. Via ce dernier, on a également accès aux variables passées lors de la notification de l’évènement.

// dans la classe aclass
public static function dosomething (sfEvent $event)
{
  $foo = $event['a_var'];
  $bar = $event['another_var'];
  // code
}

Et voilà, à vous de jouer.

Astuce symfony : changer le chemin du cookie de session de symfony

Symfony va stocker les informations de l’utilisateur courant dans un cookie de session avec / comme chemin. Si vous avez plusieurs applications symfony sur le même serveur et si celles ci sont gérées via des alias apache et non des virtual host, cela peut poser problème. En effet, une fois loggué sur une application, vous pouvez naviguer sur une autre avec tous les crédentials et autre variables de session définies sur cette première application.

Pour changer cela, voici comment je procède. Il faut simplement ajouter un fichier config/factories.yml et y insérer les lignes suivantes :

all:
  storage:
    class: sfSessionStorage
    param:
      session_cookie_path: 

omCrossAppUrlPlugin (liens inter applications dans Symfony) est disponible sur le repository de Symfony

Pour info, j’ai packagé un petit helper Symfony pour le dépot de plugins du projet. Il permet simplement de faire des liens entre applications d’un même projet. Il est compatible Symfony 1.2 uniquement.

Merci de vos retours si vous rencontrez des soucis avec ce helper.

http://www.symfony-project.org/plugins/omCrossAppUrlPlugin