Archives mensuelles : mai 2008

The IT Crownd – une série britannique pour geek vraiment sympa !

Tout de même, le « héros » porte un t-shirt RTFM dans le premier épisode …. énorme !

(via le bistrot du coin)

Publicités

Symfony : comment gérer l’apparition du panneau de connexion dans les zones rafraichies en Ajax

Symfony permet assez facilement de mettre en œuvre des appels Ajax afin de dynamiser vos écrans. Symfony permet également de facilement sécuriser tout ou partie de vos applications via de simples paramétrages. Si l’utilisateur connecté n’a pas le degré suffisant d’autorisation ou si sa session a expirée, il sera automatiquement dirigé, par le filtre de sécurité de Symfony, vers, par exemple, le panneau de login de votre application.

Un effet de bord de ces techniques est que, si l’utilisateur de votre application laisse sa session expirer, puis lance une action Ajax devant rafraichir une partie de son écran, il verra le panneau de connexion apparaitre dans cette zone : effet peu ergonomique garanti !

Voila la technique que j’utilise pour pallier à ce problème. A vrai dire, je ne sais pas si elle correspond à l’état de l’art, mais elle a l’avantage de bien fonctionner sans nécessiter de multiples interventions dans l’application.

1/ Permettre l’évaluation du Javascript dans les templates affichés via des appels AJax

Cela dépend de la librairie Javascript que vous utilisez. Par exemple, avec JQuery, il faudra préciser que le type de donnée retourné est ‘html’. Si vous utilisez les helpers Symfony, il vous faudra ajouter 'script' => true au tableau d’options passé au helper.

Cette étape n’est pas obligatoire. Elle permet toutefois de rediriger les utilisateurs en Javascript vers le panneau de connexion.


2/ Modifier le code du contrôleur gérant votre panneau de connexion

On va simplement lui dire que, si il est appelé via une requête Ajax, il n’utilise pas la vue habituelle.

Par exemple :

  /**
   * Executes login action
   *
   */
  public function executeLogin()
  {
    if($this->getRequest()->isXmlHttpRequest()) {
      $this->getResponse()->setStatusCode(401);
      return 'redirect';
    }
    /*
    end of the login action code
   */
  }

3/ Créer la vue appelée précédemment

Ici le fichier loginRedirect.php


La route correspondant à l’action de déconnexion @user_logout doit bien sur exister.

Voilà !

Et vous, que pensez vous de cette méthode ?

Enkin, un vrai projet de geek avec du potentiel

Je vous laisse découvrir la vidéo assez parlante (personnellement, j’adore le look des deux concepteurs !).


Enkin from Enkin on Vimeo.

Le concept me parait terrible, on peut imaginer des PDA ou des lunettes incorporant les images provenant d’Enkin pour s’aider à se diriger ou retrouver des amis sur la place Bellecour un soir de match (allez l’OL) o/

Check-list du démarrage d’un projet Symfony

Voici une liste de petites choses que je fais systématiquement lors du démarrage d’un projet Symfony. J’espère que cela vous sera utile.

  • conception de base : applications, modules, choix des plugins (symfony propose un grand nombre de plugins souvent d’excellente qualité, c’est un point fort du framework),
  • branchement des librairies symfony sur les répertoires lib et data via des externals svn,
  • branchement des plugins choisis sur le répertoire plugins via des externals svn,
  • choix des environnements possibles pour l’application (dev et prod viennent par défaut, l’environnement de test peut être utile pour des projets nécessitant une configuration dédiée aux tests),
  • mise en place des contrôleurs pour chaque couple application/environnement,
  • revue de la configuration pour chaque application (fichier settings.yml : escaping_strategy, etag, standard_helpers, i18n, error_reporting …)

Certains détails me semblent très importants au démarrage du projet :

  • l’escaping strategy choisi conditionne la façon dont vous allez traiter certaines de vos variables dans le code de vos templates (par exemple, les fonctions du genre is_array ne marcheront plus car vos tableaux seront des objets sfOutputEscaperArrayDecorator, de même pour les objets qui ne seront plus de la même classe). Un changement dans cette variable de configuration peut donc affecter fortement le budget de votre projet … autant être sûr du premier coup.
  • Utiliser judicieusement la directive svn:ignore afin d’éviter de commiter les fichiers indésirables ou générer par symfony (comme le cache, les classes générées par propel, les contrôleurs de dev, les logs …).
  • La configuration du fichier php.yml permettant de contrôler l’environnement de votre future application est, selon moi, un moyen simple et pratique afin d’être sûr que tout le monde travaille dans la même configuration.

Si vous avez d’autres points de ce genre, n’hésitez pas à m’en faire part.

Frameworks php pour l’entreprise

Un peu de pub pour un livre blanc Clever Age auquel j’ai contribué.

Les frameworks suivants sont abordés : CakePHP, CodeIgniter, Symfony, Zend Framewok. Avec en fin de chaque chapitre un court paragraphe indiquant dans quels cas métier utiliser ce framework et, en fin de document, un magnifique tableau QSOS permettant leur comparaison aisée.