interfaceviewer ou viewer
Question plutôt théorique....
A ce que je crois savoir d'après d'anciennes discussions dans ce forum, l'IGN favoriserait la mise en application courante de l'api JS du géoportail via interfaceviewer. L'utilisation d'un chargement direct via viewer étant plutôt réservée à des applications plus élaborées.
1/ Qu'en est-il avec la nouvelle version?
2/ Pour un amateur comme moi, je me pose souvent la question de savoir pourquoi faire une différence entre ces deux modes de chargement, puisque entre autres, on passe du premier à l'autre par la fonction interfaceviewer.getViewer(). Dans ce cas, si je comprends bien, le chargement de l'api pourrait se faire systématiquement par l'interfaceviewer, quitte à travailler ensuite sur le viewer en utilisant cette dernière fonction. Non? Y-a t'il des notions qui m'échappent?
3/ Avec un chargement direct via le viewer, je suis resté avec un complément de codage jugé alors obligatoire :
Qu'en est-il aujourd'hui avec la nouvelle version de l'api?
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55if (window.__Geoportal$timer === undefined) { var __Geoportal$timer = null; } /** * Function: checkApiLoading * Assess that needed classes have been loaded. * Parameters: * retryClbk - {Function} function to call if any of the expected classes * is missing. * clss - {Array({String})} list of classes to check. * Returns: {Boolean} true when all needed classes have been loaded, false otherwise. */ function checkApiLoading(retryClbk, clss) { if (__Geoportal$timer !== null) { //clearTimeout: annule le minuteur "__Geoportal$timer" avant sa fin window.clearTimeout(__Geoportal$timer); __Geoportal$timer = null; } /** * Il se peut que l'init soit exécuté avant que l'API ne soit chargée * Ajout d'un code temporisateur qui attend 300 ms avant de relancer l'init */ var f; for (var i = 0, l = clss.length; i < l; i++) { try { f = eval(clss[i]); } catch (e) { f = undefined; } if (typeof(f) === 'undefined') { __Geoportal$timer = window.setTimeout(retryClbk, 300); return false; } } return true; } /** * Function: loadAPI * Load the configuration related with the API keys. * Called on "onload" event. * Call <initMap>() function to load the interface. */ function loadAPI() { // on attend que les classes soient chargées if (checkApiLoading('loadAPI();', ['OpenLayers', 'Geoportal', 'Geoportal.Viewer', 'Geoportal.Viewer.Default']) === false) { return; } // on charge la configuration de la clef API, puis on charge l'application xxxxxxxxx Geoportal.GeoRMHandler.getConfig([apiKey], null, null, { onContractsComplete : initMap }); } // assignation de la fonction à appeler lors de la levée de l'évènement "onload" window.onload = loadAPI;
4/ Par ailleurs, sans me faire trop d'illusion car cela peut-être complexe en terme de gestion pour vous, je réitère quand même l'idée de pouvoir construire son fichier geoportail.js en fonction des applications et des outils (controls) du geoportail qu'on utilise. Avoir 3 tailles (GeoportalMin.js, Geoportal.js, GeoportalExtended.js) allant du simple au double en taille mémoire c'est bien, mais comme l'utilisateur moyen ne connait pas bien les capacités de ces 3 modules, on favorise plutôt GeoportalExtended.js (qui peut le plus...) sans aucune notion d'optimisation de son chargement. Plutôt dommage, non?
Répondre avec citation
Envoyé par cmail
Partager