20 ASTUCES POUR PROGRAMMEURS JAVASCRIPT AVANCÉS
007Julien
Messages postés
276
Date d'inscription
mercredi 22 septembre 2010
Statut
Membre
Dernière intervention
8 janvier 2014
-
3 mars 2011 à 23:51
jdmcreator Messages postés 647 Date d'inscription samedi 30 décembre 2000 Statut Membre Dernière intervention 20 juillet 2012 - 28 mars 2011 à 22:47
jdmcreator Messages postés 647 Date d'inscription samedi 30 décembre 2000 Statut Membre Dernière intervention 20 juillet 2012 - 28 mars 2011 à 22:47
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/52882-20-astuces-pour-programmeurs-javascript-avances
https://codes-sources.commentcamarche.net/source/52882-20-astuces-pour-programmeurs-javascript-avances
28 mars 2011 à 22:47
24 mars 2011 à 10:13
24 mars 2011 à 02:05
Pardonnez cette absence, maladie puis reprises de travaux scolaires m'a forcé à m'éloigner de ce site ;) En fait, j'ai mal suivi vos discussions, et je suis un peu perdu ! J'approuve avec Kimjoa : " Tu aurais pu nous fournir une fonction toute propre ;)" ;D
16 mars 2011 à 14:22
Enfin bon je suis sur que jdmcreator va s'en occuper et mettre à jours ces astuces!
a+
15 mars 2011 à 14:28
Effectivement, le tableau associatif que constitue le $_GET en PHP présente le défaut majeur de «tuer» les valeurs multiples pourtant transmises dans la chaîne d'adresse par l'envoi du formulaire et seul l'artifice que constitue l'utilisation d'un nom suivi de deux crochets droits [] (en forme d'affectation à une variable tableau) permet de surmonter cette lacune.
La fonction getUrlVar proposée ne reprend pas cet artifice mais concatène les valeurs multiples dans une liste d'éléments séparés par des virgules (ce qui pourrait présenter d'autres inconvénients - l'introduction du séparateur en argument mettrait en garde l'utilisateur).
NB : Un oubli malencontreux dans l'expression régulière interdit la restitution du premier paramètre par la seconde fonction. Celle-ci semble d'ailleurs inutile, la première pouvant prendre, sous forme d'objet, la forme d'un tableau associatif rendant les mêmes services.
Enfin, ayant sauvegardé le script proposé dans un répertoire astuces&rechrerches, l'expérience montre que l'emploi de window.location.search paraît préférable à celui de window.location.href (à cet égard le décodeURIComponent sur les noms des paramètres constitue effectivement une précaution utile bien que non indispensable).
Merci en toute hypothèse pour cette analyse approfondie et pour ces exemples d'utilisation de fonctions de «callback» avec la méthode replace.
14 mars 2011 à 01:51
#11 : C'est principalement pour faire des remplacements à la volée, il est très complexe de générer un RegExp en fonction de l'utilisateur. Petit exemple : dans l'exemple du code, si on met dans le champ TEXTE "a.b", si on génère un RegExp à la volée, cela donnera : new RegExp("a.b","gi") . Seulement, le . en RegExp signifie n'importe quel caractère. Même chose pour les symboles []$^\ etc...
Pour ta fonction du $GET, ça semble très bon, mais je ne savais pas que "instanceof" fonctionait avec tous les navigateurs. Maintenant que je sais, je vais l'utiliser ;)
Pour l'indentation, c'est évident, mais j'avoue que se sera très long, surtout que j'ai déjà plusieurs modifications à faire.
Merci de ton commentaire ;)
13 mars 2011 à 23:15
Déjà comme dit plus haut la méthode eval ne fait rien d'autre que un block try{}catch(){}.
Je vois pas l'utilité de #5 par rapport à un getElementsByTagName('*')
Le #11 aussi... Les expressions régulière c'est quand même super pratique, pourquoi vouloir s'en passer?
La fonction GET est partiellement fausse. Enfin en php si il y a des paramètre en doublon, alors ça devient un tableau. De plus il faut utiliser la fonction decodeURIComponent.J'ai amélioré une fonction du web, voilà ce que ça donne
(function(){
var reg = /[?&]+([^=&]+)=?([^&]*)/gi,
href = window.location.href;
getUrlVars = function(){
var map = {};
href.replace(reg, function(match, key, value) {
key = decodeURIComponent(key);
value = value ? decodeURIComponent(value) : true;
map[key] ? map[key] instanceof Array ? map[key].push(value) : map[key] = [map[key], value] : map[key] = value;
});
return map;
}
getUrlVar = function(param){
var reg = new RegExp("&"+param+"=([^&]*)", "gi"),
res;
href.replace(reg, function(match, value) {
value = value ? decodeURIComponent(value) : true; res ? res instanceof Array ? res.push(value) : res [res, value] : res value;
});
return res;
}
})();
Sinon il y a pas mal de truc intéressante, notamment l'exploitation du DOM pour parser des string .... c'est plutôt ingénieux !
ps : indente ton code ! ça pique les yeux sans ;)
13 mars 2011 à 21:09
Il est alors possible d'adapter le contenu à la page à cet appel...
13 mars 2011 à 20:14
PS :
Get=function(){var i,t=window.location.search.substring(1).split(/&/g),;for(i in t) {u=t[i].split(/=/);u[0]=decodeURIComponent(u[1])}}
le "new" avant function est inutile, la variable "l" aussi, car utilisé une seule fois, et de toute façon "for(i=0;i<l;i++)" peut être remplacer par "for(i in t)"
Aussi, pourquoi "this[u[0]]" et non pas juste u[0] ?
13 mars 2011 à 13:27
Je reste néanmoins convaincu que la meilleure expression du get, en javascript, consiste à créer un objet avec le code suivant (à insérer par exemple dans un script outils.js).
Get=new function(){var i,t=window.location.search.substring(1).split(/&/g),l=t.length,u;for(i=0;i<l;i++) {u=t[i].split(/=/);this[u[0]]=decodeURIComponent(u[1])}}
Ce script d'encombrement réduit met à disposition un objet permettant d'envisager le passage d'un nombre, il est vrai limité, de paramètres entre les pages d'un site sans recours au PHP.
9 mars 2011 à 09:31
Dans ton message du 08/03/2011 à 02:50:49, tu as "compressé manuellement et beautifier".
Si le code n'est déjà plus facile à lire, ça ne sert à rien de le "beautifier"...
Sans même parler de pédagogie, un code avec des noms de variables explicites est plus facile à maintenir.
9 mars 2011 à 02:15
Si j'ai beautifier le code, c'est pour que n'importe qui puisse le lire, n'oubliez que CodeS-SourceS est à la base pédagogique et le résultat ne compte pas plus que le code. Si vous voulez placer ce code sur votre site, compressez-le, c'est bien mieux ainsi. Mais le but de ma source est de présenter différentes astuces où le code est plus important que le résultat. Dans les boîtes destinés à contenir le code Source des astuces dans "index.html", tous les codes sont plus ou moins beautifier pour qu'on puisse les lire. C'est ainsi sur toutes les documentations ;)
Mais nous nous éloignons un peu du sujet et entrons dans un sujet peu important ;)
9 mars 2011 à 02:09
Mais, l'objet premier d'un code c'est l'efficacité. C'est en toute hypothèse ce que j'ai recherché en produisant, à ma connaissance un «compte est bon» inédit en javascript (voir le code http://www.javascriptfr.com/codes/COMPTE-EST-BON_52331.aspx) ou encore un «Puissance 4» relativement performant (voir http://www.javascriptfr.com/codes/PUISSANCE_52840.aspx).
Alors oui, c'est difficile à lire mais un beau site cela se mérite et nécessite parfois quelques efforts vous dirons les architectes, les alpinistes et bientôt les maîtres-toiles...
N'oublions donc pas qu'un code n'est pas destiné à être affiché. Que ceux qui en douteraient encore veuillent bien consulter le source de Google.
9 mars 2011 à 00:41
function j_g(n){var i,t=window.location.search.substring(1).split(/&/g),u,v=[];for(i in t){u=t[i].split(/=/);v.push(u[1]);if(n==u[0])return u[1]}return v}
est assez difficile à lire ;) Évidemment, si tu veux le compresser pour le mettre sur ton site, aucun problème que tu le compresses, c'est plus rapide à charger. Si j'ai placer le code beautifier, il s'agissait plutôt pour qu'il puisse bien être affiché lorsque je le placerai dans le fichier d'astuces.
@Jordmund : Si c'est à moi que tu parles, alors pour moi le code n'est pas du tout illisible, je n'utilise que des moyens dits "de base". Oui, j'ai en effet supprimé quelques octets, sur un petit code comme celui-ci ce n'est pas très grave, sur un plus gros code comme JQuery.js , crois-moi que ces petits octets ici à gauche et à droite, finissent par faire beaucoup. Pourquoi nous empêcher de réduire notre code, ça n'a jamais été mauvais ;) ?
8 mars 2011 à 12:07
8 mars 2011 à 11:04
return !n?v:'';
8 mars 2011 à 10:27
8 mars 2011 à 09:50
Pour son efficacité en javascript, j'aurais plutôt tendance à compresser ma proposition (JSMin de Douglas Crockford http://jscompress.com/ ou Dean Edwards compressor http://javascriptcompressor.com/). Celle-ci passerait alors de 188 à 175 octets (gain de 7%) plutôt que de retenir celle proposée de 229 octets (perte de 23%).
Maintenant le test consistant à récupérer une variable non définie est facile à faire il donne sans surprise une valeur non renseignée dans le tableau et une valeur undefined sinon.
8 mars 2011 à 09:38
Pour ce qui est de ta fonction j_g avec "http://example.com?test=1&test2=2&test3&test4=4" et test3: u[1] n'existe pas, la fonction renverra null.
Une remarque sur cette fonction: si la variable get recherchée n'existe pas, ça va aller au bout de la boucle for et retourner le tableau des variables, je ne suis pas sûr que ça soit forcément le comportement que tu attendais.
8 mars 2011 à 02:50
Ton code compressé manuellement puis beautifier (http://jsbeautifier.org/) devrait donner environ ceci :
function j_g(n) {
var i, t = window.location.search.substring(1).split(/&/g),
u, v = [];
for (i in t) {
u = t[i].split(/=/);
v.push(u[1]);
if (n == u[0]) return u[1];
}
return v;
}
Reste à savoir si cela fonctionne avec http://example.com?test=1&test2=2&test3&test4=4
Pourrais-je récupérer test3 ;) ?
@Jormund : En effet, il y a bel et bien deux coquilles et une erreur, mea culpa, je suis en train de corriger
@2e commentaire de 007Julien : En fait au départ, c'était de trouver différentes manières d'émuler "eval()" pour trouver la plus rapide, eval() me semblant un peu lente, je cherche encore, il me reste plusieurs tests à faire, mais j'ai décidé de la mettre comme première astuce pour voir si d'autres personnes, comme toi, avait des solutions différentes à me proposer ;)
@3e commentaire de 007Julien : c'est un fait ;)
7 mars 2011 à 13:17
Ces valeurs doivent, en effet, être supposées avoir subi le traitement inverse lors de l'écriture de l'adresse.
7 mars 2011 à 12:00
J'utilise personnellement pour effectuer cela:
function callSomething(code)
{
var tempFunction = new Function(code);
return tempFunction();
}
Par contre je ne sais pas si il est compatible tous navigateurs, alors que c'est probablement le cas de ton code.
J'évoquais d'autres utilisation de eval qui ne fonctionnent pas avec ton code, il y a par exemple:
var a = eval("[1,2,3]");
ou encore
var a = eval("{test:'toto'}")
J'avoue aussi ne pas bien voir l'intérêt de ta fonction par rapport à:
function evalWithCatch(code)
{
try
{
return eval(code);
}
catch(e)
{
return undefined;
}
}
7 mars 2011 à 11:45
Il y a deux coquilles dans ta page index.html:
Le code javascript affiché pour le #3 est celui du #4.
La description du #20 est celle du #19.
Ensuite j'ai une questions :
Pourquoi passer par une input pour les #3 et #4 ?
Je ne comprends pas la différence avec un simple return tn.replace(/[\n]+/gi,"");
Une remarque sur le #8: pour que le #8 fonctionne il faut utiliser la propriété href (une balise a n'a pas d'attribut "src").
Et enfin, pour contribuer à la discution sur la récupération des paramètres get, j'utilise personnellement un code similaire à 007Julien pour obtenir un tableau associatif à partir d'une url:
function getParamsFromUrl (url)
{
var params = {};
var index = url.indexOf('?');
if(index > -1)
{
url = url.split('?')[1];
url = url.split('#')[0];
url = url.split('&');
var sTmp = "";
for(var i in url)
{
sTmp = url[i];
sTmp = sTmp.split('=');
params[sTmp[0]] = sTmp[1];
}
}
return params;
}
4 mars 2011 à 23:33
S'il convenait de répondre aux objectifs maintenant précisés, la fonction suivante paraîtrait plus adaptée tout en restant plus concise :
<script type="text/javascript">
function j_g(n){var i,t=window.location.search.substring(1).split(/&/g),l=t.length,u,v=[];
for (i=0;i<l;i++) {u=t[i].split(/=/);v[v.length]=u[1];if (n==u[0]) return u[1];}
return v;
}
alert(j_g())
alert(j_g('truc'))
</script>
Maintenant si la compression consiste à réduire les noms des variables, je pense avoir convenablement préparé le terrain...
Cordialement.
4 mars 2011 à 19:15
Ta fonction est très intéressante, il ne resterait plus qu'à la compresser. Seulement, elle n'est pas identique à $GET() car cette dernière possède deux fonctions :
Pas d'arguments : Retourne un tableau de toutes les valeurs
Argument : Retourne la valeur recherchée
4 mars 2011 à 11:40
Pour le get en javascript imitons le php jusqu'au tableau associatif, s'il existe !
<script type="text/javascript">
var jsc_get=new function(){var i,t=window.location.search.substring(1).split(/&/g),l=t.length,u,v={},w=0;
for (i=0;i<l;i++) {u=t[i].split(/=/);v[u[0]]=u[1];w=1}
return w?v:null;
}
// Avec un vrai tableau associatif
c='';for (i in jsc_get) c+=' '+i+':'+jsc_get[i];alert(c);
if (jsc_get && jsc_get['truc']) alert(jsc_get['truc']);
</script>
4 mars 2011 à 00:06
Relis mon commentaire :P
4 mars 2011 à 00:04
3 mars 2011 à 23:57
Dans le premier cas, la ville chez moi fonctionne, mais cela dépend du pays. Pour certains, il n'est pas possible de le récupérer. Moi, j'habite au Canada et cela fonctionne, mais peut-être que ce que tu dis est vrai. Mais l'IP, lui, est exploitable.
#16 : C'est qu'il existe plusieurs exceptions, c'est la fonction que j'utilise mais si vous en avez une autre équivalente, je peux la modifier
#18 : C'est vrai
Dans le dernier cas : C'est pourquoi j'ai mentionné d'aller voir la documentation afin de voir quels propriétés utilisés pour recueillir l'élément, selon le navigateur
3 mars 2011 à 23:51
La fonction GET en javascript (#16) permettant de récupérer les variables de l'url est un peu laborieuse lorsque deux splits (l'un sur les &, l'autre les =) sur window.location.search.substring(1) suffisent pour disposer de tous les éléments.
Sinon les valeurs par défaut (#18) des champs de texte (textarea) s'appliquent aussi aux autres champs de texte (inputs de type texte) ce qui permet d'utiliser ces champs pour décrire leur contenu et de reprendre cette description lors de la perte de focus avec un champ vierge.
Enfin, (last but not least) l'instruction document.elementFromPoint(Number x,Number y) semble a peu près acceptée par les navigateurs les plus courants encore que des incertitudes subsistent sur la nature des coordonnées à utiliser (voir la page http://www.quirksmode.org/dom/w3c_cssom.html#documentview).