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/

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?

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 ;)

Plus mon nombre de projets défile sous Symfony et plus j’essaye d’éviter de faire des choses hors framework, mais plutôt de voir comment on pourrait le régler via le framework. Avant, quand un problème se présentait, j’optais souvent pour une solution alternative quitte à mettre de côté pour une petite fonction la philosophie Symfony. Mais voilà, je l’aime moi, cette philosophie et au fur et à mesure, j’ai décidé de mettre de plus en plus les mains dans la cambouis et les yeux dans le code source, pour résoudre mes problèmes.

Récemment, j’étais sur un petit système de sondage très basique qui se présentait donc sous cette forme grâce au complément sfWidgetFormChoice et sfWidgetFormSelectCheckbox:

Grâce à un code du genre:

$this->widgetSchema['reponses'] = new sfWidgetFormChoice(array(
        'multiple' => true,
      	'expanded' => true,
        'choices' => $reponses
      ));

qui me produisait quelque chose comme ça:

<ul class="radio_list">
<li><input type="checkbox" id="etude_question_2_reponses_7" value="7" name="etude[question_2][reponses][]"/> <label for="etude_question_2_reponses_7">Oula</label></li>
<li><input type="checkbox" id="etude_question_2_reponses_8" value="8" name="etude[question_2][reponses][]"/> <label for="etude_question_2_reponses_8">Ola</label></li>
<li><input type="checkbox" id="etude_question_2_reponses_9" value="9" name="etude[question_2][reponses][]"/> <label for="etude_question_2_reponses_9">Woot</label></li>
<li><input type="checkbox" id="etude_question_2_reponses_10" value="10" name="etude[question_2][reponses][]"/> <label for="etude_question_2_reponses_10">Wagli</label></li>
<li><input type="checkbox" id="etude_question_2_reponses_11" value="11" name="etude[question_2][reponses][]"/> <label for="etude_question_2_reponses_11">Plop</label></li>
</ul>

Ca fonctionne parfaitement, mais voilà à l’intégration, j’avais 2 checkbox par ligne… Et pour réaliser ça, j’avais besoin de modifier le code HTML que Symfony m’avait gentiment généré.

Et donc là, je me suis lancé dans une session de formatting grâce au sfFormatter. En effet, Symfony intègre en règle générale un code HTML par défaut, pour un peu tout, mais nous laisse parfaitement la possibilité de le modifier. Ici, je veux juste pouvoir rajouter une class CSS différente pour les éléments pair et impair. On va donc réécrire la fonction de formatting du widget comme ceci:

$this->widgetSchema['reponses'] = new sfWidgetFormChoice(array(
        'multiple' => true,
      	'expanded' => true,
        'choices' => $reponses,
        'renderer_options' => array('formatter' => array($this, 'formatter')) // Ici on passe l'option formatter avec comme valeur la fonction formatter que l'on va ajouter à notre formulaire
      ));

Puis maintenant, on ajoute la fameuse fonction. J’ai choisi ici de la laisser dans mon formulaire, on peut très bien la mettre où on veut:

public function formatter($widget, $inputs)
{
    $rows = array();
    foreach ($inputs as $i => $input)
    {
      $rows[] = $widget->renderContentTag(
        	  'li', 
                  $input['input'].$widget->getOption('label_separator').$input['label'],
                  ($i%2>0?array('class' => 'pair'):array('class' => 'impair')) //Seule réelle modification par rapport à la fonction définie de base dans la classe sfWidgetFormSelectCheckbox
                );
    }
 
    return $widget->renderContentTag('ul', implode($widget->getOption('separator'), $rows), array('class' => 'radio_list'));
}

Et voilà mon code HTML ressemble maintenant à:

