Et forcément, chez les développeurs Symfony, ca frétille d’impatience car chaque jour nous rapproche de la sortie de la version 1.3 de notre framework PHP préféré, dernière release majeure avant le passage en 2.0 (oué pour le coup, ils sont pas encore à la mode).

Je me suis dis que ca valait le coup de faire un petit tour d’horizon des nouveautés attendues (au moins par moi) que se soit Symfony, Doctrine et même Propel:

Propel

On commence avec le feuilleton de l’été. Propel, mourra, mourra pas?

L’info a très vite circulé, et Propel a été enterré très vite après l’annonce de son créateur Hans Lellelid d’arrêter là les frais.

Mais dans son message, il y avait bien un appel au passage de relai, appel auquel François Zaninotto (himself, ex de la core team Symfony) et Sven Teitje ont répondu. Le premier prenant en charge l’évolution de la branche 1.x et le second le développement de la nouvelle branche 2.x.

D’ailleurs ils n’ont pas trainé car on parle déjà de Propel 1.4! On suivra bien sûr ça de très près.

Doctrine

Avec la mode 2.0, Mister Wage prépare lui aussi une version 2.0 de son ORM Doctrine. Peu d’infos encore si ce n’est qu’il sera plus beau, plus fort et surtout plus rapide! Grâce à PHP 5.3 en particulier.
Mais on pourra également retrouver des messages d’erreurs localisés! Et ça c’est la classe.

Mais ceci reste du futur pas proche. Et on va s’intéresser plutôt à la version 1.2, celle qui accompagnera la version 1.3 de Symfony (oui j’avoue, ils auraient pu se mettre d’accord sur les numéros de version, ça aurait été plus simple).

Et la nouveauté majeure pour moi, c’est la possibilité d’étendre les classe de Doctrine facilement et en particulier Doctrine_Query et Doctrine_Collection. On pourra alors généraliser certains comportements et ajouter de nouvelles fonctionnalités comme des tri personnalisés dans les collections ou adapter l’idée de NiKo pour les query.

On notera également, l’ajout d’un système d’extension directement via doctrine qui sont en fait des behaviors. Vous retrouverez la liste sur le site lui même. J’ai d’ailleurs de mon côté, une petite idée d’extension, mais on en reparlera le moment voulu ;)

Symfony

Gros programme pour cette dernière release (comme annoncée, la 1.4 ne sera qu’une 1.3 débarrassé des méthodes/classes dépréciées). Beaucoup de choses, mais voici un résumé de celles que j’attends vraiment:

• La vrai nouveauté, un Mailer de série! Basé sur Swift, très bonne librairie, cela fera toujours un plugin de moins à utiliser
• Le système de formulaire pluggué sur le système d’évènement avec 4 nouveaux évènements qui va permettre enfin de généraliser des comportements pour certains formulaires très facilement.
• Pouvoir ne pas générer les formulaires ou filtres d’un modèle lors de sa définition dans le schema.yml (seulement doctrine). Nan parce que, c’est vrai que des fois, on en a vraiment pas besoin.
• Petit détail enfin corrigé, les pager intègrent enfin les interfaces Countable et Iterator.
• Autre détail, à la génération automatique d’un label d’un champ de formulaire, les _id seront supprimés! Ca permettra d’avoir quelque chose de présentable plus facilement, pcq les _id nous on les voit pas, mais les clients, ca leur saute toujours aux yeux ;)
• Petite révolution dans les définitions de formulaire. Actuellement, il faut retirer du formulaire les champs qu’on ne souhaite pas voir s’afficher. Mais le coup classique du « je rajoute un champ et il apparait automatiquement alors que je voulais pas » ça agace. Dans la 1.3, ca sera donc l’inverse, il faudra spécifier les champs qu’on voudra afficher grâce à la nouvelle méthode useFields
• Niveau CLI aussi beaucoup de nouveautés, dont une assez formidable, la possibilité de rejouer seulement les tests qui auront échoué! Il suffira de rajouter l’option –only-failed.
• Pour Doctrine aussi, beaucoup de rajouts bien pratiques, comme la possibilité de regénérer/supprimer les fichiers liés à un model donné. Et même de resynchroniser tous les modèles avec le schema.yml (entendre par là qu’il supprimera ceux qui n’existe plus). Des petits gains de temps qui ne sont pas de refus, surtout dans les débuts d’un nouveau projet.
• Et bien sûr, la plus attendue pour la fin. Fabien en avait déjà parlé sur le blog, la possibilité de créer un installer pour la génération de nouveau projet qui fera automatiquement toutes les tâches de personnalisation que vous faisiez avant à la main ou en maintenant votre skeleton de projet.

En tout cas, ça fait envie, et ca va dans le bon sens selon moi. Pour tous les détails:

• Slides de Jonathan Wage sur Symfony 1.3 et Doctrine 1.2
• Page officielle des nouveautés de la v1.3

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

