Problématique

Il me fallait stocker le résultat d’une question à choix multiple sans pour autant avoir à manipuler ensuite ses résultats autrement que par simple visualisation. Du coup, je voulais éviter d’avoir à créer une table pour stocker ces réponses et une table d’association avec ma table miroir de mon formulaire.

C’est là où le type array intervient. Rien de compliqué en fait, il ne fait que simplifier un traitement tout bête qui consiste à stocker un tableau php en base après sérialisation. Et qui le désérialise quand on le récupère depuis un enregistrement de la base.
Une chose de moins à faire en fait et c’est bien là ce qu’on recherche nous autres développeurs, en faire le moins possible ;)

La solution codée

Niveau code, c’est très simple. On défini notre champ dans notre schema.yml comme n’importe quel autre champ

meschoix: { type: array(1000) }

Qui donnera un champ text en mysql.

Ensuite, il suffit de modifier le formulaire obtenu pour transformer notre champ en liste de checkbox de manière très classique:

$this->widgetSchema['meschoix'] = new sfWidgetFormChoice(array(
      'choices' => array(
        '0' => 'Choix1',
        '1' => 'Choix2',
        '2' => 'Choix3',
        '3' => 'Choix4'
      ),
      'multiple' => true,
      'expanded' => true
    ));

Et puis c’est tout! Maintenant, lors de l’enregistrement, Doctrine va sérialiser le résultat de votre sélection et le stocker en base. Et quand vous peuplerez votre formulaire avec des données en base, il le désérialisera et donnera les bonnes valeurs à notre liste de checkbox.

Bien sûr, ca nous oblige à ne pas changer l’ordre des questions et les rend difficilement modifiables. Mais c’est une décision qui doit être prise en connaissance de cette limitation.

Crédit photo: http://www.flickr.com/photos/40491122@N03/3738306829/

Le modèle MVC

Le fameux Modèle Vue Controlleur. Si vous vous dites qu’à part avec un test fonctionnel (c’est à dire un test qui simule le comportement utilisateur via des clicks, avec un sfBrowser ou Selenium) ça va pas être possible de tester votre appli, c’est surement vrai ; que les tests fonctionnels ça se fait vers la fin de l’écriture de votre module, quand votre code HTML bouge plus trop c’est vrai aussi ; et que donc dans le coup vous voyez pas trop comment tester votre application avant de l’avoir finie, c’est vrai aussi.

Du M dans le C

Mais si vous vous dites tout ça, c’est qu’il y a du M dans le C. C’est à dire qu’il y a des parties de votre Modèle dans votre Controlleur et dans le coup, vous ne pouvez tester votre modèle sans votre Controlleur (et dans le coup sans la Vue aussi). C’est typiquement le cas quand vous faites quelque chose comme ça :

  public function executeIndex(sfWebRequest $request)
  {
	$objects = Doctrine::getTable('Objects')
		->createQuery('o')
		->where('o.titi=?',$titi)
		->andWhere('...')
		->orderBy('...')
		->execute();
  }

Faites pas style c’est pas vous, je vous ai vu. Pourquoi ne pas faire ça dans l’action :

  public function executeIndex(sfWebRequest $request)
  {
	$objects = Doctrine::getTable('Objects')
		->getObjectsByTiti($titi);
  }

et ça dans la classe ObjectTable :

  public function getObjectsByTiti($titi)
  {
	return Doctrine::getTable('Objects')
		->createQuery('o')
		->where('o.titi=?',$toto)
		->andWhere('...')
		->orderBy('...')
		->execute();
  }

Vous serez d’accord avec moi que le résultat est le même mais que c’est un peu plus découplé. On pourra reparler plus tard du fait que le summum serait de retourner un tableau (le fameux HYDRATE_ARRAY de Doctrine passé à la requête) dans la méthode getObjectsByTiti afin de ne pas se retrouver avec quelque chose dépendant de dépendant de l’ORM dans le controlleur (ici une Doctrine_Collection), mais ce n’est pas le sujet ici ;-)

