La première grosse nouveauté de la v3, c’est la mort de la clé api ! En effet, il n’est plus nécessaire de déclarer un domaine pour récupérer une clé, ou de se battre avec tout un trousseau pour jongler entre des environnements de dev, preprod, prod, test, etc… Maintenant on charge simplement l’api comme n’importe quelle librairie Javascript.
Second changement notoire, plus aucun appel Ajax explicite vers l’api REST n’est nécessaire pour récupérer des données de géolocalisation. Un simple passage de paramètres à des objets Javascript nous rendra les informations voulues en un temps record.

Commençons donc par charger l’api et afficher une map:

<div id="gmap-div" style="width: 500px; height: 400px;"></div>
 
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.min.js"></script>
<script type="text/javascript" src="http://maps.google.com/maps/api/js?sensor=false" />
<script type="text/javascript">
$(function() {
  //J'utilise dans l'exemple jQuery pour améliorer la lisibilité du code, le focus étant sur GoogleMaps
 
  //tout d'abord on définit le centre de notre map par sa latitude et longitude, par exemple Montpellier: 
  var latLng = new google.maps.LatLng(43.60, 3.88);
  //puis on créé la map
  var gmap = new google.maps.Map(document.getElementById('gmap-div'), {
    zoom: 10, //le zoom de départ
    center: latLng, //le centre de la map au chargement
    mapTypeId: google.maps.MapTypeId.ROADMAP, //le type de map, ROADMAP correspond à la version par défaut des versions précédentes
    streetViewControl: false, //si on souhaite désactiver les contrôle StreetView
    panControl: false //si on souhaite masquer les contrôles de déplacement
  });
});	
</script>

Créons maintenant quelques interactions. Pour commencer un formulaire va nous permettre de rechercher une ville pour ensuite placer un marqueur à son emplacement sur la map:

<form id="search-form" action="#">
  <input type="text" id="search-query" size="20" />
  <input type="submit" value="chercher" />
</form>

Et le code javascript correspondant:

//on créé un geocoder qui s'occupera des requètes de géolocalisation
var geocoder = new google.maps.Geocoder();
 
$('#search-form').submit(function(e) {
  e.preventDefault();
 
  //l'objet request que l'on passe au geocoder
  var request = {
    address:    $('#search-query').val(),
    region:     'fr', //pour améliorer la qualité des résultats en précisant que l'on cherche principalement en France
    language:   'fr'
  };
  //aucune requète ajax nécessaire !
  geocoder.geocode(request, function(results, status) {
    if (status == 'OK' && results.length) {
      //on récupère les coordonnées du premier résultat
      var lat = results[0].geometry.location.lat();
      var lng = results[0].geometry.location.lng();
 
      //puis on recentre la map...
      var newCenter = new google.maps.LatLng(lat, lng);
      gmap.setCenter(newCenter);
 
      //...et on pose un marqueur dessus
      new google.maps.Marker({
	position:  newCenter,
        map:       gmap
      });
    } else {
      console.log('aucun résultat');
    }
  });
});

Plutôt simple pour l’instant. Allons un peu plus loin et traçons une ligne qui va relier au fur et à mesure toutes les villes marquées. Il va falloir pour cela utiliser la librairie supplémentaire de GoogleMaps « Geometry ». N’étant pas une librairie chargée par défaut, il faut préciser son utilisation au chargement de GoogleMaps:

<script type="text/javascript" src="http://maps.google.com/maps/api/js?libraries=geometry&sensor=false"></script>

Profitons-en pour afficher la longueur en kilomètre de notre itinéraire dans une div que l’on va tout de suite rajouter au document:

<div id="total-length"></div>

Pour tracer une ligne reliant des points sur une GoogleMap, il faut utiliser la classe « Polyline ». Déclarons-la juste après la map en début de script:

  /* ... */
  var polyline = new google.maps.Polyline({
    strokeColor:   '#2222FF', //on définit la couleur
    strokeOpacity: 0.5,       //l'opacité
    strokeWeight:  3,         //l'épaisseur du trait,
    map:           gmap       //la map à laquelle rattacher la polyline
  });
 
  //on peut extraire un objet renfermant tous les points d'une Polyline
  //cet objet nous sera utile pour calculer la distance de l'itinéraire
  var path = polyline.getPath();