<ul class="radio_list">
<li class="impair"><input type="checkbox" id="etude_question_2_reponses_7" value="7" name="etude[question_2][reponses][]"/> <label for="etude_question_2_reponses_7">Oula</label></li>
<li class="pair"><input type="checkbox" id="etude_question_2_reponses_8" value="8" name="etude[question_2][reponses][]"/> <label for="etude_question_2_reponses_8">Ola</label></li>
<li class="impair"><input type="checkbox" id="etude_question_2_reponses_9" value="9" name="etude[question_2][reponses][]"/> <label for="etude_question_2_reponses_9">Woot</label></li>
<li class="pair"><input type="checkbox" id="etude_question_2_reponses_10" value="10" name="etude[question_2][reponses][]"/> <label for="etude_question_2_reponses_10">Wagli</label></li>
<li class="impair"><input type="checkbox" id="etude_question_2_reponses_11" value="11" name="etude[question_2][reponses][]"/> <label for="etude_question_2_reponses_11">Plop</label></li>
</ul>

Je peux maintenant appliquer mon CSS pour faire la modification demandée à l’origine! Cette astuce fonctionne pour tous les widgets qui embarque du html autre que le simple tag input.

Comme leur nom le laisse à penser, ce sont des méthodes qui seront appeler en amont et en aval de l’exécution d’une action. Je n’ai pas vraiment d’idée d’utilisation à l’heure où j’écris mais dans un souci de factorisation, je trouve le concept intéressant et c’est bien avec ce genre de méthodes que je trouve Symfony si bien pensé.

Quelqu’un s’en est déjà servi? Une utilisation intéressante qui gagne à être connue?

Quoi de plus frustrant d’avoir en premier retour de votre client Euh, pourquoi l’image est au milieu de l’écran? alors que vous venez de passer les dernières heures à la mettre au bon endroit en retouchant votre CSS. Bien sûr vous lancez rapidement le cri de guerre adéquat F5! et la magie opère enfin.

Mais ne serait-il pas plus plaisant que d’obtenir dès le premier clic, le bon résultat?
Il y a pour cela une astuce, que bon nombre connaisse, mais qui dans un contexte de développement professionnel, est souvent lourde à mettre en place: changer le nom de votre CSS pour forcer le navigateur à la recharger et ainsi laisser apparaitre vos modifications du premier coup.

Évidemment, un changement de nom complet n’est pas pensable et d’ailleurs, il suffit de peu en fait.
En effet pour un navigateur les 2 inclusions suivantes sont différentes

<link rel="stylesheet" href="/css/main.css?1" type="text/css" media="all' />

<link rel="stylesheet" href="/css/main.css?2" type="text/css" media="all" />

On utilise ainsi tout simplement le passage de paramètre HTTP, et tous nos navigateurs penseront que la CSS a changé car l’url est différente alors qu’en fait ce n’est que poudre aux yeux!

Dans le cadre d’un projet amateur, on pourrait penser que gérer ce « versionning » de CSS à la main n’est pas insurmontable mais en entreprise, on aura vite faite de s’en passer si ce n’est pas automatisé.

Voyons comment y remédier sur Symfony par exemple. La définition des CSS se fait dans le view.yml de notre application:

default:
  stylesheets:    [main]

donne comme résultat:

<link rel="stylesheet" type="text/css" media="screen" href="/css/main.css" />

Et là, on se dit Euréka! Car oui on peut écrire du PHP dans les fichiers YML de Symfony, directement. Sachant qu’en environnement de production ces fichiers de configurations ne sont générés qu’au clean du cache, on peut très bien écrire alors:

default:
  stylesheets:    [main.css?<?php echo time() ?>]

Et notre CSS changera alors de nom à chaque fois que nous viderons le cache. Certes, ce n’est certainement pas le moyen le plus optimisé car notre CSS ne change pas vraiment à chaque clean de cache, mais son coup de mise en place reste anecdotique pour le résultat obtenu.

Là où la virtualisation se banalise grâce à des logiciels comme VirtualBox, certains utilisent encore des émulateurs dont le célèbre ie4linux.

Et bien, l’alternative pour Mac OS X existe, preuve que la pomme a quand même bien fait les choses. Et pour l’installer rien de plus simple.

Commençons par s’assurer que nous disposons de X11 qui sera utilisé pour afficher la fenêtre de notre futur IE6. Si vous ne l’avez pas spécifié à l’installation de Léopard, il faudra l’installer via Xcode, mais que tout bon développeur sous Mac aura déjà installé. L’application X11 devrait donc se situer dans Applications > Utilitaires