Si c’est pareil, pourquoi c’est mieux alors ?

Parce que je vous le dis ! Oui bon d’accord. Plusieurs avantages, vous n’avez qu’un endroit à aller voir en cas de souci de logique métier : le Modèle. Mais surtout plus vous en mettrez dans le modèle (le premier que je vois écrire du HTML dans le modèle devra coder avec Wordpad), plus vous pourrez en tester ! Et plus vous écrirez de tests unitaires pour vos modèles, plus vous serez confiant dans votre code et plus votre code sera de qualité. Vos controlleurs devraient faire environ 10 lines de code, pas plus. Essayez de vous y tenir, ça vous changera la vie (mettez ce qui concerne la sessions dans votre classe myUser par exemple).

Maintenant nous pourrions écrire un test unitaire du style :

$t->ok(
  count(Doctrine::getTable('Object')->getObjectsByTiti('mogito'))>4,
  '-> Getting object by mogito returns more than 4 objects');

Ici je teste que notre méthode retourne au moins 4 objets si je lui demande un mogito.

Vers la rédemption

Si vous faites bien attention de ne pas avoir de M dans le C, vous pourrez coder toute votre logique applicative sans ouvrir un seul navigateur internet, et c’est même ce que vous devrez vous forcer à faire. Vous pouvez, voire même devez, faire marcher votre logique métier sans la moindre page web, juste en faisant tourner vos tests unitaires qui sont suffisants (et nécessaires) pour voir si votre code est bon et fait ce qu’il doit faire.

En faisant ça, vous pourrez ne vous concentrer que sur le modèle, sur le coeur de la logique métier, sans être parasité par des besoins webs (que le formulaire soit valide pour pouvoir récupérer l’objet, c’est pas le problème du modèle ça !).

Une fois que vous aurez les principales fonctions métier de codées dans votre modèle vous pourrez ensuite écrire vos controlleurs et pages web et à la fin les tests fonctionnels. Mais avant de faire ça, vous saurez qu’il y aura déjà une bonne partie de votre code qui sera écrit et testé.

Et après ?

Quand vous aurez pris l’habitude d’écrire des tests unitaires et que vous en serez devenu accrocs, vous pourrez passer au développement guidé par les tests (le TDD). Là vous écrivez avant les tests (donc en gros ce que vous attendez de votre modèle) et ensuite vous écrivez le modèle : vous serez assuré que tout votre modèle est couvert par les tests, et vous aurez écrit ce que doit faire votre modèle avant de l’avoir implémenté (c’est toujours bien de réfléchir avant de coder, sisi).

Quand vos tests commencerons à prendre du temps à s’exécuter, vous commencerez à vous intéresser à des outils d’intégration continue comme phpUnderControl ou Hudson, dont NiKo a récemment décrit l’intégration avec symfony dans un de ses articles.

Pour finir, en effet ça va vous demander plus de temps de réaliser votre application web en écrivant des tests unitaires. Comme vous êtes Freelance et que le temps c’est de l’argent, vous vous dites que vous ne le ferez pas. Oui mais quand vous aurez livré et que le client reviendra 10 fois vers vous ensuite à cause de bugs, ou que vous aurez changé quelque chose qui aura tout cassé sans que vous ne vous en rendiez compte, et que ça commencera à se savoir que ce que vous faites est buggé : vous penserez fortement à une méthode qui vous permettra d’être beaucoup plus confiant dans votre code, à savoir l’écriture de tests !

Si vous êtes stagiaire ça marche aussi pour prendre de bonnes habitudes et ne pas vous faire taper dessus par votre supérieur, si vous êtes salarié reportez vous au cas du stagiaire ;-)

Je me suis donc dis que j’allais tout simplement le benchmarker grosso modo, afin d’avoir une idée du gain qu’on peut avoir à passer par des tableaux. Car en fait, on sait très bien que le 2e est plus rapide, mais la question, c’est de combien.

J’ai donc pris un modèle assez classique. Un couple de Departement/Region de France.