Il faut maintenant étoffer le code de création du marqueur:

  /* ... */
  geocoder.geocode(request, function(results, status) {
    if (status == 'OK' && results.length) {
      var lat = results[0].geometry.location.lat();
      var lng = results[0].geometry.location.lng();
 
      var newCenter = new google.maps.LatLng(lat, lng);
      gmap.setCenter(newCenter);
 
      new google.maps.Marker({
        position:  newCenter,
        map:       gmap
      });
 
      //on ajoute le nouveau point à notre path, le Polyline associé se met automatiquement à jour
      path.push(newCenter);
 
      //on affiche la longueur du path dans notre div
      //c'est ici qu'intervient la librairie Geometry, qui va gérer automatiquement tous les calculs nécessaires
 
      var pathLength = parseInt(google.maps.geometry.spherical.computeLength(path)) / 1000;
      //computeLength nous renvoie des mètres que l'on transforme en kilomètres
 
      //on met à jour l'affichage
      $('#total-length').html(pathLength + ' km');
 
    } else {
      console.log('aucun résultat');
    }
  });
  /* ... */

Il a suffi d’une poignée de lignes pour rajouter ces informations, et le résultat est plutôt sympathique.

On remarque tout de même un détail ennuyeux: il faut déplacer et zoomer à la main si on veut avoir une vue globale et centrée de notre itinéraire à chaque nouvel ajout de marqueur. A la manière du « path » qui stocke les informations d’une Polyline, une map possède des « bounds » qui définissent les limites de son affichage. La classe « LatLngBounds » arrive ici en jeu et va nous permettre d’optimiser automatiquement l’affichage de notre itinéraire.

  //en début de script avec les déclarations, on créé notre objet bounds
  var bounds = new google.maps.LatLngBounds();
 
  /* ... */
 
  //à la suite de l'ajout d'un nouveau marqueur, on étend la zone "bounds" en lui demandant d'inclure le nouveau point
  bounds.extend(newCenter);
  //on demande en suite à la map de s'adapter à cette zone
  gmap.fitBounds(bounds);
 
  /* ... */

Et c’est tout ! Encore trois malheureuses lignes pour une fonctionnalité relativement puissante. Vous pouvez voir l’exemple tourner sur cette page.

La richesse de cette dernière version de l’api, couplée à la fluidité de son utilisation, rend l’intégration d’une GoogleMap dans une application riche vraiment agréable. Jetez un oeil à la documentation officielle très complète si vous souhaitez en apprendre plus !

Les sources de l’exemple de cet article sont disponibles sur Github.

Si l’on reprend quelques bases de bonnes pratiques de développement javascript, on constate :