Ensuite, installer Darwine (via un joli .dmg et un simple glissez/déposer à la mac), qui n’est d’autre qu’un portage de Wine sur Mac OS X.

Maintenant tous les exe seront ouvert via Darwine. Il ne vous reste plus qu’à installer ie4osx et voilà le travail:

Alors ça reste moche hein, Mac ne fait pas de miracle, mais ca permet de dépanner rapidement pour des tests bateau, quand vous ne faites qu’assurer le service minimum pour ce navigateur ;)

Son principal problème était son brevet, qui a trainé jusqu’en 2004, le rendant ennemi numéro 1 des libristes du web. Pendant ce temps, tapis dans l’ombre, le PNG a commencé à monter en puissance, d’abord appuyé par le W3C puis certifié ISO en 2004.

Son principal intérêt, un gif amélioré et un format ouvert. Amélioré car il ne s’arrête pas aux 8bits de couleurs du GIF, mais va jusqu’à 32, permettant même de gérer totalement la transparence d’une image et à image égale il surpasse le GIF en poids d’image.

Malheureusement, trop mis en avant dès sa sortie, le PNG a été proclamé messie et tueur également du format JPEG alors qu’il n’en avait pas la possibilité. En effet, le jpeg tire son succès dans la compression de photo, là où son algorithme de compression avec perte (grosse différence comparé au PNG) pouvait pleinement s’exprimer. A photo égale, le PNG se retrouve donc logiquement loin derrière.

On l’a alors rangé dans le catalogue format non optimisé, trop lourd, sans compter avec ces problèmes relationnels avec Photoshop et Internet Explorer.

Mais comme tous les formats ouverts, le PNG a ses fans et certains réalisent des choses assez folles comme ce cher Smush it qui permet en 1 clic après installation du plugin firefox correspondant d’optimiser toutes les images d’un site, vous les mettant alors à disposition, et en PNG bien sûr.

Voila le résultat pour amicalement web:

Il n’est pas encore possible d’imposer une police à l’internaute^[1] mais seulement de lui en suggérer un certain nombre que le navigateur parsera dans l’ordre donné jusqu’à en trouver une que le système d’exploitation possède. Mais avec la montée en puissance, lente mais régulière des systèmes autre que Windows, il peut devenir un vrai casse-tête de trouver une police un peu évoluée que chacun pourra afficher.

En fait le problème se pose surtout pour les linuxiens, et même le paquet msttcorefonts ne résous pas ce problème entièrement, en plus d’obliger les partisans du pingouin à installer un paquet supplémentaire.

Mais le web regorge de bonnes volontés, et je suis tombé sur un billet en anglais qui tente de trouver des équivalents à ce cher Arial, Helvetica, Lucida sous linux en natif.

Au final, j’ai opté personnellement pour le couple Lucida Sans/Mukti Narrow pour le texte et Helvetica/FreeSans pour les titres. Après quelques tests, le résultat est tout à fait acceptable sur mon Ubuntu et permet de garder un peu plus le contrôle sur la charte graphique désirée.

1. C’est tout de même en projet sérieusement dans CSS3

Cependant il n’est pas rare qu’elles gâchent la lisibilité d’un code quand elles s’imbriquent ou quand les différents états sont à plusieurs dizaines de lignes d’écart.

Un moyen simple d’y voir plus clair et de tourner vos conditions différemment.

Par exemple, on a souvent tendance à écrire:

<?php
if ($condition) {
    /* Tout mon traitement qui peut faire plusieurs dizaines de ligne */
} else {
    /* Traitement de l'erreur, par exemple */
    return false ;
}
?>

Au final, la condition n’est utilisée que pour gérer le cas d’erreur, mais celui-ci se retrouve retranché en bas de script.

Pour gagner en lisibilité, on pourrait donc écrire:

<?php
if (!$condition) {
    /* Traitement de l'erreur, par exemple */
    return false ;
}
/* Tout mon traitement qui peut faire plusieurs dizaines de ligne */
?>

La gestion de notre erreur, est maintenant dans la continuité de notre script et se révèle beaucoup plus confortable à lire. Attention toutefois, ce genre de pratique demande à ce que votre gestion d’erreur coupe l’exécution du script avec en général l’utilisation de return.