Dans mon fichier Table de mes départements, je rajoute la méthode suivante pour faire ma jointure sur régions

public function getAll()
  {
    return $this->createQuery('d')
      ->leftJoin('d.Regions r');
  }

Hydratation en objet

Parfait, maintenant, je crée une action qui récupère seulement tous les items de ma table, soit environ 100 départements, en relation avec une région chacun.

public function executeIndex(sfWebRequest $request)
  {
    $this->items = Doctrine::getTable('Departements')->getAll()->execute();
  }

Ca reste un cas tout a fait commun. J’ai donc lancé un ab, un programme livré avec apache qui permet de lancer l’exécution d’une page web, n fois avec n requêtes concurrentielles. j’ai décidé de le lancer 100 fois avec 10 requêtes à la fois. Et voici le résultat:

Document Path:          /hydrate/index
Document Length:        2400 bytes
 
Concurrency Level:      10
Time taken for tests:  16.862 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      269400 bytes
HTML transferred:       240000 bytes
Requests per second:    5.93 [#/sec] (mean)
Time per request:       1686.205 [ms] (mean)
Time per request:       168.621 [ms] (mean, across all concurrent requests)
Transfer rate:          15.60 [Kbytes/sec] received
 
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.5      0       4
Processing:  1172 1665 167.3   1662    2337
Waiting:     1172 1663 166.5   1661    2337
Total:       1172 1665 167.4   1662    2338
 
Percentage of the requests served within a certain time (ms)
  50%   1662
  66%   1709
  75%   1750
  80%   1783
  90%   1860
  95%   1928
  98%   2102
  99%   2338
 100%   2338 (longest request)

Hydratation en tableau

2e action, le même code, le même résultat HTML souhaité, mais on passe dans le execute le fameux paramètre. Notre résultat ne sera donc plus une Doctrine_Collection, mais un tableau associatif avec en clé, les noms des champs.

  public function executeIndex2(sfWebRequest $request)
  {
    $this->items = Doctrine::getTable('Departements')->getAll()->execute(array(),Doctrine::HYDRATE_ARRAY);
  }

Et voici le résultat

Document Path:          /hydrate/index2
Document Length:        2400 bytes
 
Concurrency Level:      10
Time taken for tests:   10.086 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      269400 bytes
HTML transferred:       240000 bytes
Requests per second:    9.92 [#/sec] (mean)
Time per request:       1008.569 [ms] (mean)
Time per request:       100.857 [ms] (mean, across all concurrent requests)
Transfer rate:          26.09 [Kbytes/sec] received
 
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   1.4      0       6
Processing:   598  992 112.9   1003    1239
Waiting:      598  991 113.0   1002    1239
Total:        599  993 113.0   1003    1239
 
Percentage of the requests served within a certain time (ms)
  50%   1003
  66%   1051
  75%   1081
  80%   1085
  90%   1104
  95%   1128
  98%   1149
  99%   1239
 100%   1239 (longest request)

Bilan

Alors évidemment, il faut prendre en compte la différence de temps de réponse qu’on peut avoir entre 2 lancement de ab. Mais l’objectif est surtout de montrer que le gain est non négligeable et vraiment réel.

On constate que le HTML reçu est bien le même. On a donc le même rendu!
Et côté performance, le 1er cas nous donne une requête en 1,7sec quand le 2e nous donne 1s soit près de 60% de mieux.

Conclusion, quand on souhaite réaliser seulement de l’affichage de données, il faut hydrater en tableau! Même si dans le cas présent, on parle de 0,7sec, il faut voir que c’est un projet vierge avec rien d’autre autour. Le gain est donc bien réel et pas seulement gadget.

Crédit photo: http://www.flickr.com/photos/don3rdse/3208161023/

Pour bien configurer un serveur, il existe plusieurs façons, chaque administrateur ayant la plupart du temps sa propre conf en fonction de ses habitudes et celles de ses users.

Je vous propose ici quelques petits tips à mettre en place sur votre serveur pour voir un peu se qui s’y passe.

Connexion SSH

Il est toujours intéressant de connaître les connexions ssh des utilisateurs sur votre serveur, que ce soit pour des statistiques ou tout simplement surveiller les différentes connexions pour par exemple intervenir rapidement en cas d’intrusion.

Pour cela, il existe un moyen très simple avec l’utilisation de sshrc. Dans le man, il est dit :

/etc/ssh/sshrc
Commands in this file are executed by ssh when the user logs in,
just before the user's shell (or command) is started.
See the sshd(8) manual page for more information.

Nous allons donc y introduire un petit bout de script qui enverra un mail automatiquement.

#!/bin/sh
DATE=`date "+%d-%m-%Y %H:%M"`
IP=`echo $SSH_CONNECTION | awk '{print $1}'`
REVERSE=`dig -x $IP +short`
 
# Message + envoi du mail
echo "USER : $USER
IP : $IP
ReverseDNS : $REVERSE
Date : $DATE
 
" | mail -s "[SSH] $DATE - Connexion de $USER" your_email@domaine.com

A chaque connexion ssh d’un utilisateur, vous recevrez un mail contenant diverses informations. Je souligne au passage qu’un authentification ssh par clef est toujours plus sûre ;)

Modifications de fichiers

Il existe plusieurs applications (plus ou moins performantes) permettant de voir les fichiers modifiés sur votre serveur. Ici, un petit script tout bête qui va vous permette de voir les modifications effectuées depuis X jours sur votre serveur dans un ou plusieurs répertoires donnés.

Bien entendu c’est une surveillance basique, rien de comparable avec un contrôleur d’intégrité (tripwire par exemple), mais cela peut s’avérer très pratique, notamment pour retrouver rapidement une erreur faite dans un script après une modification, mais aussi pour vérifier qu’aucune modification externe n’est faite sur des fichiers sensibles.

#!/bin/sh
DATE=`date "+%d-%m-%Y %H:%M"`
LAPS=1
INFOS="Liste des fichiers modifiés :\n"
for i in `find /etc/ -mtime -$LAPS` `find /home/user/ -mtime -$LAPS`; do
        if [ -f $i ]; then
                INFOS="$INFOS\n$i"
        fi;
done
echo $INFOS | mail -s "[MODIF] $DATE - Fichiers modifies" your_email@domaine.com

N.B : Une vérification est faite pour n’avoir que les fichiers et non les répertoires + fichiers.

Dans l’instruction for i in … ; do vous pouvez mettre plusieurs répertoire en utilisant `find /rep/ -mtime -$LAPS`.

Une fois le script créé, il vous suffit de mettre en place un cron (ici à 23h59 tous les jours) qui le lancera automatiquement et vous avertira par mail des changements.

59 23 * * * /path/to/your/script

Consommation de bande passante

Savoir qui consomme le plus de bande passante sur un serveur est souvent très intéressant, je vous propose donc ici un petit script qui va vous permettre de recevoir par mail les informations concernant les hôtes qui consomment le plus de bande passante, ici sur les 10000 derniers paquets.

#!/bin/sh
DATE=`date "+%d-%m-%Y %H:%M"`
tcpdump -c 10000 -ni eth0 | perl -lane 'END{@keys=sort{$h{$a}  <=> $h{$b}} keys %h;for(reverse(@keys)){printf("%32s => %i\n", $_, $h{$_}) if($h{$_}>100);}} $h{$F[1]}++;' | mail -s "[BP] $DATE - Consommation bande passante" your_email@domaine.com

A noter que pour faire plaisir à Vincent, j’ai utilisé du perl et non du python ^^

Une fois le script en place, un petit ajout dans le cron et c’est partit. Vous pouvez le faire tourner autant de fois que vous voulez, cela dépend surtout du traffic de votre serveur, ici 4 fois par jour soit toutes les 6 heures.

* */6 * * * /path/to/your/script

Voilà, si cela vous intéresse, il y aura surement d’autres tips à venir et surtout n’hésitez pas à demander si vous cherchez un petit truc particulier ou si vous avez des remarques.

Rien à dire, en plus de ne pas être écologique, on a du mal à y voir un intérêt, pauvres humains que nous sommes. Mais quand vient le moment d’écrire son adresse mail sur un site web qui sera visible par tout le monde, on en tremblerait presque.

Du coup, il existe beaucoup de techniques, l’idéal étant encore de ne pas écrire son adresse mail en toutes lettres sur son site! Mais des fois, cela reste bien pratique. Voici donc une solution très simple à mettre en place, qui sans être parfaite, assure quand même le boulot dans la majorité des cas.

A noter que cette technique est tiré du site de Symfony himself. Comme je ne l’avais jamais croisé auparavant, ca peut valoir le coup d’en parler un peu.

Le principe est simpliste mais bien pensé.

On écrit, notre adresse mail à l’envers en PHP (ou tout autre langage serveur on est d’accord) et on demande à notre CSS de l’afficher à l’envers également. Et vous l’aurez compris, l’envers de l’envers, et bien… c’est l’endroit! Fou je vous l’accorde.

En terme de code, voilà ce que ca donnera schématiquement:

<span class="reverse">
 <?php echo strrev('monmail@monadresse.com') // qui va écrire moc.esserdanom@liamnom du coup ?>
</span>

Il suffit maintenant de changer la direction de lecture de notre span reverse via CSS:

span.reverse {
direction:rtl;
unicode-bidi:bidi-override;
}

Et voilà, notre adresse est maintenant lisible à l’endroit à tout le monde bénéficiant d’un support CSS, donc en théorie, tout le monde sauf, les vilains méchants robots spammeurs. Malheureusement ça reste de la théorie mais en pratique, cela reste un manque niveau accessibilité, tout comme on est pas sûr que les robots ne sauront pas interpréter le CSS très bientôt. Mais je pense que ca reste une solution à connaitre.

Mais smushit n’est pas mort, Yahoo l’a juste intégré dans son très bon Yslow. On peut se demander si niveau marketing, c’est une bonne idée, tant Yslow est déjà très complet. Mais je vais laisser cette analyse aux spécialistes. Pour ma part, je vais me contenter de vous montrer comment on s’en sert maintenant. Parce que même si les alternatives existent, je l’aime bien moi ce Smushit!

Première étape, il faut déjà retrouver l’option dans l’armada Yahoo:

Il faut donc aller sur l’onglet Tools et vous aurez accès en bas à l’option All Smush.it. Un simple clic et on vous envoie vers une nouvelle url où vous aurez accès à toutes les images de la page courante smushé!

Oui rien de bien compliqué, mais ca méritait d’être dit selon moi ;)

