L’idée dans le tuto d’aujourd’hui est de faire un petit point sur la partie « security » très bien documentée sur le site officiel mais qui change assez des habitudes de symfony 1 et donc semble un peu déroutante au début.

Ce billet est issu de ma propre et récente expérience sur le sujet et sur la branche master de fabien. Les choses peuvent changer ou être inexactes. Dans ce dernier cas, n’hésitez pas à me reprendre via les commentaires ;)

Contexte

Pour l’illustration, je vais simplement partir de la sandbox officielle d’origine configurée sur l’url suivante en local chez moi :

http://sandbox.local

et où je vais vous montrer comment y intégrer votre admin avec un formulaire d’identification sur l’url suivante :

http://sandbox.local/admin/

L’utilisateur sera géré directement via la config, pas de bdd, on veut quelque chose de très simple et rapide à mettre en place.

Première chose à comprendre dans une application Symfony2, il n’y a plus qu’une application… Oui hein, ça parait fou dis comme ça :D Toute la séparation se situe au niveau des bundles, chacun d’eux pouvant embarquer des modèles, controllers, vues différentes, tout en pouvant communiquer avec les autres bundles. Fini les galères pour faire des liens entre un backend et un frontend !

Pour notre admin, nous allons donc générer un nouveau bundle dans notre application via la commande :

php app/console init:bundle Application/AdminBundle

On se retrouve donc avec un controller basique dans ce bundle qui sera la base de notre admin. Première chose à faire, l’activer dans le fichier app/AppKernel.php via la méthode registerBundles.

Mise en place url admin

On va maintenant tenter d’y accéder via l’url /admin/

Pour ça, c’est très simple ! On va modifier notre fichier routing.yml (ou xml ou php hein, mais moi j’aime bien le yml ! ) comme ceci :

#path:app/config/routing.yml
 
homepage:
    pattern:  /
    defaults: { _controller: FrameworkBundle:Default:index }
 
hello:
    resource: HelloBundle/Resources/config/routing.yml
 
admin:
   resource: AdminBundle/Resources/config/routing.yml
   prefix: /admin

et du coup créer le fichier de routing de notre nouveau AdminBundle. Pour ça, on va faire quelque chose de très simple aussi:

#src/Application/AdminBundle/Resources/config/routing.yml
admin_homepage:
  pattern:  /
  defaults: { _controller: AdminBundle:Default:index }

Et par magie, maintenant, si vous accédez à l’url :

http://sandbox.local/admin/

Vous obtenez le mot « Hello » qui n’est d’autre que la vue par défaut qui a été générée par la commande init:bundle
Pour pas se perdre, on va modifier la vue, pour y indiquer le mot admin, ca sera plus clair.

Sécuriser l’url d’admin

2e étape, comment sécuriser tout ça pour ne pas laisser tout le monde accéder à votre admin. Pour ça il y a en fait plusieurs solutions.

• Sécuriser toutes les urls de votre application, en autorisant les connexions anonymes partout, sauf dans votre admin
• Sécuriser toutes les urls de votre admin seulement

La 1ere a l’avantage de faire écrire très peu de ligne de config, mais honnêtement, je ne sais pas s’il y en a une de meilleure que l’autre, donc je présente la première dans ce tuto, mais je vous met le code de la deuxième à la fin. Elles font sensiblement la même chose.

On va donc se lancer dans la config du component security. Pour ça, on se retrouve dans notre config.yml pour y ajouter un provider, qui sera en fait le compte utilisateur de notre admin.

#app/config/config.yml
security.config:
  providers:
    admin:
      users:
        monadmin: { password: monpass, roles: ROLE_ADMIN }

Nous voici avec un compte « monadmin » identifié grâce au mot de passe « monpass » qui sera crédité de l’autorisation « ROLE_ADMIN » (pour pourriez mettre TOTO à la place de ADMIN, ca changerait rien, par contrel mot ROLE est apparemment obligatoire)

Pour l’instant, ca ne change rien. Définissons maintenant une règle firewall ! Le mot utilisé pour définir ce nouveau service fait sourire j’avoue, en fait il s’agit de définir des règles de sécurité pour des motifs d’urls.

On reste dans notre config.yml qu’on enrichit comme ceci:

