Discussion :

[shama]

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...

[dgrichard]

Ok, bien vu, je corrige cela 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 :

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
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;
    };

Côté API, a priori, il suffira de déplacer la surcharge XMLHttpRequest.js du fichier OverloadedOpenLayersStandard.js (476 lignes) vers OverloadedOpenLayersMinimum.js

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).

[shama]

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.

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é

[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.

Je suis preneur de toutes suggestions : le code étant téléchargeable, il suffit de voir ce qui pourrait ne pas être à sa place

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.

[shama]

Je suis preneur de toutes suggestions : le code étant téléchargeable, il suffit de voir ce qui pourrait ne pas être à sa place

Je n'ai malheureusement pas le temps pour me livrer a cet exercice.

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.

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.

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é

[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).

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

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).

C'est bien le pourquoi de matériels précédents ...

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.

Chiche ...

(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)

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.

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 ?

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.

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.

Le côté "insupportable" est à démontrer ...

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.

D'abord le téléchargement ne fournit pas les sources compressées.

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 ...)

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é

La vérité est ailleurs ...

[shama]

Chiche ...

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).
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

Qui puis-je ?

Rien et je vous le redit, je comprend parfaitement le choix.

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.

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 ?

Le côté "insupportable" est à démontrer ...

Juste une stat pour démontrer le côté insupportable => 3304 lignes pour OverloadedOpenLayersMinimum.js mélangeant choux, carottes et patates !
Aussi insupportable qu'une fonction faisant plus de 100 lignes !

D'abord le téléchargement ne fournit pas les sources compressées.

C'est bien pourquoi on va les chercher à la mano pour les poser dans le répertoire local de travail

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).

Top merci beaucoup.

J'ai pris en compte les retours (comme d'habitude) pour améliorer le service, il faut juste (comme d'habitude) être patient !

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...