On se rappelle tous (enfin je parle au passé, mais Propel n’est pas mort hein :p) qu’on avait tout à disposition dans le BasePeer de notre modèle, les accesseurs, les modificateurs et quasi toutes les méthodes dont on pouvait avoir besoin. Avec Doctrine, la donne a changé, tant cet ORM est codé différemment.

On se retrouve du coup un peu perdu parfois, sans trop savoir ce qu’on peut utiliser. Et là, il faut bien sûr jeter un œil à l’API Doctrine. Mais on le sait tous, on a pas toujours le temps! Du coup, au travers de mes recherches, j’ai trouvé quelques petites méthodes que j’utilise régulièrement et dont je vais vous parler.

Le modèle d’exemple

Afin d’illustrer au mieux les différentes fonctions, je vais prendre en exemple un modèle basique, une liste de lien:

MyLink:
  columns:
    name: { type: string(100), notnull: true }
    link: { type: string(255), notnull: true }
    description: { type: string(4000) }

Un save qui retourne un booléen

Parfois, lors de petites modifications, on a pas toujours le courage de faire un try/catch sur notre transaction. TrySave répond à cette problématique, en incluant directement le try catch sur le save et en retournant un booléen, true si l’enregistrement a bien été commité, false si une exception a été levée. Bien pratique!

