Version imprimable
Bonjour,
Nouveau petit soucis dans l'api minimum sur les fonction XML qui sont surchargées mais sans déclaration de la methode "getParseErrorText()" comme c'est fait dans l'api standard.
Du coup, sans bidouiller, impossible d'utiliser une fonction native OL pour le XML...
Ok, bien vu, je corrige cela :aie: la méthode OpenLayers.Format.XML.read() l'utilise dans l'API minimum. En première instance, il suffit de la surcharger après avoir inclu l'API minimum :
Côté API, a priori, il suffira de déplacer la surcharge XMLHttpRequest.js du fichier OverloadedOpenLayersStandard.js (476 lignes) vers OverloadedOpenLayersMinimum.js :ccool:Code:
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
55
56
57
58
59
60
61
62/** * APIMethod: read * Deserialize a XML string and return a DOM node. * * Parameters: * text - {String} A XML string * * Returns: * {DOMElement} A DOM node */ OpenLayers.Format.XML.prototype.read= function(text) { var index = text.indexOf('<'); if(index > 0) { text = text.substring(index); } var node = OpenLayers.Util.Try( OpenLayers.Function.bind(( function() { var xmldom; /** * Since we want to be able to call this method on the prototype * itself, this.xmldom may not exist even if in IE. */ if(window.ActiveXObject && !this.xmldom) { xmldom = new ActiveXObject("Microsoft.XMLDOM"); } else { xmldom = this.xmldom; } xmldom.loadXML(text); return xmldom; } ), this), function() { return new DOMParser().parseFromString(text, 'text/xml'); }, function() { var req = new XMLHttpRequest(); req.open("GET", "data:" + "text/xml" + ";charset=utf-8," + encodeURIComponent(text), false); if(req.overrideMimeType) { req.overrideMimeType("text/xml"); } req.send(null); return req.responseXML; } ); /* IGNF var pet= OpenLayers.Request.XMLHttpRequest.getParseErrorText(node); if (pet != OpenLayers.Request.XMLHttpRequest.PARSED_OK && pet != OpenLayers.Request.XMLHttpRequest.PARSED_EMPTY) { alert(OpenLayers.i18n(pet)); } */ if(this.keepData) { this.data = node; } return node; };
Edit: finalement, après réflexion, c'est plutôt le contraire qui convient (mettre la surcharge de la la méthode OpenLayers.Format.XML.read() dans l'API standard).
C'est exactement ce que j'ai fait avant de vous poster ce message.Citation:
Envoyé par dgrichard
J'en profite ici pour exposer à nouveau ce que j'avais compris de l'API minimum: "faire en sorte de pouvoir facilement afficher les couches IGN en étant LE MOINS INTRUSIF POSSIBLE face à OpenLayers". Et si cette définition convient, il reste un peu de boulot pour que la réalité colle à cette définition. (surcharge sur les key-events pas heureuses, etc.) Mais bon je n'ai pas la vision d'ensemble ni le cahier des charges de cette api minimum, donc je vois ça avec une simple vision utilisateur.
En tout cas merci et toujours bravo pour la réactivité
Je suis preneur de toutes suggestions : le code étant téléchargeable, il suffit de voir ce qui pourrait ne pas être à sa place :ccool:Citation:
Envoyé par shama
Pour prendre l'exemple, des codes claviers, le fait que certains codes ne soient pas reconnus par OpenLayers m'a fait placer cette surcharge à cet endroit.
Je n'ai malheureusement pas le temps pour me livrer a cet exercice. :oops:Citation:
Envoyé par dgrichard
Que les sources des versions stables soit téléchargeable est une excellente chose, mais quand je vois votre réactivité sur le forum, j'imagine qu'elle existe aussi dans le dépôt des sources or nous n'y avons pas accès (sauf à ce que j'ai loupé une info).
Du coup, certaine personne qui, comme moi on juste le besoin fonctionnel d'afficher les couches de l'IGN sont assez rétissantes à se mettre un délais d'attente d'une nouvelle release en plus de celui d'OL (+ éventuellement d'autres librairies).
Mais c'est certainement que j’interprète mal le sens API Minimum et que j'aurai peut-être plutôt du faire le choix de me passer complètement des API et d'accéder aux couches IGN par VMS classique.
(Je ne dénigre absolument pas le boulot colossale que vous avez fait pour corriger de nombreuses faiblesses d'OL depuis un bon bout de temps maitenant, et nous avons déjà échangé sur le choix qui vous a conduit à faire plutôt des overload de votre côté plutôt que de contribuer directement chez OL)
En revanche, vu que vous me renvoyer sur les sources téléchargeables, le mode "pseudo-compiler" des 3 versions "Overlaoded*" est juste inssuportable pour celui qui ne l'a pas créer et cherche un peu ce qu'il contient.
Pourquoi ne pas avoir fait vos overload dans une arborescence similaire à celle des sources OL et avec les même noms de fichier ? On y gagnerai en lisibilité, et en facilité pour composer les différentes version de l'api lorsqu'on compacte le tout.
Tant que nous sommes sur ce genre de sujet, j'ai fourni, sur une autre discussion, un fichier de chargement de l'API en mode minimal mais non-compacté. Il me semble que ce fichier devrait exister directement dans vos livraisons aussi bien pour l'api etendue, normal que minimal. En mode développement il est vraiment pas facile de se retrouver à bosser sur des sources compressées.
Si le but de l'API minimal est d'ajouter du fonctionnel et correction de bug sur OL alors vous avez bien raison. Si, comme vu de ma fenêtre, elle doit juste permettre l'affichage des couche IGN dans OpenLayers, alors ça n'a rien à faire là. Mais pour le coup c'est vous qui détenez la vérité ;)Citation:
Envoyé par dgrichard
N'ai-je pas indiqué que nous avions enfin réussi à avoir le matériel pour installer tout cela après les vacances :? et tu as répondu :ccool:Citation:
Envoyé par shama
C'est bien le pourquoi de matériels précédents ...Citation:
Envoyé par shama
Chiche ...Citation:
Envoyé par shama
De nouveau, une administration ne peut contribuer à un projet dont les règles de contribution donne les droits d'auteur à une société de droits privé américaine et qui ne prend pas en compte le fait qu'il existe des pays dans lesquels les brevets logiciels ne sont pas reconnus.Citation:
Envoyé par shama
Celà fait plus de 2 ans que j'en discute avec l'OSGéO. Un PSC OpenLayers a eu lieu avec des avancées mais pas de révision de la CCLA.
Qui puis-je ?
Je me suis déjà expliqué dessus, maintenir trois nouvelles arborescences serait complexe et n'empêcherait pas qu'il faille gérer les surcharges pour suivre les évolutions OpenLayers.Citation:
Envoyé par shama
Le côté "insupportable" est à démontrer ...
D'abord le téléchargement ne fournit pas les sources compressées.Citation:
Envoyé par shama
Puis, c'est fait (chargement de l'API non compacté) pour la prochaine mise-à-jour ... Cf. pièce attachée pour la 1.1 (c'est fait aussi pour la 1.0 que j'ai pas sous le clavier).
J'ai pris en compte les retours (comme d'habitude) pour améliorer le service, il faut juste (comme d'habitude) être patient ! (il est vrai que pendant les vacances, les fonctionnaires peuvent bosser vu qu'ils ne foutent rien de l'année ...)
La vérité est ailleurs ... :mouarf:Citation:
Envoyé par shama
Déjà fait l'exercice l'année dernière sous OL et le mois dernier j'ai fait le même exercice sous la v3 de google maps avec les formules simplifiées pour les projections (tests pour pda tactile ou l'api google fonctionne à merveille).Citation:
Envoyé par dgrichard
Mais entre le tout à la mano et l'utilisation du catalogue y'a un petit gap non négligeable ce qui m'a conduit à utilisé l'api minimum, même si on est pas au niveau de la simplicité d'activer une couche google, yahoo, etc. sous OL
Rien et je vous le redit, je comprend parfaitement le choix.Citation:
Envoyé par dgrichard
On a du mal se comprendre car je ne vois qu'une arbo d'overload a maintenir. C'est le rôle du compacteur et des fichiers de chargement non-compresser que de choisir quel morceau d'overload intégrer suivant la version de l'API. Est-ce plus clair ?Citation:
Envoyé par dgrichard
Juste une stat pour démontrer le côté insupportable => 3304 lignes pour OverloadedOpenLayersMinimum.js mélangeant choux, carottes et patates !Citation:
Envoyé par dgrichard
Aussi insupportable qu'une fonction faisant plus de 100 lignes !
C'est bien pourquoi on va les chercher à la mano pour les poser dans le répertoire local de travail :mouarf::oops:Citation:
Envoyé par dgrichard
Top merci beaucoup.Citation:
Envoyé par dgrichard
Pas de souci. Je pense qu'il manque juste un peu de visibilité (et on va pas reboucler sur les serveur de sources) car, par exemple, je n'avais pas vu que vous aviez pris en compte ce point...Citation:
Envoyé par dgrichard