Numabilis - Ingénierie web

Google Maps API : gestionnaire automatique de marqueurs

Wed, 21 Nov 2007 20:42:00 +0100

Comme nous l'avons vu dans le billet précédent sur le gestionnaire de marqueurs, l'API Google Maps ne gère pas automatiquement le remplacement d'un groupe de marqueurs proches par un marqueur unique à faible facteur de zoom. Heureusement, Jef Poskanzer a écrit une librairie implémentant cette fonctionnalité : Clusterer.

Partons de l'exemple 9 qui est identique à l'exemple 4 d'un précédent billet auquel j'ai ajouter une concentration importante de marqueurs à l'est de Paris. Déclarons la librairie dans l'en-tête HTML :

La gestion automatique se fait en déclarant une variable clusterer, instanciée dans la fonction load :

var clusterer; function load() { if (GBrowserIsCompatible()) { map = new GMap2(document.getElementById("map")); map.addControl(new GLargeMapControl()); map.addControl(new GMapTypeControl()); map.setCenter(new GLatLng(46.85, 1.75), 6); clusterer = new Clusterer(map); clusterer.SetMaxVisibleMarkers(10); clusterer.SetMinMarkersPerCluster(5); GDownloadUrl("exemple10.json", setup_json); } else { alert("Desole, l'API Google Maps n'est pas compatible avec votre navigateur."); } }

Un objet Clusterer possède 4 méthodes :

SetMaxVisibleMarkers(n) : définie le nombre de marqueurs au delà duquel le clustering est mis en place (150 par défaut).
SetMinMarkersPerCluster(n) : définie le nombre minimum de marqueurs constituant un cluster (5 par défaut).
SetMaxLinesPerInfoBox(n) : définie le nombre de ligne s'affichant dans la fenêtre d'information du marqueur correspondant au cluster (10 par défaut).
SetIcon(icon) : définie l'icône du marqueur correspondant au cluster si celui par défaut ne convient pas.

Il suffit ensuite de remplacer chaque appel à map.addOverlay(marker) par un appel à clusterer.AddMarker(marker, title) (où title est la ligne du marqueur réel qui s'affichera dans la fenêtre d'information du marqueur correspondant au cluster) et chaque appel à map.removeOverlay(marker) par un appel à clusterer.RemoveMarker(marker). Exemple dans la fonction setup_json :

setup_json = function(json, status) { var data = eval('(' + json + ')'); for (var i=0; i<data.markers.length; i++) { var point = new GLatLng(data.markers[i].lat, data.markers[i].lng); var marker = createMarker(point, data.markers[i].html); clusterer.AddMarker(marker, data.markers[i].html); } }

Le résultat est visible sur l'exemple 10.