• Documentation trySave
• Exemple:

  public function saveMyLink()
  {
    $link = new MyLink();
    $link->name = 'Amicalement-web';
    $link->url = 'http://www.amicalement-web.net';
   
    return $link->trySave(); // Retournera true si la sauvegarde a été effectuée, false sinon
  }

Le nom de la clé primaire

Oui des fois, quand on veut généraliser une méthode, on a besoin du nom de la clé primaire de notre model. (Dans le cas d’un unset en vue d’un embedForm par exemple).

• Documentation getIdentifier
• Exemple:

  $link = new MyLink();
  $link->getTable()->getIdentifier();

Exporter votre modèle en différents formats

Que se soit pour générer des XML destinés à une application tiers, ou du json pour votre module javascript, on a souvent besoin de nos modèles dans un format d’échange. Et bien Doctrine intègre cette fonctionnalité de base, en permettant des export en tableau php, xml, yml et json.

• Documentation exportTo
• Exemple

  $link = new MyLink();
  $link->name = 'Symfony Project';
  $link->link = 'http://www.symfony-project.org';
  $link->save();
   
  echo $link->exportTo('xml'); // Attention par défaut exporte aussi les relations de l'objets. Il faut mettre à false, le 2e argument si on veut conserver seulement notre objet en question

• Rendu:

  <?xml version="1.0" encoding="utf-8"?>
  <data>
    <id>1</id>
    <name>Symfony Project</name>
    <url>http://www.symfony-project.org</url>
    <description></description>
  </data>