#app/config/config.yml
security.config:
  providers:
    main:
      users:
        monadmin: { password: monpass, roles: ROLE_ADMIN  }
 
  firewalls:
    admin:
      pattern: .*
      http_basic: true

Et là, vous obtenez normalement une demande d’authentification HTTP sur tout votre site. Ok! Maintenant, on va autoriser des connexions anonymes, c’est à dire qu’on ne va pas forcer les gens à se connecter:

#app/config/config.yml
security.config:
  providers:
    main:
      users:
        monadmin: { password: monpass, roles: ROLE_ADMIN }
 
  firewalls:
    admin:
      pattern: .*
      http_basic: true
      anonymous: true

Maintenant, voyons voir pour mettre en place un formulaire plus conventionnel (et il me semble plus secure si bien fait, mais à confirmer).

#app/config/config.yml
security.config:
  providers:
    main:
      users:
        monadmin: { password: monpass, roles: ROLE_ADMIN }
 
  firewalls:
    admin:
      pattern: .*
      form_login: true
      anonymous: true

Ici on a changé le mode d’authentification pour celui d’un formulaire classique, grâce à l’option form-login

Maintenant, on va verrouiller l’accès à notre admin. Pour ce faire, on va demander une autorisation pour notre url /admin:

#app/config/config.yml
security.config:
  providers:
    main:
      users:
        monadmin: { password: monpass, roles: ROLE_ADMIN }
 
  firewalls:
    admin:
      pattern: .*
      form_login: true
      anonymous: true
 
  access_control:
      - { path: /admin/.*, role: ROLE_ADMIN }

Et maintenant, si vous essayez d’accéder à l’url :

http://sandbox.local/admin/

Vous êtes redirigés vers l’url:

http://sandbox.local/login/

qui se termine en 404! Jusqu’ici c’est normal.

Symfony2 par défaut, utilise 3 urls pour la gestion de l’authentification :

• login
• login_check
• logout

Nous allons donc les rajouter dans notre routing.yml tout simplement. Attention de bien les mettre au début, histoire d’éviter tout conflit avec une autre de vos règles.

_security_login:
  pattern: /login
  defaults: { _controller: AdminBundle:Default:login }
 
_security_check:
  pattern: /login_check
 
_security_logout:
    pattern: /logout

Le login a besoin de nous pour constituer le formulaire d’identification, les 2 autres doivent seulement exister ! Les patterns des urls peuvent varier, mais il faut alors donner les nouveaux paths dans le config.yml, nous verrons ça plus tard.

Maintenant, si nous accédons à notre admin nous avons bien sûr l’exception suivante:

Method "Application\AdminBundle\Controller\DefaultController::loginAction" does not exist.

On la crée donc:

<?php
// src/Application/AdminBundle/Controller/DefaultController.php
 
namespace Application\AdminBundle\Controller;
 
use Symfony\Bundle\FrameworkBundle\Controller\Controller;
use Symfony\Component\Security\SecurityContext; // à rajouter
 
class DefaultController extends Controller
{
    public function indexAction()
    {
        return $this->render('AdminBundle:Default:index.php');
    }
 
    public function loginAction()
    {
       // get the error if any (works with forward and redirect -- see below)
      if ($this->get('request')->attributes->has(SecurityContext::AUTHENTICATION_ERROR)) {
          $error = $this->get('request')->attributes->get(SecurityContext::AUTHENTICATION_ERROR);
      } else {
          $error = $this->get('request')->getSession()->get(SecurityContext::AUTHENTICATION_ERROR);
      }
 
      return $this->render('AdminBundle:Default:login.twig', array(
          // last username entered by the user
          'last_username' => $this->get('request')->getSession()->get(SecurityContext::LAST_USERNAME),
          'error' => $error,
      ));
    }
}

Donc là, j’ai simplement récupéré le code fourni dans la doc officielle, pas de mystère non plus. Et voici la vue correspondante :

<form action="{% path "_security_check" %}" method="post">
 
  {% if error %}
	<div class="notification error png_bg">
		<div>
			{{ error }}
		</div>
	</div>
  {% endif %}
 
  <p>
      <label>Username</label>
	<input class="text-input" type="text" name="_username" value="{{ last_username }}" />
   </p>
   <p>
      <label>Password</label>
      <input class="text-input" type="password" name="_password" />
   </p>
   <p id="remember-password">
      <input type="checkbox" />Remember me
   </p>
 
   <p>
	<input class="button" type="submit" name="login" value="Sign In" />
   </p>