Cette solution permet de rendre de bons services, mais n'est toute fois pas idéale. En effet, le clustering est lié au nombre de marqueurs plutôt qu'à leur densité. Ainsi, deux marqueurs supperposés ne seront vus que comme un seul marqueur à fort grossissement (en l'absence de clustering). D'autre part, l'algorithme n'est pas très précis : sur l'exemple 10, le marqueur placé sur Le Havre a été intégré au cluster bien qu'il en soit assez éloigné !

Les autres billets de cette série sur l'API Google Maps :

API Google Maps : premières cartes
Google Maps API : marqueurs et fenêtres d'informations
Google Maps API : affichage des données d'un fichier JSON
Google Maps API : géolocalisation (geocoding)
Google Maps API : un marqueur déplaçable
Google Maps API : coordonnées d'un marqueur
Google Maps API : gestionnaire de marqueurs
Google Maps API : gestionnaire automatique de marqueurs

Google Maps API : gestionnaire de marqueurs

Tue, 20 Nov 2007 19:54:34 +0100

Reprenons notre exploration de l'API Google Maps pour résoudre le problème suivant : comment afficher un unique marqueur regroupant plusieurs marqueurs lorsque le niveau de zoom est faible ? En effet, lorsque le nombre de marqueurs est très important sur une petite région, la carte est difficile à lire et lente à s'afficher. La réponse semble être le gestionnaire de marqueurs GMarkerManager.

Partons de l'exemple 4 d'un précédent billet dans lequel nous déléguons l'affichage des marqueurs à un gestionnaire de marqueurs. Pour cela, on déclare une variable mgr, que l'on instancie dans la fonction load :

var mgr; function load() { if (GBrowserIsCompatible()) { map = new GMap2(document.getElementById("map")); map.addControl(new GLargeMapControl()); map.addControl(new GMapTypeControl()); map.setCenter(new GLatLng(46.85, 1.75), 6); mgr = new MarkerManager(map); GDownloadUrl("exemple04.json", setup_json); } else { alert("Desole, l'API Google Maps n'est pas compatible avec votre navigateur."); } }

L'ajout des marqueurs se fait dans la fonctions setup_json en créant d'abord un tableau de marqueurs, markers, ajouter en une fois à la carte via la fonction addMarkers prenant comme second paramètre le niveau de zoom minimum en deçà duquel les marqueurs ne sont pas affichés, et un troisième argument optionnel, le niveau de zoom maximum au delà duquel les marqueurs ne sont pas affichés :

setup_json = function(json, status) { var data = eval('(' + json + ')'); var markers = new Array(); for (var i=0; i<data.markers.length; i++) { var point = new GLatLng(data.markers[i].lat, data.markers[i].lng); var marker = createMarker(point, data.markers[i].html); markers.push(marker); } mgr.addMarkers(markers, 5); mgr.refresh(); }

Le résultat est visible sur l'exemple 8.

On peut appeler plusieurs fois la méthode addMarkers avec différents tableaux de marqueurs pour différents niveau de zoom et gérer ainsi, à la mano, les regroupements de marqueurs. Cela implique donc de calculer, sur le serveur, l'emplacement des marqueurs qui prendront la place d'un ensemble de marqueurs et du niveau de zoom auquel on affiche chacun... Pas simple ! Heureusement il existe une solution toute faite via une librairie JavaScript... Suite au prochain épisode !

Les autres billets de cette série sur l'API Google Maps :

Développer en local une application mashup (Google Maps API, facebook, etc)

Thu, 30 Aug 2007 20:53:06 +0200

Le développement d'une application s'appuyant sur un service externe (mashup) tel que Google Maps ou facebook nécessite de le faire sur un serveur accessible depuis Internet. Cela est imposé par le fournisseur du service qui soit délivre une clé liée au nom du serveur (Google Maps par exemple), soit fait des requêtes directement sur le serveur (facebook). Voici une adaptation d'un tutoriel permettant de développer une telle application sur votre propre poste de développement local (si vous maîtrisez votre réseau).

Il n'y a pas de solution miracle. La seule possibilité est de mettre son poste de développement (le PC) sur Internet. Cela implique de pouvoir faire de la translation de port sur votre routeur NAT. Cette opération varie d'un routeur à un autre. Mais vous aurez généralement besoin de connaître l'adresse IP du PC sur le réseau interne ainsi que son adresse MAC. Pour cela il suffit de taper la commande ifconfig eth0 qui vous sort un truc comme ça (les adresses ci-dessous sont fictives) :

eth0 Lien encap:Ethernet HWaddr 00:12:62:4A:BA:28 inet adr:192.168.0.13 Bcast:192.168.0.255 Masque:255.255.255.0 adr inet6: fa70::153:73ef:fb9a:da16/64 Scope:Lien UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Packets reçus:55899 erreurs:0 :0 overruns:0 frame:0 TX packets:49661 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:1000 Octets reçus:62053810 (59.1 MiB) Octets transmis:8498200 (8.1 MiB) Interruption:16

L'adresse IP du PC sur le réseau interne est donc 192.168.0.13 et son adresse MAC 00:12:62:4A:BA:28.

Il suffit de configurer son routeur pour lui indiquer que l'adresse MAC 00:12:62:4A:BA:28 doit toujours être associée à l'adresse IP 192.168.0.13 et que les requêtes reçu par le routeur sur le port 80 doivent être renvoyées vers le port 80 de la machine d'adresse IP 192.168.0.13.

Vous pouvez chercher la procédure adaptée à votre routeur sur le site Port Forward. Dans le cas d'une freebox, il suffit d'aller sur la page de configuration accessible après login, et de remplir le formulaire :

Exemple de configuration sur la Freebox (agrandir)

Vérifiez que cela fonctionne en pointant votre navigateur vers l'adresse IP publique de votre routeur, récupérable via son interface de configuration ou via le service web What is my IP (88.171.154.137 par exemple). Vous devez voir la racine de votre serveur web... Vous pouvez même donner un nom DNS à cette adresse IP. Il ne vous reste plus qu'à générer la clé du service pour cette adresse IP !

Google Maps API : coordonnées d'un marqueur

Sun, 08 Jul 2007 22:55:10 +0200

Ce sixième et dernier billet (pour le moment du moins) sur l'API Google Maps vous apprendra à récupérer les coordonnées d'un marqueur déplaçable.

Partons de l'exemple 6 du billet précédent. Les coordonnées sont des propriétés du marqueur qu'il suffit de récupérer à la fin d'un glisser/déposer dans la fonction createMarker :

GEvent.addListener(marker, "dragend", function() { htm = html + '<br />Lat_1 = ' + point.lat() + ' Lat_2 = ' + marker.getPoint().lat(); htm = htm + '<br />Lng_1 = ' + point.lng() + ' Lng_2 = ' + marker.getPoint().lng(); marker.openInfoWindowHtml(htm); });

Voilà ! Nous avons tout ce dont nous avons besoin pour faire un formulaire d'enregistrement de coordonnées en plus de l'affichage de marqueurs correspondants à des emplacements fournis sous forme de données JSON.

Le résultat est visible sur l'exemple 7.

Les autres billets de cette série sur l'API Google Maps :

Google Maps API : un marqueur déplaçable

Sun, 08 Jul 2007 19:02:32 +0200

Ce cinqième billet sur l'API Google Maps vous apprendra à créer un marqueur déplaçable par simple glisser/déposer (drag and drop).

Partons de l'exemple 5 du billet précédent dont nous allons simplement modifier la fonction de création de marqueur createMarker :

Le marqueur est donc construit en passant des options au constructeur : l'URL (absolue) d'une icône (pour différencier le marqueur déplaçable des autres) et un simple booléen indiquant que le marqueur est déplaçable ! Il est également possible, comme dans cet exemple de définir des fonctions appelées au début et à la fin du déplacement.

Le résultat est visible sur l'exemple 6.

Les autres billets de cette série sur l'API Google Maps :

Google Maps API : géolocalisation (geocoding)

Sun, 08 Jul 2007 14:55:14 +0200

Ce quatrième billet sur l'API Google Maps vous apprendra à afficher la carte d'un lieu à partir de son adresse. C'est ce que l'on nomme geocoding dans l'API, opération réalisée grâce à un objet JavaScript, le geocoder.

Partons de l'exemple 4 du billet précédent auquel nous ajoutons la variable globale geocoder. Le chargement du fichier JSON est remplacé par l'instanciation du geocoder dans la fonction load :

var geocoder; function load() { if (GBrowserIsCompatible()) { map = new GMap2(document.getElementById("map")); map.addControl(new GLargeMapControl()); map.addControl(new GMapTypeControl()); map.setCenter(new GLatLng(46.85, 1.75), 6); geocoder = new GClientGeocoder(); } else { alert("Desole, l'API Google Maps n'est pas compatible avec votre navigateur."); } }

Nous ajoutons à la page un formulaire permettant la saisie de l'adresse cherchée. La validation du formulaire est interceptée par la fonction geocode qui prend en paramètre l'adresse saisie :

<form onsubmit="return geocode(this.address.value);"> Adresse : <input type="text" size="80" name="address" /> <input type="submit" value="GO" /> </form>

Cette fonction geocode, qui va faire tout le travail, est extrêmement simple :

Elle consiste à appeler la fonction getLatLng du geocoder en lui passant en paramètre l'adresse saisie et une fonction appelée par le geocoder au retour de la requête HTTP. En cas de succès, on centre la carte sur le point correspondant à l'adresse, on créé un marqueur que l'on ajoute sur la carte et on affiche la fenêtre d'information.

Le résultat est visible sur l'exemple 5.

Les autres billets de cette série sur l'API Google Maps :

API Google Maps : premières cartes
Google Maps API : marqueurs et fenêtres d'informations
Google Maps API : affichage des données d'un fichier JSON
Google Maps API : géolocalisation (geocoding)
Google Maps API : un marqueur déplaçable
Google Maps API : coordonnées d'un marqueur
Google Maps API : gestionnaire de marqueurs
Google Maps API : gestionnaire automatique de marqueurs

Google Maps API : affichage des données d'un fichier JSON

Sat, 07 Jul 2007 13:47:49 +0200

Ce troisième billet sur l'API Google Maps vous apprendra à afficher des données distantes au format JSON (produites dynamiquement par un serveur par exemple). L'API peut utiliser le format XML. Je préfère cependant utiliser le format JSON, plus compact et plus rapide à traiter en JavaScript, mais aussi plus complexe.

Partons de l'exemple 3 du billet précédent dont nous supprimons la création du marqueur lors du chargement de la page (fonction load) pour la remplacer par un appel à la fonction GDownloadUrl. Cette fonction permet de charger une ressource de manière asynchrone et prends deux paramètres :

url : l'URL de la ressource, exemple04.json dans notre exemple.
onload : la fonction à appeler après le chargement de la ressource. Cette fonction doit avoir deux paramètres :
- text : le texte du document téléchargé.
- status : le code du statut de la réponse HTTP.
En cas de timeout de la requête, la fonction est appelée avec null et -1 comme arguments.

Nous avons donc la fonction load suivante :

Notons au passage que la vairable map a été sortie de la fonction afin de la rendre globale et de pouvoir y accéder dans la fonction set_json :

Le résultat est visible sur l'exemple 4.

Plus de précisions : Data in JSON files.

Les autres billets de cette série sur l'API Google Maps :

API Google Maps : premières cartes
Google Maps API : marqueurs et fenêtres d'informations
Google Maps API : affichage des données d'un fichier JSON
Google Maps API : géolocalisation (geocoding)
Google Maps API : un marqueur déplaçable
Google Maps API : coordonnées d'un marqueur
Google Maps API : gestionnaire de marqueurs
Google Maps API : gestionnaire automatique de marqueurs

Google Maps API : marqueurs et fenêtres d'informations

Thu, 21 Jun 2007 19:27:09 +0200

Ce second billet vous apprendra à ajouter des marqueurs affichant une fenêtre d'information lorsque l'on clique dessus.

Partons de l'exemple 2 du billet précédent auquel nous ajoutons le bloc suivant dans le corps, afin de prévenir les utilisateurs ne disposant pas de JavaScript :

Prévenons aussi les utilisateurs dont le navigateur n'est pas compatible avec l'API Google Maps en définissant la clause else du test de compatibilité dans la fonction load :

if (GBrowserIsCompatible()) { // ... } else { alert("Desole, l'API Google Maps n'est pas compatible avec votre navigateur."); }

Ajoutons ensuite, lors de la création de la carte, dans la fonction load, l'affichage du contrôle de positionnement et de zoom :

map.addControl(new GLargeMapControl());

ainsi que le contrôle du type de carte (plan, satellite ou mixte) :

map.addControl(new GMapTypeControl());

Définissons un premier marqueur sur Mantes-la-Jolie (de coordonnées 48.9908338, 1.717222) :

var point = new GLatLng(48.9908338,1.717222); var marker = createMarker(point,'Ici, c\'est chez moi !') map.addOverlay(marker);

La fonction createMarker est la suivante :

function createMarker(point,html) { var marker = new GMarker(point); GEvent.addListener(marker, "click", function() { marker.openInfoWindowHtml(html); }); return marker; }

Le résultat est visible sur l'exemple 3.

La fenêtre d'information affiche du HTML standard et il est possible de définir autant de marqueur que l'on souhaite...

Plus de précisions : Markers and info windows.

Les autres billets de cette série sur l'API Google Maps :

API Google Maps : premières cartes
Google Maps API : marqueurs et fenêtres d'informations
Google Maps API : affichage des données d'un fichier JSON
Google Maps API : géolocalisation (geocoding)
Google Maps API : un marqueur déplaçable
Google Maps API : coordonnées d'un marqueur
Google Maps API : gestionnaire de marqueurs
Google Maps API : gestionnaire automatique de marqueurs

API Google Maps : premières cartes

Sun, 10 Jun 2007 15:08:59 +0200

Je me lance dans la découverte de l'API Google Maps et en profite pour rédiger une série de billets sur le sujet. Voici le premier tutoriel permettant de débuter dont la plupart des informations viennent de ce Google Maps API Tutorial de Mike Williams.

Avant toute chose, il faut disposer d'un compte Google car Google ne donne accès à son service qu'à travers une clé d'identification fournie aux seuls possesseurs de compte Google.

Disposant d'un compte Google, vous devez ensuite, générer la clé d'identification valable pour une URL donnée (et toutes ses sous URL) et qui devra être communiquée à chaque requête. La validation du formulaire vous donne :

Une clé du genre :

ABQIAAAA1x2klffHrefUjPpt9uu-YRSFwTc1YMYqORShagowwmhC3WCZJBTJ7YUSLR4rEGMAxpz2Jm54o0aACw

et le code d'une page permettant de tester le service avec cette clé :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head>Google Maps API : coordonnées d'un marqueur <meta http-equiv="content-type" content="text/html; charset=utf-8"/> <title>Google Maps JavaScript API Example</title> <script src="http://maps.google.com/maps?file=api&v=2&key=ABQIAAAA1x2klffHrefUjPpt9uu-YRSFwTc1YMYqORShagowwmhC3WCZJBTJ7YUSLR4rEGMAxpz2Jm54o0aACw" type="text/javascript"></script> <script type="text/javascript"> //<![CDATA[ function load() { if (GBrowserIsCompatible()) { var map = new GMap2(document.getElementById("map")); map.setCenter(new GLatLng(37.4419, -122.1419), 13); } } //]]> </script> </head> <body onload="load()" onunload="GUnload()"> <div id="map" style="width: 500px; height: 300px"></div> </body> </html>

Le résultat de cette page ressemble à cet exemple 1. Le code source est assez limpide et simple à modifier pour centrer la carte sur la France avec un facteur de zoom adapté à la taille du div. Pour cela il suffit de modifier la ligne suivante :

map.setCenter(new GLatLng(37.4419, -122.1419), 13);

en fournissant latitude, longitude et facteur de zoom voulus :

map.setCenter(new GLatLng(46.85, 1.75), 6);

J'utilise aussi un div de taille supérieure :

Le résultat est visible sur l'exemple 2.

Plus de détails sur Instant maps with the Google Wizard.

Les autres billets de cette série sur l'API Google Maps :

Critères de choix d'un framework PHP

Wed, 30 May 2007 19:27:58 +0200

En tant que chef de projet dans une grosse structure, justifiant son poste par sa capacité à résoudre les problèmes qu'il a lui-même créés, vous êtes décidé à bâtir la prochaine application corporate sur un framework PHP. En plus des critères de choix déjà évoqués, vous veillerez à la présence de fonctionnalités qui permettent aux développeurs de se concentrer sur les particularités de l'application, en les libérant de l'écriture des briques de base :

Implémentation du design pattern MVC
Présence d'un module de logging
Contrôle total sur les URLs
Validation des formulaires
Gestion des accès aux bases de données
Implémentation de l'inversion de contrôle (IoC)
Gestion de l'internationalisation
Système de caching
Authentification et gestion des profils utilisateurs
Gestion de la montée en charge
Prise en compte de la sécurité (cross scripting, code injection, sql injection, vols de session, etc)
Système de communication entre les modules
Module Ajax

L'examen d'un certain nombre de framework (Zend Framework, CakePHP, Symfony Project, Seagull Framework, WACT, PHP on TRAX, ZooP Framework, Navigator, CodeIgniter) montre que se sont surtout des usines à gaz. Seul CodeIgniter sort du lot : il est très léger grâce aux modules indépendants, qui ne sont chargés qu'à la demande du contrôleur, mais il a le défaut de la rigidité des URLs. LE framework MVC est donc plus une collection de composants utilisables au sein d'un micro container. C'est la démarche de CodeIgniter et de Zend Framework, bien que ce dernier soit un peu plus complexe.

L'utilisation d'un framework nécessite toujours un investissement pour former les développeurs. Cet investissement sera d'autant plus important que le framework sera complexe. Cette complexité entrainera également des frais plus élevé de maintenance et d'évolution. Dans bien des cas, cet investissement est beaucoup plus rentable s'il est effectué dans le développement d'un micro-noyau maison...

Framework PHP MVC : pourquoi s'en passer

Mon, 15 Jan 2007 21:41:56 +0100

Beaucoup plus populaire que les conteneurs implémentant l'inversion de contrôle, les frameworks MVC (Model-View-Controller ou Modèle-Vue-Contrôleur) en PHP sont légion. Ils participent de cette attente irrationnelle du monde PHP envers la programmation orientée objet et son corollaire, le framework. Seul Rasmus Lerdorf semble percevoir le comique de la situation avec son no-framework PHP MVC framework. Avant de vous décidez de démarrer votre prochain projet avec un tel framework, considérez d'abord les inconvénients suivants :

Une application moins performante. Les diverses couches d'abstraction et la panoplie impressionnante de composants accompagnant tout framework en font un mécanisme lourd, consommant beaucoup de ressources matérielles. La mise en production peut alors s'accompagner de l'achat, en urgence, d'un système de cache performant pour remédier aux performance déplorables. Rappelons-nous des difficultés de lancement du GéoPortail ou plus récemment les débuts difficiles du comparateur de prix des carburants du Minefi.
Coût de développement accrus. La complexité du framework induit des salaires plus élevés pour les développeurs spécialisés en raison de leur rareté ou des frais de formation (ou de perte de productivité) pour les autres développeurs. Ajoutez les frais de formation à un nouveau langage de script si le framework s'appuie sur un moteur de template style Smarty, très à la mode chez les développeurs PHP. Ces moteurs n'ont aucune utilité (si ce n'est de complexifier le développement) comme le montre bien l'article PHP for designers de Matt Mullenweg (co-fondateur et développeur principal de WordPress). Seule compte la séparation des préoccupations.
Une application bridée. Une autre conséquence de la complexité d'un framework est la difficulté de l'étendre ou de l'adapter à ses besoins particuliers.
Une application ne répondant pas aux besoins des utilisateurs. La plupart des framework font des choix radicaux en termes de conception grévant les fonctionnalités de l'application. L'exemple le plus simple : l'URL rewriting. L'URL d'une page est généralement de la forme http://my.web.com/module/action/params pour invoquer l'action action du module module. Aussi lorsque l'on souhaite créer un site web dont les URLs représentent l'architecture fonctionnelle du site, cela s'avère très compliqué ! Ainsi au lieu d'avoir l'URL http://www.numabilis.com/services/realisation_de_sites_web on a quelque chose comme http://www.numabilis.com/article/view/id/35. Le module de réécriture fourni est généralement insuffisant : les sections Services et Réalisations étant toutes deux constituées d'articles, la réécriture ne permet pas de distingués les articles de ces deux sections ! Comme souvent les couches techniques imposent des contraintes fortes sur le fonctionnel.

Les frameworks PHP, dans leur très grande majorité, souffrent d'une trop grande complexité. Ils singent le monde Java (voir les implémentations PHP de Struts : Phrame, PhpMVC ou Studs) en faisant du tout objet avec force renfort de template engine et de mod_rewrite.

Par conséquent, sauf si vous êtes chef de projet dans une grosse structure, dont le poste n'est justifié que par votre capacité à résoudre les problèmes que vous avez vous même créés, vous devriez vous passer d'un tel framework.

Veni Vidi Wiki (dessin de Brad Fitzpatrick)

Technorati Profile

Héritage en JavaScript

Tue, 12 Dec 2006 21:54:41 +0100

Comment faire hériter une classe Book d'une classe Item en JavaScript ?

La classe Item possède deux propriétés (id et price), deux méthodes pour lire ces propriétés (getId et getPrice) et une méthode pour obtenir une représentation de l'objet sous forme d'une chaîne de caractères (toString) :

Une méthode classique d'héritage en Javascript est dite par prototypage :

Book.prototype = new Item; function Book(id, price, title) { this.super = Item; this.super(id, price); this.title = title; } Book.prototype.getTitle = function() { return this.title; } Book.prototype.toString = function() { return "Book[id="+this.getId()+",price="+this.getPrice()+",title="+this.getTitle()+"]"; }

Ainsi, le code suivant :

var myBook = new Book(1001, 10.5, "The definitive JS Guide"); alert(myBook);

provoquera l'affichage de la chaîne de caractères : Book[id=1001,price=10.5,title=The definitive JS Guide]. Parfait ! Mais l'article de Douglas Crockford intitulé Prototypal Inheritance in JavaScript m'a inspiré une autre méthode pour définir de manière automatique et dynamique la fonction Book. Pour cela on écrit une fonction inherit prenant la classe de base en paramètre et renvoyant la fonction définissant la sous-classe. Cette fonction :

Détermine le nombre et le noms des arguments du constructeur de la classe de base (args) par un mécanisme mimant l'introspection,
Construit une chaîne de caractère (str) dont l'évaluation définira la fonction faisant appel au constructeur de la classe de base avec les bons paramètres.
Copie tous les attributs et toutes les fonctions de la classe de base dans la classe dérivée.
Retourne la fonction

Ce code s'appuie sur les extensions trim et explode apportées à l'objet String :

String.prototype.trim = function() { return this.replace(/(^\s*)|(\s*$)/g,''); } String.prototype.explode = function(delim) { var exploded = new Array(); var copy = this; var i = copy.indexOf(delim); while(i>0) { extracted = copy.substring(0, i); copy = copy.substring(i+1); exploded.push (extracted.trim()); i = copy.indexOf(delim); } exploded.push(copy.trim()); return exploded; }

Le constructeur étant défini automatiquement, on ne peut pas lui ajouter des paramètres spécifiques à la sous-classe (title par exemple). L'initialisation de l'objet dérivé doit donc se terminer à l'extérieur du constructeur :

Book = inherit(Item); Book.prototype.title = ""; Book.prototype.getTitle = function() { return this.title; } Book.prototype.toString = function() { return "Book[id="+this.getId()+",price="+this.getPrice()+",title="+this.getTitle()+"]"; }

Le code suivant :

var myBook = new Book(1001, 10.5); myBook.title = "The definitive JS Guide"; alert(myBook);

provoquera l'affichage de la chaîne de caractères : Book[id=1001,price=10.5,title=The definitive JS Guide] comme précédemment.

Il serait possible d'étendre ce mécanisme en ajoutant des paramètres à la fonction inherit afin d'avoir un constructeur prenant plus de paramètres que le constructeur de base. Un des paramètres serait un bout de code à exécuter pour finir l'initialisation de l'objet dérivé. Mais cela aurait-il un intérêt ?

Si l'on met de côté le fait que la définition de fonction à l'aide de la fonction Function et l'utilisation de la fonction eval sont fortement déconseillées, cette méthode est amusante, non ?

Au-delà de MVC(2)

Mon, 16 Oct 2006 17:19:31 +0200

Le design pattern MVC est très à la mode dans le monde PHP. Beaucoup d'articles le présentent, mais peu en font comprendre l'essence. Ils passent généralement à côté de l'essentiel : la séparation des préoccupations.

MVC : la séparation des préoccupations

Inversion de contrôle en PHP : comment ne pas l'implémenter

Mon, 09 Oct 2006 00:29:59 +0200

L'inversion de contrôle (Inversion of Control, IoC) est un motif de conception (design pattern) devenu populaire, ces dernières années, avec l'adoption des conteneurs légers comme SpringFramework. Entendant leurs mérites tant vantés par les développeurs Java, des adeptes de PHP se sont fait un devoir d'implémenter un tel conteneur dans leur langage de prédilection. On trouve ainsi : Drip, Garden, Solar, Phemto, Seasar, ClawPHP et même WACT. C'est à mon avis alourdir considérablement le développement pour faire quelque chose que PHP sait faire naturellement. Je vous propose donc de découvrir ce qu'est l'inversion de controle et comment la mettre en place en PHP sans même l'implémenter concrètement.

Mise en cache d'applet (applet caching)

Fri, 29 Sep 2006 14:12:29 +0200

« Que c'est lent ! » C'est vrai que le chargement d'applet java peut prendre beaucoup de temps. Ce temps de chargement dépend de la taille du code principal (typiquement le .jar constituant l'applet) mais aussi des librairies dont elle dépend et qui sont téléchargées à chaque appel de la page. Au dela de deux seconde, l'utilisateur s'impatiente. Ce billet explique comment éviter le chargement des applet à chaque appel de la page.

Il existe deux solutions : le mécanisme des extensions Java et la mise en cache des applets. Les extensions sont des jar définis comme tels dans le manifest du jar de l'applet, indiquant à la JVM que ces jar sont nécessaires à l'exécution de l'applet. La JVM les télécharge et les stocke dans le répertoire lib/ext du JRE et en charge les classes via le ClassLoader de plus haut niveau. Si une version plus récente du jar est disponible, la JVM se chargera de le télécharger pour remplacer le précedent. Bien que cela soit assez simple à mettre en oeuvre, cette technoloqie présente des inconvénients :

Des conflits peuvent apparaître entre des applets utilisant différentes version d'une même librairie tierce (une version 1.1 téléchargée depuis le site de la première applet et une version 1.2 téléchargée depuis le site de la seconde applet).
Si une librairie fait appel à des librairies natives, des conflits encore pus aigüs peuvent se révéler...

Le mécanisme de mise en cache des applet est tout aussi simple et pose beaucoup moins de problème car les jars sont téléchargés via un ClassLoader spécifique à chaque applet. Il suffit d'ajouter les paramètres suivants dans la balise object :

cache_option indique le mécanisme à utiliser pour gérer le cache ("No", "Browser" ou "Plugin")
cache_archive contient la liste des jar à mettre en cache
cache_version est un paramètre optionnel permettant de gérer les versions des jar.

L'exemple 5 reprend l'ensemble des techniques décrites dans cette série de billets :