Importer votre modèle en différents formats

Et oui parce que Doctrine fait les choses biens, la réciproque existe aussi et est toute aussi utile. Vous pouvez ainsi hydrater  un objet à partir d’un xml, json, ou yml grâce à la méthode importFrom

• Documentation importFrom
• Exemple:

  $json = '{"id":"5","name":"Doctrine Project","url":"http:\/\/www.doctrine-project.org","description":"Orm PHP"}';
  $link = new MyLink();
  $link->importFrom('json',$json);
  echo $link->name; // Affiche "Doctrine Project"

Pour ce qui est d’hydrater à partir d’un tableau php, il y a 2 méthodes pour ça: fromArray et hydrate. Leurs différences, c’est la façon de faire. La première utilise les modificateurs de notre modèle (permettant ainsi de passer par des modifications qu’on aurait pu apporter à ces méthodes « set ») alors que la seconde remplie directement les attributs de notre modèle.

• Documentation fromArray
• Documentation hydrate
• Exemple:

  // On surcharge le modificateur de la propriété $url pour rajouter 'http://' devant
  class MyLink extends BaseMyLink
  {
    public function setUrl($url)
    {
      parent::_set('url','http://'.$url);
    }
  }

  Puis maintenant nos 2 appels:

  $data = array('name' => 'Amicalement Web', 'url' => 'www.amicalement-web.net');
  $link1 = new MyLink();
  $link1->fromArray($data);
  echo 'link1='.$link1->url; // Affiche http://www.amicalement-web.net
   
  $link2 = new MyLink();
  $link2->hydrate($data);
  echo 'link2='.$link2->url; // Affiche www.amicalement-web.net

Post/Pre methodes

Comme je l’avais utilisé dans l’exemple du behavior Geographical, Doctrine met à disposition toute une série de méthodes en post et pré traitement de nombreuses fonctionnalités comme

• Sérialisation
• Désérialisation
• Sauvegarde
• Suppression
• Mise à jour
• Insertion
• Validation
• Hydratation

Leur documentation à la suite les unes des autre.

Libérer de la mémoire

La performance, sans être un axe principal a mon goût, doit rester dans la tête de chacun. Pour ça, Doctrine propose une méthode pour effacer un objet ainsi que toutes ses références de la mémoire de l’ORM. A utiliser principalement dans des boucles quand on veut juste faire un traitement sur un ensemble d’objets dont on ne voudra pas se resservir ensuite.