</form>

Là aussi, très basique mais ça vous donne l’occasion d’essayer twig ;) Ce qui compte pour le coup, c’est surtout les attributs name des input (_username et _password), et de rediriger vers /login_check

A noter que l’utilisation du tag path dans la dernière version de twig n’est plus d’actualité. C’est désormais une fonction, donc à utiliser comme ceci {{ path(‘_security_check’) }}

Alors oui, il faudrait un layout et tout, mais bon, on va aller droit à l’essentiel.

On retrouve bien notre formulaire de login maintenant, si on essaye d’accéder à notre admin ! Encore mieux, si on essaye de s’authentifier, avec le couple login/password défini au début, on obtient notre page « admin! » Et il suffit d’ajouter une dernière ligne à notre config, pour ajouter le listener manquant sur le /logout :

#app/config/config.yml
security.config:
  providers:
    main:
      users:
        monadmin: { password: monpass, roles: ROLE_ADMIN }
 
  firewalls:
    admin:
      pattern: .*
      form_login: true
      anonymous: true
      logout: true
 
  access_control:
      - { path: /admin/.*, role: ROLE_ADMIN }

Et maintenant, vous pouvez vous déloguer sur l’url :

http://sandbox.local/logout

Histoire d’illustrer un peu plus, voici une autre config qui fonctionne aussi et qui permet de ne sécuriser que l’admin:

security.config:
  providers:
    main:
      users:
        monadmin: { password: monpass, roles: ROLE_TOTO }
 
  firewalls:
    admin: { pattern: /admin/.*, form_login: true }
    login: { pattern: /login, anonymous: true, form_login: true }
    login_check: { pattern: /login_check, anonymous: true, form_login: true }
    logout: { pattern: /logout, form_login: true, logout: true }
 
  access_control:
       - { path: /admin/.*, role: ROLE_TOTO }

Il y a bien sûr, beaucoup de tuning possible, pour encoder le password par exemple, mais maintenant qu’on a la base, je vous laisse lire vraiment la doc entière cette fois-ci ;)

Maintenant que c’est fait, nous allons parler ici d’un des aspects de symfony les plus intéressant, mais aussi d’un des moins bien documenté. Pas que les forms « basiques » ne soient pas documentés, mais dès que vous voulez faire autre chose qu’un form qui représente tel quel (ou presque) un objet de la base de données, ça se complique un peu.

Je vais essayer de vous faire un petit tour d’horizon de ce qu’on peut faire avec les embedded forms.

Les forms, c’est de la POO

Vous allez me dire que tout symfony est de la POO (Programmation Orientée Objet), et vous avez raison. Mais on peut utiliser symfony sans être un expert de la POO (voire sans vraiment savoir ce que c’est), en suivant Jobeet et en comprenant que executeIndex inclut le template indexSuccess.php en cas de succès. À partir de là, on est le roi du monde.

Enfin, du monde, moins les forms. Car les forms sont – à mon sens – la partie de symfony qui est à la fois utilisée par tous les utilisateurs de symfony, et à la fois très orientée objet (les factories sont par exemple beaucoup moins utilisées …). Du coup, ça mérite quelques explications.

Tout le monde n’est pas doué en POO

Certes tout le monde n’est pas doué en POO, professionnel ou pas d’ailleurs ;) À l’inverse de JAVA où les programmeurs n’ont pas vraiment le choix, la POO est récente dans PHP et certains l’ont découvert comme un cheveu sur la soupe.

L’impression que l’on a quand on essaye de changer le comportement des embed form c’est : mais où est-ce que je peux bien faire ce que j’ai envie de faire? doBind, doUpdateObject, saveEmbeddedForms, … les choix sont multiples.

Et pour cause, les forms utilisent énormément l’héritage, et disposent donc de moultes méthodes que l’on peut surcharger, sans que ce ne soit vraiment documenté autre part que dans l’API. Si on ne comprend pas les principes de base de la POO, les forms sont une vraie galère (déjà que quand on les comprend …).