• que vos javascripts doivent être non-intrusifs, autrement dit là pour améliorer l’expérience utilisateur et en aucun cas être indispensable au fonctionnement d’une page ;
• que les javascript doivent être combinés en 1 seul fichier et minifié (ceci afin de limiter le nombre de requête HTTP et car le chargement de la page est arrêté à chaque balise script, notamment à cause d’un éventuel document.write(); ;
• que l’appel au javascript doit être en bas de page ;

Cette liste est bien entendu non exhaustive, vous trouverez une liste plus détaillée par ici.

Toutes ces bonnes pratiques de développement Javascript n’ont pas toujours été facilitées dans symfony, notamment à la grande époque des helpers link_to_remote() & co. qui en ont ravi certains et fait cauchemarder d’autres. Et aujourd’hui encore bon nombre de widgets de formulaire retournent directement du code javascript (dépendant de jQuery ou autre) et qui ne fonctionneront évidemment plus dès lors que vos javascripts se trouveront en bas de page.

1. Où placer les javascripts dans le document

Idéalement et selon les recommandations de Yslow, en bas de page, donc juste avant la balise fermante de votre layout.php. Ceci afin de ne pas ralentir inutilement le début du chargement de votre page, puisque chaque balise script bloque le chargement de la page (notamment pour gérer le document.write();).
Source : http://developer.yahoo.com/performance/rules.html#js_bottom

Si cette méthode ne vous gênera pas pour les librairies tierces telles que jQuery, qu’en est-il par contre de vos codes javascript ? Ils doivent également se trouver dans des fichiers séparés, dissociés de votre document HTML. Néanmoins comme je vois souvent le besoin pour les développeurs d’avoir le code javascript au sein du template symfony, voici une technique pour qu’il soit tout de même placé en fin de page : via un slot.

Un petit exemple de code :

// indexSuccess.php :
<?php slot('javascript') ?>
<script type="text/javascript">
  console.log('javascript @ bottom');
</script>
<?php end_slot() ?>
 
// layout.php :
<?php include_javascripts() ?>
<?php include_slot('javascript') ?>

Vous pourrez ainsi éditer votre code javascript depuis votre template PHP, bénéficier par exemple de valeurs dynamiques de PHP et pour autant que le code soit bien inclus en bas de page. Toutefois je vous recommande d’écrire du javascript là où il doit se trouver, à savoir dans un fichier JS…

De plus l’inconvénient majeur du slot est qu’il ne peut contenir qu’une valeur, il est écrasé à chaque utilisation. La technique fonctionne mais est très limitée. Pour ces besoins nous avons écrit chez Lexik un petit plugin « lxJavascript », très similaire à l’utilisation d’un slot mais optimisé pour l’inclusion de javascripts. Il gère donc le multiple ajout, supprime les éventuelles multiples balises script pour en conserver qu’une seule, etc. Vous en saurez plus demain, le plugin sort en OpenSource sur le Github de Lexik.

2. Compression

La compression des javascripts (c’est valable aussi pour les CSS) est une des tâches d’optimisations les plus importantes et également une des plus simples, du moins via les plugins symfony. Cette technique consiste à compresser tous vos fichiers javascript en 1 seul et surtout d’y appliquer un numéro de version (un timestamp le plus souvent) afin de prévenir des problèmes de cache dans vos mises à jour.

Les principaux plugins :

• sfCombinePlugin
• npAssetsOptimizerPlugin
• swCombinePlugin

Chez Lexik, nous utilisons npAssetsOptimizerPlugin, un plugin de Nicolas Perriault, extrêmement simple à installer et paramétrer. Sur votre environnement de production, vous obtiendrez ainsi un fichier javascript compressé /js/optimized.js?1294759429 qui contient un timestamp permettant à chaque modifications des fichiers d’être prises en compte sans problème de cache.

Nous n’appliquons pas la compression pour les librairies externes telles que jQuery que nous déléguons aux serveurs CDN de Google, cela apporte ces avantages notables :

• l’avantage du CDN, à savoir de proposer des données statiques via un réseau de multiples serveurs dans de multiples points géographiques, afin de permettre un accès très court ;
• les navigateurs sont limités sur le nombre de connexions HTTP simultanées sur un même domaine, le téléchargement d’un javascript sur les serveurs de Google se fera en parallèle ;
• les librairies du CDN ont les bonnes en-têtes de cache, par exemple la version 1.4.4 de jQuery restera en cache pendant 1 an sur le client, cela signifie également qu’un internaute peut bénéficier du cache téléchargé depuis un autre site, pas forcément sur le votre.

3. Accéder à certaines données dynamiques depuis javascript

Il peut parfois être très utile depuis javascript d’accéder à certaines données dynamiques telles que la culture de l’utilisateur, du routing pour des appels Ajax ou encore de l’i18n. Il suffit de s’appuyer sur un simple fichier de configuration via un tableau de données JSON généré depuis une action symfony. J’ai écrit sur mon blog personnel un article détaillé sur le sujet Configurations Javascript dynamiques en Symfony.

4. Javascript depuis les widget

Maintenant que vos inclusions de javascripts se trouvent en bas de page, jQuery par exemple, que faire de nos chers widgets jQuery Autocompleter sfWidgetFormJQueryAutocompleter et autre Datepicker sfWidgetFormJQueryDate qui retournent des champs de formulaire et le javascript d’initialisation du composant ? Eh bien, ne plus les utiliser… Simplement car ils seront inclus avant jQuery et vous aurez donc droit à l’erreur « jQuery is not defined ». Sans être aussi extrême, vous pouvez charger jQuery en haut de page (via les CDN de Google) et votre script compressé en bas de page, les widgets de formulaire seront alors à nouveau fonctionnels.

Cela fait déjà quelques temps que chez Lexik nous avons fait le choix d’enlever tous ces widgets pour les ré-écrire et les adapter à nos besoins. Les javascripts des widgets passent par notre plugin lxJavascript ce qui permet de les inclure là où on le souhaite. Egalement, le javascript retourné par ces widgets correspond à une utilisation basique du composant, dans un cas concrêt il est souvent nécessaire d’en ré-écrire une bonne part. Il peut être pratique par contre que le widget retourne seulement la sémantique HTML adaptée, par exemple dans le cas d’un Autocomplete un champ hidden pour stocker la valeur et un champ texte pour l’autocomplete, aussi nos widgets ont une option pour retourner ou non le code javascript.

5. Optimisation frontend

Presque aussi important que la compression, la configuration d’apache pour mettre en cache certains de vos fichiers statiques. Typiquement, maintenant que vos fichiers javascripts et CSS sont compressés en 1 seul et possèdent un timestamp unique par version, il serait dommage de les recharger à chaque chargement de page… Vous devez donc configurer le module Expires d’apache via le fichier de config du vhost ou via le .htaccess, en voici un exemple :

  ExpiresActive on
  ExpiresByType text/css "access plus 1 year"
  ExpiresByType text/javascript "access plus 1 year"

Vos fichiers javascript et CSS seront ainsi en cache pendant 1 an, attention du coup à ne pas avoir de fichier sans numéro de version, car ils resteraient en cache et vos internautes ne bénéficieraient pas de vos mises à jour…

Dernière chose, si ce n’est pas encore fait, installez et testez Yslow pour trouver des pistes d’optimisations de performance de vos sites.

Dans mon précédent post j’évoquais les différentes possibilités d’inclure le javascript dans les vues.

• Mettre des balises <script> directement au milieu du html (un peu crade mais efficace)
• Faire un fichier .js « en dur » dans le dossier /web/js (mais là on perd la possibilité d’utiliser du php)
• Utiliser un slot dans le <head> du template
• Utiliser une vue

C’est ce dernier point que je vous propose de voir aujourd’hui.

Pour se dessiner un petit background on va prendre l’exemple d’une vue index dans un module d’actualités.
Dans cette vue on veut faire un appel ajax sur un lien et on veut utiliser le routing pour définir l’url du script à appeler.

On va donc utiliser une action et deux vues, une pour la page html et une pour le javascript qui sera inclus dans la vue html. On utilise des sf_format différents.

On créé la route qui servira pour les deux vues (/app/frontend/config/routing.yml).

...
actu_index:
  url:   /actualites/index.:sf_format
  param: { module: actu, action: index, sf_format: html }
...

Dans notre action on récupère juste les dernières actualités à afficher dans la page html (/app/frontend/modules/actu/actions/actions.class.php).

<?php
 
class actuActions extends sfActions
{
 
  public function executeIndex(sfWebRequest $request)
  {
    $this->actus = Doctrine::getTable('Actu')->getLast();
  }
 
}

La vue Html. C’est la que ca se passe ! On fais un use_javascript() auquel on passe le url_for() de la même vue en spécifiant juste le sf_format à ‘js’ (/app/frontend/modules/actu/templates/indexSuccess.php).

<?php use_javascript(url_for('@actu_index?sf_format=js')) ?>
<div class="liste_actus">
  <?php foreach($actus as $actu): ?>
    <div class="actu">
      <h3><?php echo $actu->getTitre() ?></h3>
      <p><?php echo $actu->getTexteCourt() ?></p>
      <div class="action"><?php echo link_to('Lire la suite', '@actu_detail') ?><div>
    </div>
  <?php endforeach; ?>
</div>

Et donc la vue js sera inclue par la vue html qui rajoute dans le head l’appel au fichier.

<script type="text/javascript" src="/actualites/index.js"></script>

Il ne reste plus qu’a faire la script javascript dans la vue /app/frontend/modules/actu/templates/indexSuccess.js.php ou on peut avoir accès à tous les éléments de symfony que l’on désire.

Par exemple là un peut appel ajax en jQuery ou je récupère l’url du script appelé grâce au routing.

jQuery(function() {
 
  $('div.action a').click(function(event) {
    event.preventDefault();
    $.post(
      '<?php echo url_for('@actu_detail') ?>',
      { url: $(this).attr('href') },
      {},
      'script'
    );
  });
 
});

Il se peut que dans la vue javascript on n’ait pas besoin d’exécuter toute l’action.
Par exemple ici, dans ma vue javascript, je n’ai pas besoin des dernières actualités, il est donc possible de filtrer pour alléger l’action grâce au sf_format.

<?php
 
class actuActions extends sfActions
{
 
  public function executeIndex(sfWebRequest $request)
  {
    if($request->getParameter('sf_format') != 'js')
    {
      $this->actus = Doctrine::getTable('Actu')->getLast();
    }
  }
 
}

Après, libre a chacun de voir si on doit utiliser la même action que la vue html ou si la vue javascript nécessite sa propre action.

En utilisant une action séparée pour la vue javascript on peut s’amuser à pousser le vice du camouflage en utilisant un routing qui fasse croire que l’on appelle un fichier .js (Attention si jamais un fichier avec le même nom existe réellement dans le répertoire /web/js c’est ce dernier qui sera inclus).

...
actu_index_js:
  url:   /js/actu.:sf_format
  param: { module: actu, action: index, sf_format: js }
...

Avantage de cette technique :

• Un code source html super « clean »

Inconvéniant :

• Pour une page html, on fait deux appels à symfony.
  A utiliser avec parcimonie et bien optimiser les actions pour ne pas faire des requêtes inutiles sur la base de donnée.

http://forum.symfony-project.org/index.php/m/66906/?srch=tinymce+3+steps#msg_66906

En français et expliqué plus en détails, ça donne :

Intégrer Tiny MCE

• Télécharger et copier :
  http://tinymce.moxiecode.com/download.php
  dans :

  /web/js/tinyMCE

• Modifier ce fichier :

  /apps/backend/config/settings.yml

  ^?View Code YML

  all: .settings: sf_rich_text_js_dir: js/tinyMCE

Installer le plugin sfFormExtraPlugin:

symfony plugin:install sfFormExtraPlugin

Modifier le widget sfWidgetFormTextareaTinyMCE.class.php

Il faut modifier le plugin !

/plugins/sfFormExtraPlugin/lib/widget/sfWidgetFormTextareaTinyMCE.class.php

Fichier :

<?php
class sfWidgetFormTextareaTinyMCE extends sfWidgetFormTextarea
{
  protected function configure($options = array(), $attributes = array())
  {
    $this->addOption('theme', 'advanced');
    $this->addOption('width');
    $this->addOption('height');
    $this->addOption('config', '');
  }
  public function render($name, $value = null, $attributes = array(), $errors = array())
  {
    $attributes = array_merge($this->attributes, $attributes); 
    ...

Utilisation

Modifier ce fichier :

/lib/form/doctrine/ContenuForm.class.php

<?php
class ContenuForm extends BaseContenuForm
{
  public function configure()
  {
      $this->widgetSchema['texte'] =  new sfWidgetFormTextareaTinyMCE(
      array(
        'width'=>550,
        'height'=>350,
        'config'=>'theme_advanced_disable: "anchor,image,cleanup,help"',
        'theme'   =>  sfConfig::get('app_tinymce_theme','advanced'),
      ),
      array(
        'class'   =>  'tiny_mce'
      )
    );
    $js_path = sfConfig::get('sf_rich_text_js_dir') ? '/'.sfConfig::get('sf_rich_text_js_dir').'/tiny_mce.js' : '/sf/tinymce/js/tiny_mce.js';
    sfContext::getInstance()->getResponse()->addJavascript($js_path);
  }
}