Oui ce n'est pas très orthodoxe. Je crois qu'ils exploitent le dilemme entre l'interprétation du HTML et la construction du DOM par les navigateurs.
Pour faire simple, le contenu de l'élément <script> est ignoré par l'interpréteur HTML, et n'est donc pas passé au moteur JS pour exécution. Mais, par contre, ce contenu est construit et récupérable dans l'arbre DOM, à charge pour un script quelconque de l'exploiter pour y trouver, par exemple, des paramètres de configuration.
Le hic, à mon avis, est que cela oblige à employer la fonction "eval()" sur le contenu récupéré, pour pouvoir l'exploiter.
Je ne sais pas pourquoi ils ont choisi cette méthode plutôt que de passer les paramètres dans l'url, comme dans cet exemple : <script src="monScript.js?param1=val1¶m2=val2"></script> Ce n'est pas plus dur à récupérer et surtout sans risque.
Effectivement, si le futur standard est implémenté tel quel, ils vont avoir quelques problèmes avec leur bibliothèque, à moins que j'aie loupé un truc.
Oui ce n'est pas très orthodoxe.
Je crois qu'ils exploitent le dilemme entre l'interprétation du HTML et
la construction du DOM par les navigateurs.
Pour faire simple, le contenu de l'élément <script> est ignoré par
l'interpréteur HTML, et n'est donc pas passé au moteur JS pour exécution.
Mais, par contre, ce contenu est construit et récupérable dans l'arbre
DOM, à charge pour un script quelconque de l'exploiter pour y trouver,
par exemple, des paramètres de configuration.
Le hic, à mon avis, est que cela oblige à employer la fonction "eval()"
sur le contenu récupéré, pour pouvoir l'exploiter.
Je ne sais pas pourquoi ils ont choisi cette méthode plutôt que de
passer les paramètres dans l'url, comme dans cet exemple :
<script src="monScript.js?param1=val1¶m2=val2"></script>
Ce n'est pas plus dur à récupérer et surtout sans risque.
Effectivement, si le futur standard est implémenté tel quel, ils vont
avoir quelques problèmes avec leur bibliothèque, à moins que j'aie loupé
un truc.
Oui ce n'est pas très orthodoxe. Je crois qu'ils exploitent le dilemme entre l'interprétation du HTML et la construction du DOM par les navigateurs.
Pour faire simple, le contenu de l'élément <script> est ignoré par l'interpréteur HTML, et n'est donc pas passé au moteur JS pour exécution. Mais, par contre, ce contenu est construit et récupérable dans l'arbre DOM, à charge pour un script quelconque de l'exploiter pour y trouver, par exemple, des paramètres de configuration.
Le hic, à mon avis, est que cela oblige à employer la fonction "eval()" sur le contenu récupéré, pour pouvoir l'exploiter.
Je ne sais pas pourquoi ils ont choisi cette méthode plutôt que de passer les paramètres dans l'url, comme dans cet exemple : <script src="monScript.js?param1=val1¶m2=val2"></script> Ce n'est pas plus dur à récupérer et surtout sans risque.
Effectivement, si le futur standard est implémenté tel quel, ils vont avoir quelques problèmes avec leur bibliothèque, à moins que j'aie loupé un truc.
-- Cordialement, Pascal
Pascal Poncet
Le 03/07/2011 19:36, Pascal Poncet a écrit :
Le hic, à mon avis, est que cela oblige à employer la fonction "eval()" sur le contenu récupéré, pour pouvoir l'exploiter.
Pardon de me répondre à moi-même, mais je viens de voir une autre possibilité que le "evil/eval" !
En fait, on peut cloner le contenu dans un nouvel élément <script> créé dynamiquement et ajouté dans le DOM.
Par exemple, on aurait le source HTML suivant, dont le deuxième script permet de récupérer les paramètres du premier en les stockant dans l'objet "extParams" :
<html> <head> <title>Test JS</title> <script src="params.js"> {"message": "coucou !"} </script> </head> <body> <p>Valeur à récupérer : <span id="msg"></span></p> <script> var scriptTags = document.getElementsByTagName("script"); for (var i=0, len = scriptTags.length; i < len; i++) { if (! scriptTags[i].src) continue; if (scriptTags[i].src.indexOf("params.js") >= 0 ) { var params = scriptTags[i].innerHTML; var newScriptTag = document.createElement("script"); newScriptTag.innerHTML = "var extParams = " + params + ";"; scriptTags[i].parentNode.appendChild(newScriptTag); } } </script> </body> </html>
Et le script externe "params.js", qui peut ainsi disposer des propriétés de l'objet "extParams", ici pour en incorporer une ("message") dans le document en cours :
window.onload = function() { var msgString = extParams["message"]; var msgContainer = document.getElementById("msg"); msgContainer.innerHTML = msgString; }
Testé FF 5.0 seulement.
C'est sûrement un truc comme ça que Google a dû bricoler dans cette bibliothèque.
-- Cordialement, Pascal
Le 03/07/2011 19:36, Pascal Poncet a écrit :
Le hic, à mon avis, est que cela oblige à employer la fonction "eval()"
sur le contenu récupéré, pour pouvoir l'exploiter.
Pardon de me répondre à moi-même, mais je viens de voir une autre
possibilité que le "evil/eval" !
En fait, on peut cloner le contenu dans un nouvel élément <script> créé
dynamiquement et ajouté dans le DOM.
Par exemple, on aurait le source HTML suivant, dont le deuxième script
permet de récupérer les paramètres du premier en les stockant dans
l'objet "extParams" :
<html>
<head>
<title>Test JS</title>
<script src="params.js">
{"message": "coucou !"}
</script>
</head>
<body>
<p>Valeur à récupérer : <span id="msg"></span></p>
<script>
var scriptTags = document.getElementsByTagName("script");
for (var i=0, len = scriptTags.length; i < len; i++) {
if (! scriptTags[i].src) continue;
if (scriptTags[i].src.indexOf("params.js") >= 0 ) {
var params = scriptTags[i].innerHTML;
var newScriptTag = document.createElement("script");
newScriptTag.innerHTML = "var extParams = " +
params + ";";
scriptTags[i].parentNode.appendChild(newScriptTag);
}
}
</script>
</body>
</html>
Et le script externe "params.js", qui peut ainsi disposer des propriétés
de l'objet "extParams", ici pour en incorporer une ("message") dans le
document en cours :
window.onload = function() {
var msgString = extParams["message"];
var msgContainer = document.getElementById("msg");
msgContainer.innerHTML = msgString;
}
Testé FF 5.0 seulement.
C'est sûrement un truc comme ça que Google a dû bricoler dans cette
bibliothèque.
Le hic, à mon avis, est que cela oblige à employer la fonction "eval()" sur le contenu récupéré, pour pouvoir l'exploiter.
Pardon de me répondre à moi-même, mais je viens de voir une autre possibilité que le "evil/eval" !
En fait, on peut cloner le contenu dans un nouvel élément <script> créé dynamiquement et ajouté dans le DOM.
Par exemple, on aurait le source HTML suivant, dont le deuxième script permet de récupérer les paramètres du premier en les stockant dans l'objet "extParams" :
<html> <head> <title>Test JS</title> <script src="params.js"> {"message": "coucou !"} </script> </head> <body> <p>Valeur à récupérer : <span id="msg"></span></p> <script> var scriptTags = document.getElementsByTagName("script"); for (var i=0, len = scriptTags.length; i < len; i++) { if (! scriptTags[i].src) continue; if (scriptTags[i].src.indexOf("params.js") >= 0 ) { var params = scriptTags[i].innerHTML; var newScriptTag = document.createElement("script"); newScriptTag.innerHTML = "var extParams = " + params + ";"; scriptTags[i].parentNode.appendChild(newScriptTag); } } </script> </body> </html>
Et le script externe "params.js", qui peut ainsi disposer des propriétés de l'objet "extParams", ici pour en incorporer une ("message") dans le document en cours :
window.onload = function() { var msgString = extParams["message"]; var msgContainer = document.getElementById("msg"); msgContainer.innerHTML = msgString; }
Testé FF 5.0 seulement.
C'est sûrement un truc comme ça que Google a dû bricoler dans cette bibliothèque.
Je ne sais pas pourquoi ils ont choisi cette méthode plutôt que de passer les paramètres dans l'url, comme dans cet exemple : <script src="monScript.js?param1=val1¶m2=val2"></script>
Moi je vois tout de suite ;-) un seul .js dans le cache quelques soient les params
Effectivement, si le futur standard est implémenté tel quel, ils vont avoir quelques problèmes avec leur bibliothèque, à moins que j'aie loupé un truc.
D'autant qu'on peut lire sur le Draft HTML5 : Editor : Ian Hickson, Google, Inc
Je ne sais pas pourquoi ils ont choisi cette méthode plutôt que de passer
les paramètres dans l'url, comme dans cet exemple :
<script src="monScript.js?param1=val1¶m2=val2"></script>
Moi je vois tout de suite ;-)
un seul .js dans le cache quelques soient les params
Effectivement, si le futur standard est implémenté tel quel, ils vont
avoir quelques problèmes avec leur bibliothèque, à moins que j'aie loupé
un truc.
D'autant qu'on peut lire sur le Draft HTML5 :
Editor : Ian Hickson, Google, Inc
Je ne sais pas pourquoi ils ont choisi cette méthode plutôt que de passer les paramètres dans l'url, comme dans cet exemple : <script src="monScript.js?param1=val1¶m2=val2"></script>
Moi je vois tout de suite ;-) un seul .js dans le cache quelques soient les params
Effectivement, si le futur standard est implémenté tel quel, ils vont avoir quelques problèmes avec leur bibliothèque, à moins que j'aie loupé un truc.
D'autant qu'on peut lire sur le Draft HTML5 : Editor : Ian Hickson, Google, Inc