Petit rappel sur la POO sur developpez.com : Consultez au moins la partie sur l’héritage pour ceux qui sont largués.

Principales étapes de gestion des formulaires

Il faut quand même que vous ayez quelque chose à l’esprit, il y a pour moi deux principales étapes quand vous souhaitez traiter un formulaire qui vient d’être soumis :

• 1 ère étape : lier les valeurs qui sont récupérées dans la requête à l’objet Form (c’est à dire les recopier en s’assurant qu’elles sont valides et nettoyées)
• 2 ème étape : Une fois les valeurs recopiés dans le $values du formulaire (qui n’est en fait qu’un tableau de valeurs nettoyées), réaliser un traitement dessus ou sur l’objet qui en découlera (nous verrons cela par la suite)

Il est toujours bon de se demander ce que l’on veut faire exactement : agir sur les valeurs qui seront recopiées et validées dans notre form, ou alors agir sur les valeurs nettoyées et recopiées, avant qu’elles ne soient sauvegardées en base.

Première étape

Lors de la première étape de liaison/validation/recopie des valeurs de la requête dans votre formulaire (votre objet Form), vous pourrez agir sur les données avant qu’elles ne soient passées dans les validateurs, ou alors une fois qu’elles sont passées dans les validateurs.

Vous pourrez faire votre bourrin : enlever des parties de votre formulaire de la requête en vous basant sur certaines valeurs soumises.
Par exemple enlever tout un formulaire embarqué, si certaines valeurs ne sont pas saisies (c’est l’exemple qu’on trouve pas mal sur le web d’ailleurs).
Petit souci : les valeurs de la requête n’auront pas été validées/nettoyées par les validateurs, vous vous exposez donc à quelques soucis (dans le style le gars qui n’aura rempli que des espaces dans un champ texte, faudra penser à faire vous même le trim avant de vérifier la valeur …).

Deuxième étape

Lors de la deuxième étape, c’est ici que vous devrez effectuer les traitements concernant votre logique métier à proprement parler. La première étape s’est occupée de vous donner accès aux valeurs dans votre formulaire (via le tableau $values), maintenant que c’est fait vous pouvez jouer avec.

Vous voulez mettre à jour un objet qui dépend de celui que vous allez sauvegarder automatiquement, vous souhaitez insérer votre objet dans un nested set, etc etc … C’est dans cette étape que vous ferez ça.

Je sépare sciemment le processus en deux étapes, après vous pouvez le voir autrement. Les étapes étant chaînées, vous pouvez les mélanger et faire un peu de business logic à la fin de l’étape 1 par exemple, mais essayez de rester constant partout dans votre code, où vous ne saurez plus où aller voir quand il y a un souci.

Étude de cas

On va prendre ici un cas tout simple, celui d’un formulaire auto-généré par doctrine à partir d’une table de votre modèle.

Appelons notre modèle PetitSuisse. On aura donc une classe nommée PetitSuisseForm.class.php dans lib/form/doctrine/

On va vite fait faire le parcours d’héritage de cette classe :
PetitSuisseForm => BasePetitSuisseForm => BaseFormDoctrine => sfFormDoctrine => sfFormObject => BaseForm => sfFormSymfony => sfForm (ouf)

Même si quelques unes de ces classes sont vides, on comprend que ça puisse devenir un peu dur de savoir où chercher. Alors oui l’abstraction c’est bon mangez en, mais ça engendre une complexité de lecture du code non négligeable.

Les classes qui sont « à vous » et donc dans lesquelles vous pourrez surcharger des méthodes sont PetitSuisseForm et BaseFormDoctrine.

La première vous permettra de surcharger une méthode relative au formulaire du modèle PetitSuisse, la deuxième vous permettra de surcharger de manière plus globale (chacun des forms auto-générés par doctrine héritant de BaseFormDoctrine). Je parle ici de symfony 1.3+, vous n’aurez pas toutes ces classes dans les versions précédentes.

On va maintenant parler des principales méthodes que vous aurez (peut être) à surcharger. Il en existe d’autres, si celles ci ne vous vont pas, lisez le code de symfony ;-)

1 ère étape (liaison)

doBind(array $values)