• Un colorateur synthaxique multilangage (via blogmotion)
  Le monde des colorateur synthaxique, c’est un peu comme les modalbox en jquery, il y en a partout. Pourtant celui-ci a encore réussi à innover, dans le sens où il arrive à colorer chaque langage présent dans une même page, très pratique pour le cas de code web alliant html, css, javascript et php. On attend une version portable avec impatience.
• Comment écrire un behavior pour doctrine
  Et oui, doctrine on va en parler de plus en plus. Et avec ces behavior bien pratique, on va forcément avoir la question, comment qu’on fait? J’anticipe donc! A noter qu’une rumeur suggèrerait que notre ami Vincent pourrait en parler prochainement sur son blog
• JSON? Comment ca marche?
  Avec l’avènement du javascript, un format de données est sorti de sa cachette: le JSON. Il permet de modéliser des objets javascript, très simplement et est maintenant utilisé régulièrement comme format d’échange en ajax. Mais pour en savoir plus, il suffit de jeter un oeil au lien ci-dessus.
• Passez votre site symfony en maintenance
  Un site web vivant, c’est un site qu’on met à jour. Mais quand ces modifications peuvent prendre du temps, plutôt que de donner un mauvais rendu ou des erreurs à vos visiteurs, il est préférable de leur fournir une page d’attente. Ce billet donne la marche à suivre pour le faire sous Symfony!
• Un plugin jquery pour récupérer des tweets très facilement
  C’est la mode, mettre ses derniers tweets sur son site. Voilà un moyen très simple d’y parvenir
• Un plugin jquery pour tronquer des textes
  Du même auteur, voici un autre plugin jquery qui permet de tronquer très facilement des textes sur notre site.
• Comparons Zend et Symfony
  Un très bon comparatif qui sort des benchmarks classiques où l’auteur montre les différences lors d’une création d’un nouveau projet sous ces 2 framework
• 11 astuces pour protéger votre admin wordpress
  En plein d’actualité avec la faille découverte dans wordpress 2.8.3, voici un récapitulatif des meilleures techniques pour protéger votre admin wordpress.

Une semaine très riche j’ai trouvé, comme quoi ca sentirait presque la fin des vacances déjà…

A demain si tout va bien sous de nouvelles couleurs!

En ce qui nous concerne, avec les annonces faites lors de la dernière Symfony Conference Live, il faut bien commencer à se lancer dans Doctrine. Et c’est l’occasion de découvrir petit à petit cet ORM qui change beaucoup de Propel, pas toujours en bien à mon goût, mais il y a quand même des choses très bien pensées.
En parcourant la doc, je suis donc tombé sur un behavior que j’ai trouvé fort intéressant: Geographical.

Je me suis donc laissé tenté par un test de celui-ci!

Le principe est simple, il rajoute 2 champs à notre table, latitude et longitude, qui outre le fait de donner les coordonnées GPS de notre adresse, pouvant ainsi alimenter une googlemap, permet également de faire des calculs de distance (à vol d’oiseau évidemment).
Et d’ailleurs apparemment, c’est sa seule fonction, car le remplissage des champs est à notre charge. Mais ça reste une fonctionnalité intéressante.

On se lance donc dans une application à un projet, symfony bien évidemment, avec une table classique d’adresse avec le behavior de déclaré.
Voici notre schema.yml

adresses:
  actAs: [ Geographical]
  tableName: adresses
  columns:
    aid: { type: integer(4), primary: true,  autoincrement: true }
    adresse1: { type: string(255), notnull: true }
    adresse2: { type: string(255) }
    cp: { type: string(5), notnull: true }
    ville: { type: string(100), notnull: true }

Ce qui donne en base une fois notre table créé:

+------------+--------------+------+-----+---------+----------------+
| Field      | Type         | Null | Key | Default | Extra          |
+------------+--------------+------+-----+---------+----------------+
| aid        | int(11)      | NO   | PRI | NULL    | auto_increment |
| adresse1   | varchar(255) | NO   |     | NULL    |                |
| adresse2   | varchar(255) | YES  |     | NULL    |                |
| cp         | varchar(5)   | NO   |     | NULL    |                |
| ville      | varchar(100) | NO   |     | NULL    |                |
| latitude   | double       | YES  |     | NULL    |                |
| longitude  | double       | YES  |     | NULL    |                |
+------------+--------------+------+-----+---------+----------------+

Maintenant que les bases sont posées, on va créer une petite classe rapide qui va nous permettre d’alimenter les champs latitude et longitude de notre table. Pour cela on va se servir de l’inévitable googlemap. Il vous faudra pour cela une clé pour utiliser leur API.