• Documentation free
• Exemple:

  // Exemple tiré de la documentation doctrine
  for ($i = 0; $i < 1000; $i++)
  {
      $object = createBigObject();
      $object->save();
      $object->free(true); // true pour libérer même les relations
  }

Hydrater plus efficacement

Et oui, on le crie pas sur tous les toits, mais on est pas obligé de récupérer des objets complets quand on fait une requête avec doctrine même si c’est le comportement par défaut.
Quand on veut simplement faire de l’affichage, parfois seules les données nous intéresse et donc dans un gain de mémoire, on peut changer le mode d’hydratation:

• Doctrine::HYDRATE_RECORD
• Doctrine::HYDRATE_ARRAY
• Doctrine::HYDRATE_NONE
• Exemple:

  $q = Doctrine_Query::create()->from('MyLink');
   
  // Comportement par défaut, retourne un tableau d'objet
  $results = $q->execute(array(),Doctrine::HYDRATE_RECORD);
   
  // Retourne un tableau associatif où les clés sont les noms des champs
  $results = $q->execute(array(),Doctrine::HYDRATE_ARRAY);
   
  // Retourne un simple tableau où les champs sont dans l'ordre qu'ils ont été appelés
  $results = $q->execute(array(),Doctrine::HYDRATE_NONE);

Cela reste le fruit de mes tests et études, si vous avez des remarques ou des corrections n’hésitez pas!

Et vous, vous avez quelque chose à partager sur les méandres de Doctrine?

Bref, en attendant, pas de raison que je ne publie pas! Voici donc une mini astuce, sur un problème rencontré cette semaine, qui m’aura un peu usé, surtout quand on voit la solution finale.

On va donc parler de IE et de l’AJAX.

Commençons par poser le décor comme d’habitude. Quand on fait de l’AJAX avec symfony, il n’est pas rare d’essayer de le faire non intrusif (c’est même conseillé, mais ça dépend si le site a un intérêt à fonctionner sans javascript), et donc de rendre une même action symfony différemment selon qu’on l’attaque en normal ou en AJAX.

Pour cela, on utilise donc un code proche de celui-ci:

if($request->isXmlHttpRequest())
{
  return $this->renderPartial('panier/widget');
}

Au final pour le navigateur, la requête reste la même. Demandez donc maintenant à un navigateur obsolète du genre IE de gérer se genre de mécanisme.
Vous vous attendez au résultat, et je confirme pour vous. De façon non systématique, mais il arrive que si vous chargez d’abord l’action par un appel GET classique et que vous exécuez ensuite une requête ajax sur cette même action, IE a tendance à vous renvoyer la page entière et non pas seulement notre partial comme on l’a défini.

On peut penser que le souci vient de nos entêtes non détectées, mais on s’aperçoit que d’autres requêtes AJAX fonctionne… Et là, on essaye une petite ligne jquery avant notre requête AJAX:

$.ajaxSetup ({
    cache: false
});

Et par magie, IE arrête son jeu de cache cache!

C’est tout bête, mais il fallait le savoir.

Maintenant, je le sais, et vous aussi ;)

En effet, par défaut celui-ci est une empreinte sha1 généré aléatoirement, ce qui convient pour la majeure partie des cas, mais parfois ne suffit pas. Mais là encore Symfony étonne par le mécanisme mis en place pour contourner cette problématique, encore faut-il le savoir malheureusement.

Nous allons prendre un cas classique, une class Medias avec un champ path qui stockera le nom du fichier ainsi uploadé:

