Bonjour à tous !

Et oui, me revoilà après plusieurs mois sans post. Il faut dire qu'entre le boulot, les cours du soir et le sport, le temps est assez limité pour le reste ! Mais bon, je profite d'avoir un petit moment pour vous faire partager une expérience qui, pour beaucoup, semble évidente mais à laquelle on ne pense pas suffisament : Optimiser une requête Doctrine

Dans l'admin generator, on pense souvent à modifier la requête de sélection de Doctrine (pour l'affichage de la liste) en intégrant des leftJoin ou innerJoin (ceux qui ne le font pas encore, pensez-y !).

Je le fais toujours mais dans mes modules de frontend (en général, de l'affichage de données en base), je ne le faisais pas (sans doute parce que mes requête étaient simples).
Sur un projet, j'ai pu découvrir le bénéfice non négligeable d'optimiser la requête d'affichage des données, que ce soit au niveau du nombre de requêtes mais également au niveau du temps d'affichage de la page (plus précisément, au niveau du temps de calcul de l'actin d'index).

Pour que ce soit plus parlant, regardons quelques printscreen :
- utilisation de la requête générée par Doctirne




- utilisation d'une requête (et d'une action) optimisée




Voilà, je pense que c'est suffisamment parlant non ?
Pour information, j'ai rafraichi plusieurs fois la page afin d'obtenir des valeurs lorsque le cache est utilisé.

En non optimisé, Doctrine effectue 129 requêtes (3.98ms) et une fois optimisée, UNE seule requête est effectuée (0.01ms).
Le temps étant en ms, c'est assez négligeable certes mais pour une base de données énorme avec beaucoup d'accès, le ratio est de 400 ! De plus, le fait d'avoir un certain nombre de requêtes (hydratation de base Objet) rentre en compte dans le temps de calcul de l'action dont elle dépend et ici, le ratio est encore important 6 !

Afin de vous ouvrir un peu plus les yeux, il faut voir le schema de la base afin de comprendre la "complexité" des relations : schema.yml
Voici également la requête optimisée (je ne sélectionne que les données nécessaires et j'hydrate en array afin de limite les ressources nécessaires et sachant qu'il s'agit d'affichage de données, c'est parfait !) : TacheTable.class.php
Et pour finir, je vous propose les deux actions (en premier, l'action optimisée avec l'hydratation array et en second, l'ancienne action avec l'hydratation objet) : actions.class.php

Voilà, je pense que c'est assez explicite, j'obtiens exactement le même rendu avec l'une ou l'autre des actions et des requêtes et j'avoue avoir été vraiment impressionné sur ce coup là !
Morale : toujours chercher à optimiser ses requêtes !

Quel développeur symfony ne s'est pas posé cette question : comment internationaliser le filtre 'is_empty' de l'admin generator ?

Vous trouverez plusieurs solutions sur le net mais il y en a une que j'apprécie fortement et je vais vous en faire profiter :
- ajoutez la fonction privée __($string) dans le fichier /path_du_projet/lib/filter/doctrine/BaseFormFilterDoctrine.class.php :

  protected function __($string) {
    sfProjectConfiguration::getActive()->loadHelpers(array('I18N'));
    return __($string, array(), 'sf_admin');
  }

- dans chaque fichier des filtres de votre modèle (/path_du_projet/lib/filter/doctrine/ModelFormFilter.class.php) :

$this->widgetSchema['champ']->setOption('empty_label', $this->__('is empty'));

- ajoutez dans le fichier /path_du_projet/apps/votre_app/i18n/sf_admin.fr.xml (si vous n'utilisez pas ce fichier, n'hésitez pas à le récupérer dans le répertoire /path_de_symfony/plugins/sfDoctrinePlugin/i18n/sf_admin.fr.xml) :

      <trans-unit>
        <source>is empty</source>
        <target>est vide</target>
      </trans-unit>

Cette méthode fonctionne pour toutes les traductions nécessaires et peut servir un peu partout.

Il fallait bien que ça arrive un jour ou l'autre : j'ai créé mon premier plugin !!!

J'ai passé une partie de la semaine dernière à travailler sur du SSO (Single Sign On) automatique. En gros, je cherche à créer pour mon Intranet une authentification automatique pour les utilisateurs sans qu'ils aient besoin de rentrer leur login et leur mot de passe. C'est à l'application de retrouver le login de Windows puis de vérifier sur l'Active Directory si celui-ci est autorisé à accéder au contenu.
Après beaucoup de recherches, j'ai décidé de me diriger sur l'utilisation du protocole NTLM (de Microchiof ... ) pour ne pas trop me prendre la tête.

Comme je l'ai indiqué, l'authentification est basée sur un annuaire Active Directory. On peut donc soit se connecter automatiquement (paramètre de l'application), soit insérer son login et son mot de passe dans un formulaire de saisie.

Le plugin est assez simple et léger, il embarque deux librairies externes (NTLM et adLDAP) et ne possède qu'un seul module (vjAuthLogin).

L'installation est très simple, il faut ensuite modifié quelques fichiers de l'application ainsi que pour l'utilisation d'IE, quelques clés de registres à intégrer.

La documentation se trouve sur le site de symfony dans la page du plugin : vjAuthPlugin

N'hésitez pas à me renvoyer des feedbacks si vous le testez. Etant mon premier, je n'ai sans doute pas fait tout comme il fallait :)