class Geoloc
{
  protected 
    $adr = null,
    $key = null,
    $url = null,
    $context = null,
    $format = null,
    $x = null,
    $y = null;
  }
 
  public function execute()
  {
    // On utilise un stream_context pour avoir la main sur certaines options plus facilement, comme le timeout de notre connexion
    $context = stream_context_create(array(
      'http' => array(
        'method'  => 'GET',
        'header' => "Content-type: application/x-www-form-urlencoded\r\n",
        'timeout' => 5,
      ),
    ));
 
    // Google n'autorise que les requêtes en GET, on construit donc notre liste de paramètre prêt à emploi
    $param = http_build_query(array(
          'q' => $this->adr,
          'output' => $this->format,
          'oe' => 'utf8',
          'sensor' => 'false',
          'key' => $this->key
    ));
 
    $content = file_get_contents($this->url.'?'.$param, false, $context);
    if ($content)
    {
      // Le traitement est prévu ici pour du csv
      $retour = explode(',',$content);
 
      // Si le retour est bon, on récupère les coordonnées
      if ($retour[0] == '200')
      {
        $this->x = $retour[2];
        $this->y = $retour[3];
 
        return array($this->x,$this->y);
      }
    }
 
    return false;
  }
 
  public function getX()
  {
    return $this->x;
  }
 
  public function getY()
  {
    return $this->y;
  }
}

Voilà, il suffit de placer cette classe dans un dossier Lib de Symfony, où on bon vous semble. Maintenant on va créer dans notre fichier adresses.class.php 2 méthodes:
- la première qui lancera la mise à jour des champs via google
- la deuxième qui automatisera cette mise à jour, lors d’une nouvelle insertion et seulement dans ce cas. (et non pas à chaque mise à jour)

public function updateCoordonnees()
{
    $completeAdr = $this->;adresse1.' '.(!empty($this->adresse2)?$this->adresse2.' '.:'').$this->cp.' '.$this->ville; // Ajout adresse2 seulement si non vide
    $geoloc = new Geoloc($completeAdr,'maCleGoogleMap');
 
    if ($data = $geoloc->execute())
    {
      $this->latitude = $data[0];
      $this->longitude = $data[1];
    }
}
 
/**
 *  Méthode appelé avant l'insertion d'un nouvel élément. Elle est à surcharger au besoin.
 */
public function preInsert($event)
{
  $this->updateCoordonnees();
}

Et voilà, avec un fichier de fixtures.yml du genre:

adresses:
  adresse_1:
    adresse1: 165 avenue du prado
    cp: 13008
    ville: Marseille
  adresse_2:
    adresse1: 7 rue de verdun
    cp: 13005
    ville: Marseille
  adresse_3:
    adresse1: 57 Bd Romain Rolland 
    cp: 13010
    ville: Marseille
  adresse_4:
    adresse1: Route de Gemenos 
    cp: 13400
    ville: Aubagne

En le chargeant via symfony, on obtient en base:

select * from adresses ;
+-----+----------------------+----------+-------+-----------+------------+-----------+
| aid | adresse1             | address2 | cp    | ville     | latitude   | longitude |
+-----+----------------------+----------+-------+-----------+------------+-----------+
|   1 | 165 avenue du prado  | NULL   | 13008 | Marseille | 43.2783515 | 5.3883703 |
|   2 | 7 rue de verdun      | NULL     | 13005 | Marseille |  43.296542 | 5.3958405 |
|   3 | 57 Bd Romain Rolland | NULL     | 13010 | Marseille | 43.2774579 | 5.4202946 |
|   4 | Route de Gemenos     | NULL     | 13400 | Aubagne  | 43.2975544 | 5.5888222 |
+-----+----------------------+----------+-------+-----------+------------+-----------+

Un petit bout de code dans une action, rapidement pour tester:

public function executeTest(sfWebRequest $request)
{
    $adr1 = Doctrine::getTable('adresses')->find(1);
    $adr2 = Doctrine::getTable('adresses')->find(2);
    echo number_format($adr1->getDistance($adr2, true),2,',','').'Km'; // Par défaut, retourne en miles, il faut mettre le 2e paramètre à true pour avoir le résultat en km
 
    return sfView::NONE;
}

Et on obtient la distance en km entre nos 2 premières adresses. (Ici la distance entre chez moi et mon boulot :p)
Comme l’indique la doc, on peut aller plus loin, en récupérant pour une adresse donnée, les N adresses les plus proches, ce qui peut donner lieu à des fonctionnalités très intéressantes:

public function executeTest2(sfWebRequest $request)
{
    $adr1 = Doctrine::getTable('adresses')->find(1);
    $q = $adr1->getDistanceQuery();
    $result = $q->orderby('miles asc') // On les trie par distance
              ->addWhere($q->getRootAlias(). '.aid != ?',$adr1->aid) // On exclut l'adresse de référence
              ->execute();
 
    foreach ($result as $res)
    {
       echo $res->cp . " - " . $res->kilometers . "<br/>";
    }
 
    return sfView::NONE;
  }

A noter que le code du behavior est très simple en fait, il ajoute juste une formule mathématique pour ces calculs de distance. Mais c’est ce genre de petites fonctionnalités qui me font apprécier la découverte de Doctrine!