Discussion :

[Max_B]

Comme je l'ai fait remarquer dans 2 fils, beaucoup d'exemples de l'API sont invalides pour la raison suivante: l'API charge des scripts avec l'attribut defer=true (voir code ci-dessous). Or les exemples sont basés sur du javascript inline qui ne testent pas la disponibilité des scripts déférés, entrainant des erreurs de variables indéfinies.
http://www.websiteoptimization.com/speed/tweak/defer/

Considérons ce code, renvoyé par le chargement de l'API:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// Geoportal API version 1.0beta4()
var script= document.createElement('script');
script.type= 'text/javascript';
script.src= 'http://api.ign.fr/geoportail/api/js/1.0beta4/Geoportal.js';
script.charset='utf-8';
script.defer= true;
script.onload= script.onreadystatechange= function(){
	if(script.readyState && script.readyState != 'loaded' && script.readyState != 'complete'){return;}
	script.onload= script.onreadystatechange= null;
	if(typeof(initGeoportalMap)=='function'){initGeoportalMap();}else{
		var save_callback= function(){};
		if(typeof window.onload != 'undefined'){save_callback=window.onload;}
		window.onload= function() {
			initGeoportalMap();
			if(save_callback != 'undefined' && save_callback!=null) {save_callback();}
		};
	}
};
var head= document.getElementsByTagName('head')[0];
head.appendChild(script);

On voit que le script est chargé en defer et qu'un certain nombre de précautions sont ajouté pour déférer aussi l'initialisation de la carte.
Mais justement, le code en ligne n'ayant pas ces précautions il arrive trop tôt. Il est vrai que les exemples fonctionnent sur beaucoup de navigateurs, mais c'est de la pure chance et plus le navigateur optimise le temps de réponse plus il risque de tomber dans cette trappe.

Si les scripts sont chargés en local, par exemple, le problème ne se pose pas.

Note: je poste ce fil car dgrichard l'a suggéré au détour d'une réponse:

Serait-il possible de partager ce type de correctif sur le forum (nous n'utilisons pas le webkit, mais il devrait être possible de remonter l'information auw développeurs OpenLayers s'ils ont été confrontés à celà) ?

[dgrichard]

J'ai modifié sur notre plate-forme de développement, le passage de l'attribut defer de true à false dans la servlet qui fournit ce code javascript.

A ton avis, cela serait-il suffisant ?

[Max_B]

En principe, oui.
J'ai en mémoire des problème de delai, même avec un defer=false, mais je pense qu'il s'agissait de bug browser.
Même sans inclure le webkit dans les navigateur supportés, il est facile de le télécharger (bi-plateforme) pour tester sur le serveur de dev.

[dgrichard]

Même sans inclure le webkit dans les navigateur supportés, il est facile de le télécharger (bi-plateforme) pour tester sur le serveur de dev.

J'ai installé dans ma virtualbox Windows XP sous Linux, Safari 3.2.3.
J'ai téléchargé webkit nightly build.
J'ai lancé le script d'installation.
J'ai eu une erreur sur un point d'entrée d'une fonction absente :
"Le point d'entrée de procédure _CFNetworkErrorGetLocalizedDescription est introuvable dans la bibliothèque de liaison dynamique CFNetwork.dll."


Une idée ? (j'ai la flemme de chercher ayant d'autres chats à fouetter!)

[Max_B]

J'ai installé dans ma virtualbox Windows XP sous Linux, Safari 3.2.3.
J'ai téléchargé webkit nightly build.
J'ai lancé le script d'installation.
J'ai eu une erreur sur un point d'entrée d'une fonction absente :
"Le point d'entrée de procédure _CFNetworkErrorGetLocalizedDescription est introuvable dans la bibliothèque de liaison dynamique CFNetwork.dll."


Une idée ? (j'ai la flemme de chercher ayant d'autres chats à fouetter!)

Il faut avoir installé la dernière version de Safari, la 4, http://apple.fr/safari

[dgrichard]

Ok, j'ai installé Safari4 beta et lancer le script.
Au final j'ai safari4 s'affiche.
Merci

[Max_B]

Ok, j'ai installé Safari4 beta et lancer le script.
Au final j'ai safari4 s'affiche.
Merci

Oui, le webkit, étant le moteur de Safari, sa version Nigthly utilise l'UI Safari. La différence ne se voit que dans les évolutions du cœur, par exemple les optimisations javascript etc. La dénomination Webkit, n'est qu'une commodité de langage
Dans le cas précis de "onload" le fonctionnement ok sur Safari et pas sur le webkit vient probablement d'une optimisation - ou bien d'une régression. Je dois préciser que je n'ai pas testé le onload sous Windows. Mon environnement de travail est OSX et je ne lance la machine virtuelle XP que pour des besoins spécifiques (IE, etc.).

[dgrichard]

J'ai testé sur notre plate-forme de développement le chargement des javascripts compressés : cela semble ok.

J'ai aussi modifié la page de test (qui charge exemples) car Safari/WebKit ne supporte pas la méthode load() sur un document XML ... il faut donc passer par XMLHttpRequest() pour le faire.