class MediasForm extends BaseMediasForm
{
  public function configure()
  {    
    $this->widgetSchema['path'] = new sfWidgetFormInputFileEditable(array(
      'file_src' => '/uploads/medias/'.$this->getObject()->getPath(),
      'is_image' => true,
      'edit_mode' => !$this->isNew(),
      'with_delete' => true,
    ));
 
    $this->validatorSchema['path'] = new sfValidatorFile(array(
    	'required' => false,
    	'path' => sfConfig::get('sf_upload_dir').'/medias',
        'mime_types' => 'web_images'
    ));
 
    $this->validatorSchema['path_delete'] = new sfValidatorBoolean();
  }

Maintenant, si on veut avoir la main sur le nom du fichier généré, il suffit tout simplement dans la class Medias de rajouter la méthode suivante:

// Ou Path est le nom du champ ciblé lors de l'upload
  public function generatePathFilename(sfValidatedFile $file)
  {
   // On a maintenant accès à notre fichier, on peut donc lui donner un nom basé sur son id ou son slug ou tout autre chose.
    return $this->getId().$file->getExtension($file->getOriginalExtension());
  }

Tout simplement! C’est ce genre de détails qui me font apprécier la constante découverte de ce framework ;)

Je profite donc de n’avoir pas de sujets brûlants à vous faire part, pour attaquer ce billet.

En effet, c’est souvent un détail qu’on oublie très vite et il n’y a qu’à voir les maquettes qu’on reçoit pour nos devs, je pense que les bon élèves qui pensent à faire un petit mockup d’un message utilisateur sont pas forcément légions. Et pourtant, dans une optique purement IHM, l’application se doit de communiquer avec l’utilisateur pour montrer qu’il comprend bien la requête.

Difficilement d’imaginer d’appuyer sur un bouton et ne pas savoir si l’application a bien saisi et effectué notre demande. Et pourtant ce n’est pas rare de croiser encore de telles applications même si la tendance s’est inversée depuis l’avènement du deux point zéro.

Le souci, c’est que c’est souvent un peu fastidieux à mettre en place. Heureusement, nous on utilise Symfony et il va nous simplifier les choses pour peu qu’on pose les bonnes bases.

Je ne suis pas allé chercher midi à quatorze heures pour implémenter un système que je reproduis dans tous mes projets, je me suis simplement inspiré de l’admin generator.

Première phase, parmi toutes les possibilités de Symfony, laquelle utiliser pour ce genre de message?
Commençons par cerner nos besoins:

• Il faut pouvoir passer un message à l’utilisateur après une requête de sa part
• qu’elle que soit la page où il se retrouvera après
• seulement sur cette page
• pouvoir distinguer 2 types de messages au minimum: information et erreur

On se rend vite compte qu’il va falloir utiliser les sessions et en jetant un oeil à la classe qui gère ces dernières, sfUser, on découvre la méthode setFlash qui semble parfaitement correspondre à nos besoins et sans aucun effort, car maintenant le principe revient à afficher les messages, vu que le setFlash s’occupera de les faire disparaitre une fois qu’on les aura affichés.

Pour ce faire, et bien on va utiliser tout bêtement un partial qu’on va inclure dans notre layout.php! Ainsi, il sera appelé pour chacune de nos pages. En général on obtient donc quelque chose comme ceci dans notre layout:

<?php include_partial('global/messages') // global défini le répertoire ou se trouve le layout.php ?>
<?php echo $sf_content ?>

Et à l’intérieur de ce partial, voilà ce qu’il suffit de mettre:

<?php if ($sf_user->hasFlash('error') || $sf_user->hasFlash('notice')): ?>
  <div id="feedback">
    <?php if ($sf_user->hasFlash('error')): ?>
    	<p class="error-box">
    		<?php echo $sf_user->getFlash('error') ?>
    	</p>
    <?php endif; ?>
 
    <?php if ($sf_user->hasFlash('notice')): ?>
    	<p class="notice-box">
    		<?php echo $sf_user->getFlash('notice') ?>
    	</p>
    <?php endif; ?>
  </div>
<?php endif; ?>

Voilà, on teste la présence de flash de type ‘error’ et/ou ‘notice’ et les affiche le cas échéant.

Maintenant dans n’importe quelle action de notre application, un simple appel comme ci-dessous suffit:

$this->getUser()->setFlash('error','Une erreur est survenue'); // Pour les erreurs
$this->getUser()->setFlash('notice','Inscription prise en compte'); // Pour les messages

L’étape suivante pourrait être de découpler le type d’erreur de leur namespace utilisé, mais ça je vous laisse faire ;)