C’est la méthode qui va faire appel aux validateurs pour nettoyer les valeurs de la requête avant de les placer dans le tableau des valeurs. Ce sont ensuite sur ces valeurs nettoyées que nous travaillerons. Vous pouvez ici toucher aux données brut de pomme qui sortent directement du formulaire envoyé, sans traitement préalable.

2 ème étape (sauvegarde)

doSave($con = null)

C’est cette méthode qui sera appelée (par save() ) lorsque vous demandez la sauvegarde de votre formulaire. Elle se charge de mettre à jour votre objet avec les valeurs du form en appelant updateObject (qui appelera doUpdateObject que nous verrons par la suite).
Si vous souhaitez changer le processus de sauvegarde, ajouter par exemple l’appel d’une vos méthodes à chaque sauvegarde du formulaire (pourquoi pas garder trace dans un fichier de toutes les sauvegardes de vos formulaires), c’est ici que vous devez le faire.

processValues($values)

C’est ici que vous pouvez toucher les valeurs qui ont été nettoyées par les validateurs, avant qu’elles ne soient passées à la méthode updateObject (que nous verrons par la suite). Je n’ai pas de traitement particulier en tête, mais l’idée est là : modifier des valeurs avant qu’elles ne soient utilisées pour mettre votre objet à jour.

doUpdateObject($values)

C’est cette méthode que vous devrez surcharger si vous voulez réaliser une opération spéciale sur votre objet avant qu’il ne soit enregistré dans la base.
Par exemple, si vous voulez insérer cet objet à la fin d’un NestedSet, vous ferez ça ici. Le $values passé en paramètre est un tableau contenant les valeurs du formulaire, une fois qu’elles ont été nettoyées/vérifiées par les validateurs.

updateObjectEmbeddedForm($values)

Je pense qu’elle veut bien dire ce qu’elle veut dire. Elle va se charger d’appeler la fonction updateObject de chaque formulaire embarqué. Vous voulez agir sur le traitement des données par vos forms embarqués ? C’est par ici !

saveEmbeddedForms($con = null, $forms = null)

Allez la petite dernière pour la route : elle se charge de la sauvegarde de chacun des objets de vos forms embarqués. Fabien Potencier en donne un exemple de surcharge dans le livre « More with symfony »

Exemple d’utilisation

C’est bien beau de parler, mais un peu de concret ne fait pas de mal.

Vous trouverez un bon exemple pour comprendre le comportement des forms sur le blog de n1k0 dans son article Embedding Relations in Forms with Symfony 1.3 and Doctrine. Certes c’est en anglais, mais le code est universel ! Si vous avez des bons articles en français je suis preneur aussi.

Il existe maintenant la méthode embedRelation() et le plugin de Daniel Lohse ahDoctrineEasyEmbeddedRelationsPlugin qui font ça tout seul. Mais c’est toujours bien de comprendre ce que l’on fait ;-)

Conclusion

Je vous ai fait un petit tour d’horizon des principales méthodes que vous pouvez surcharger dans votre formulaire. Comme je l’ai dit plus haut, ce n’est pas une liste exhaustive, mais vous devriez avoir de quoi vous amuser.

J’ai juste essayé de voir tout cela d’une manière un peu plus globale et de ne pas proposer un n-ième exemple de code pour les formulaires embarqués.

Mais avec tout cet attirail, gardez à l’esprit que votre code d’action ne doit pas dépasser le classique Bind > Save! Ce qui est au traitement de votre formulaire, reste dans votre formulaire! Enjoy!

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

C’est donc mogito qui me rejoint pour écrire quelques beaux tutorials! Encore un Symfoniste? Et non, même pas, mogito est ce qu’on appelle un développeur… undergroud. Un homme de l’ombre qui est passionné de sécurité informatique et qui met ses compétences de développement pour cette passion principalement. En même temps, ça tombe bien, c’est aussi un peu son boulot, pour un gros site marchand qu’on ne citera pas (enfin je laisse mog le faire :p).

Vous aurez donc, dès demain, le droit à son premier tutorial. Je veux pas spoiler, mais ca parle de … sécurité informatique je crois!

J’espère que vous lui réservez un accueil chaleureux, et que vous apprécierez cet élargissement de la ligne éditoriale.

J’en profite pour relancer mon appel, je ne suis fermé à aucune proposition de collaboration! Plus on est de fous, plus on ris.

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!