Discussion :

[sekaijin]

Bonjour pourquoi utiliser un texte là ou une référence fonctionne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

window.setTimeout(function () {alert("toto")}, 300)

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
toto = function () {alert("toto")};
window.setTimeout(toto, 300)

la dernière version compressée donne la même chose ou avec obfuscator

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

eval(function(p,a,c,k,e,r){e=String;if(!''.replace(/^/,String)){while(c--)r[c]=k[c]||c;k=[function(e){return r[e]}];e=function(){return'\\w+'};c=1};while(c--)if(k[c])p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c]);return p}('0=1(){2("0")};3.4(0,5);',6,6,'toto|function|alert|window|setTimeout|300'.split('|'),0,{}))

ce qui fonctionne toujours très bien.

de façon générale mieux vaut utiliser une référence qu'un texte qui interprété donnera un appel à la référence.

par exemple ne pas faire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

function toto() {alert("toto")};

Code html :

Sélectionner tout - Visualiser dans une fenêtre à part

<a id='truc' onClick='toto()'>...

qui sera évalué pour créer dynamiquement une fonction qui sera placé comme membre de l'élément truc
le navigateur va générer ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
function toto() {alert("toto")};
document.getElementById('truc').onclick= function() {toto();};

mais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

document.getElementById('truc').onclick=function() {alert("toto")};

ou encore

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
function toto() {alert("toto")};
document.getElementById('truc').onclick=toto;

en conclusion pensez aux références
A+JYT

[sdamart]

Je constate souvent dans des code JS d'étudiant une erreur assez courante

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

document.getElementById("truc").onclick=function()....

C'est une erreur, en fait il ne faut pas affecter une fonction à un évènement, mais l'associer.

Je vous suggère l'implémentation d'un objet : "eventObserver"

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
EventObserver={
	/**
	* Ajoute un événement à un élément du DOM
	* @param DOMELement HTMLElement élément du DOM sur lequel l'évenement sera ajouté
	* @param evtName string Nom de l'élément auquel l'évenement sera associé
	* @param fn function fonction à associer à l'évenement
	* @author Sébastien DAMART
	* @author Cécil Cordheley
	*/
	addEvent:function(DOMElement,evtName,fn){
	///<summary>Ajoute un événement à un élément du DOM</summary>
	///<param type="HTMLElement">DOMElement</param>
	///<param type="string">evtName</param>
	///<param type="fonction">fn</param>
	//On associe l'événement
		if(DOMElement.attachEvent)
			DOMElement.attachEvent("on"+evtName,fn,false);
 
		else
			DOMElement.addEventListener(evtName,fn);
 
	//On stock l'événement dans un tableau associer au HTMLElement passer en paramètre
	if(DOMElement.Events==undefined)
		DOMElement.Events=new Array();
	if(DOMElement.Events[evtName]==undefined)
		DOMElement.Events[evtName]=new Array();
	DOMElement.Events[evtName].push(fn);
 
	},
	detachEvent:function(DOMElement,evtName,fn){
		if(typeof fn =="integer")//si le troisième paramètre correspond à un entier
		{
			//recuperer la fonction à l'index passer en paramètre
			var handler=DOMElement.Events[evtName][fn];
		}else{
			var i=0;
			var t=false;
			while(i<DOMElement.Events[evtName].length&&!t)
			{
				if(DOMElement.Events[evtName][i]==fn){
					t=true;
				}else
					i++;
			}
			var handler=(t)?fn:null;
		}
		if(handler){
			if(DOMElement.removeEventListener)
				DOMElement.removeEventLister(evtName,handler);
		}
	}
 
}

Au cas ou je laisse un Zip pour expliquer comment ça marche

[hefeust]

bonjour à tous !

mon point de vue sur les javascript est qu'avant, on se contentait de coller ("scotcher") des petits bouts de script sur la page HTML, tels des post-its sur un paperboard. Dorénavant, la bonne approche est de considérer le JS comme formant une application à part entière et qui utilise la page et le DOM comme son entrée/sortie (ou du moins son effet de bord) principal.

Bien sûr me direz vous elle échange également avec le clavier et la souris, avec divers évènements, et avec le serveur via XHR, mais pensez app toute faite comme le sont certains clients de mail bien connus, ou les jeux vidéo qui fleurissent un peu partout.

Ainsi on peut appliquer des principes comme le MVC ou le MVR pour faire son développement.

Voilà pour la théorie . Pour la pratique cela se complique un peu. Ca manque cruellement de tutoriels bien faits et en ligne (sur développez peut être ?) et j'ai l'impression que toutes mes recherches en direction d'une doc construite me renvoient systématiquement sur la page de tel ou tel éditeur anglophone qui vend un bouquin...

Donc j'attends avec impatience un ou des tutos sur ce site mais il faudra y trouver :
- bootstrap de l'appli et structure de fichiers sous jacent
- module pattern, include/import de fichiers
- utiliser correctement les closures
- les données comment les gérer et les découpler au maximumu de la manip de DOM pour la Vue
- concevoir des widgets en interactions les uns avec les autres et/ou avec le serveur

Voilà, à vos stylos et claviers , les auteurs, je ne manquerai pas de vous lire...

PS : J'ai remarqué quand même depuis quelques temps des bibliothèques qui sortent du lot (exemple : CraftyJS, Quintus... pour les jeux) qui ne cherchent plus systématiquement à écrire des classes (Java, PHP, C++) pour faire de l'héritage, mais qui fonctionnent plutot en "share" (partage) de composants. Cela me semble plus proche de la philosophie de JavaScript (partage de prototype)

on a donc une approche 'partage' (has-A) de javascript (== horizontal) qui oblige à se changer l'esprit par rapport à l'héritage (de qualités mais aussi de défauts...) "is-A" (== vertical) qu'on pratiquait avant ... tiens c'estr étonnant, c'est ce qu'on fait dans les réseaux sociaux, le partage...

en attendant les tutoriels (bis) merci et bonne journée !

[Lcf.vs]

Moi, ça me frappe, de voir des choses comme ceci :

[*]Tolérance zéro sur les globales : utiliser pour ça un objet statique, c'est plus propre et plus sécurisé (et quand je dis globales, je ne parle pas que des variables : les fonctions aussi !)

...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
function displayWindow(sWindowName)
{
}

Pour moi, la seule façon de déclarer proprement une fonction dans le scope courant, c'est :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
var fct;
fct = function fct() {
	// ce que vous voulez...
};

1. On déclare d'abord la variable
2. On assigne une valeur à cette variable (en l’occurrence, une fonction)
3. Dans cette déclaration, on nomme la fonction

Pourquoi nommer cette fonction? simple...

Imaginons que cette fonction soit un constructeur et que l'on en récupère une instance... faites un console.log(instance), avec ou sans avoir nommé votre fonction, vous verrez...

Edit : Pour en savoir plus, http://www.developpez.net/forums/d13...n/#post7107219

[sekaijin]

Je ne vois pas l'intérêt de nommer la fonction

c'est même source d'erreur

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
var fct = function ftc() {};
var a = new fct();
 
a.__proto__; //retourne ftc
a.__proto__.constructor; //retourne  function ftc() {}
ftc; // retourne undefined  <==== gasp c'est pourtant le nom retourné au dessus
a.__proto__.constructor.name; //retourne  "ftc"
 
a.__proto__.constructor == fct; // retourne true fct est bien le constructeur de a alors que ftc qui est le nom que porte le constructeur est un constructeur qui n'existe pas.

il y a pire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
var A = function C1() {this.a = 45};
var B = function C1() {};
...
a = new A();
b = new B();
 
// a et b sont-il des objets de même type (même constructeur) ?
a.__proto__.constructor == b.__proto__.constructor;
//reponse non le test retourne false pourtant a et b sont vu comme des objets de type C1
 
//on refait le test sous une autre forme
a.__proto__.constructor.name == b.__proto__.constructor.name;
//reponse oui le test retourne true a et b sont vu comme des objets de type C1

en clair renseigner le nom du constructeur n'est valable qu'a titre informatif et il ne faut surtout pas en tenir compte
je préfère encore

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
var fct = function () {};
var a = new fct();
 
a.__proto__; //retourne object
a.__proto__.constructor; //retourne  function () {}
fct; // retourne //retourne  function () {} la même chose qu'au dessus
a.__proto__.constructor.name; //retourne  ""
 
a.__proto__.constructor == fct; // retourne true fct est bien le constructeur de a.

tout cela est bien plus homogène

A+JYT

[Lcf.vs]

Sekaijin> J'attendais ta réaction, tiens... j'étais sûr qu'elle serait intéressante...

Pour ton premier exemple, il est tout à fait normal que ftc retourne undefined.

Il faut bien comprendre que la déclaration du nom d'une fonction n'est pas liée à la variable dans laquelle cette fonction est affectée (sauf dans le cas d'une globale, car l'interpréteur déclare implicitement une variable de ce nom).

Dans ton 2ème exemple, tu redéclares une fonction du même nom, donc les résultats obtenus sont logiques...

Une fonction, une fois déclarée, ne devrait pas (selon moi) être redéclarée, cela ne peut qu'amener des problèmes...

En gros, c'est à chacun de faire attention à ce qu'il fait...

Cette façon de faire a un avantage indéniable, une plus grande aisance pour la correction de bugs. D'ailleurs, les objets natifs sont tous nommés...

Ta solution, via __proto__ fonctionne, c'est vrai... mais elle n'est pas standard.

[Lcf.vs]

De plus, ta méhode via __proto__ nécessite de déjà avoir créé une instance de ton constructeur...

[sekaijin]

mon propos est que le nom n'est qu'un nom et qu'il ne doit surtout pas être exploite.

ça peut effectivement aider à y voir clair lors du debug mais ce n'est pas avec le nom qu'il faut travailler.

mon premier exemple montre qu'une simple petite erreur ftc à la place de fct et le code basé sur le nom ne fonctionne plus alors que celui qui ne s'intéresse qu'aux objet continu de fonctionner.

mon deuxième exemple ne montre pas le redéfinition d'une fonction mais bien qu'on meut définir deux fonctions qui ont le même nom. du coup si on base la manipulation des objet en se basant sur le nom du constructeur on vas dans le mur.


quant à la redéfinition de fonction c'est très utile.
exemple j'ai un bouton et je veux que lorsqu'on clique dessus la première fois il me crée un objet
et les fois suivante il utilise la méthode test() de l'objet.

la méthode simple consiste à écrire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
onclick = function() {
  if (undefined == typeof this.myObject) {
    this.myObject = new Constructor();
  } else {
    this.myObject.test();
  }
}

on a bien la création au premier appel et l'utilisation de la méthode test les autres fois. mais on a aussi à chaque passage l'exécution du test.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
onclick = function() {
  this.myObject = new Constructor();
  this.onclick = function() {
    this.myObject.test();
  }
}

Cette fois on ne fait aucun test. au premier appel on crée l'objet et on redéfinit la méthode
les coups suivant on ne fait qu'appeler test. c'est simple et c'est efficace.

la mutabilité des objets en javascript est un gros atout par rapport au langage à base de classe. il suffit de l'utiliser à bon escient.

bien pratique un fonction getUser() qui affiche un formulaire tant que l'utilisateur n'est pas loggé et qui est redéfinie pour retourner l'identité du user lorsqu'il est loggé pas de test pas de code inutile juste la bonne définition de la fonction en fonction du contexte.

A+JYT

[Lcf.vs]

Hum, oui... mais je n'ai jamais prétendu qu'il faille utiliser le nom d'un constructeur en guise de référence de contrôle, ce serait en effet une lourde erreur, de par la mutabilité du JS.

Sérieusement, pour moi, il serait préférable d'attacher une autre fonction à ton bouton, si celui-ci n'a plus le même rôle...

Perso, le système (orienté classes) que je développe actuellement est justement plus strict sur ce point... j'espère vraiment que quelqu'un saura me diriger pour l'optimisation de mon parser, que je puisse vous le présenter...

[Watilin]

Lcf, je pense que tu en as déjà entendu parler, mais je le dis au cas où : il existe en JavaScript une directive "use strict";. John Resig, le créateur de jQuery, a écrit un billet dessus

Personnellement, je préfère déclarer mes fonctions avec function plutôt que var car je sais que de toute façon elles seront dans le scope local. Ça fait, à mon goût, un code plus lisible pour le même résultat. Ensuite, je leur donne toujours un nom, après le mot-clé function, car comme vous l'avez dit, ce nom apparaît dans la pile lors du débogage.

Ce qui se passe est plutôt simple : le débogueur utilise la propriété name qu'ont toutes les fonctions. Quand la fonction a été déclarée sans nom, sa propriété name est une chaîne vide "".

Code console :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
>>> var x = function fun( ){}
undefined
>>> x.name
"fun"
>>> var y = function( ){}
undefined
>>> y.name
""

Pour changer de sujet, j'ai découvert il y a pas plus de 3 jours l'outil JSLint, qui est une sorte de « relecteur » JavaScript, à défaut d'être un correcteur. Il met en évidence certaines erreurs et mauvaises pratiques.
J'ai aussi découvert que Douglas Crockford a écrit des conventions de codage pour JavaScript. Cela dit, j'ai adopté les miennes et je les aime bien et, après tout, ce n'est pas très différent

[Lcf.vs]

Watilin :

Comme je le dis ici, le but est d'avoir un code propre et uniforme, avec de chouettes petits avantages.

[sekaijin]

Sérieusement, pour moi, il serait préférable d'attacher une autre fonction à ton bouton, si celui-ci n'a plus le même rôle...

attache signify d'avoir défini cette fonction.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
onclick = function() {
  this.myObject = new Constructor();
  this.onclick = function() {
    this.myObject.test();
  }// après l'exéution de cette ligne la méthode d'origine est déchargée de la ram
}

devient

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
fonction A() {
  this.myObject = new Constructor();
  this.onclick = B; //on attache une autre fonction 
}
fonction B() {
    this.myObject.test();
}
onclick = A

que l'on utilse des évent listener ou directement le onclick il faut avoir défini les fonctions. outre que le code n'en est pas plus lisible (c'est marginal) les fonctions A et B sont défini et le restent. après le premier appel A reste une fonction défini donc en mémoire mais elle n'est plus utilisée. un code mort inutile dans la mémoire.

je préfere les fonction annonyme directement définie sur le handler. ainsi lorsqu'on attache une nouvelle fonction annonyme l'anciene n'étant plus référencé (attaché à une closure) le moteur js la décharge de la ram.

A+JYT

[Lcf.vs]

Je comprends ton point de vue, néanmoins je préfère le côté réutilisable des éléments déclarés.

Je pense, notamment, à mon premier chat multi-comptes, en JS, où on pouvait se connecter depuis plusieurs comptes dans la même page, switcher de l'un à l'autre, changer de discussion, ..., le tout, sans avoir à recharger les messages et paramètres déjà calculés.

Tu me diras qu'il suffit de déclarer une seule fonction (la tienne) et de l'attacher au onclick, afin qu'elle puisse resservir... mais cela signifierait qu'à chaque fois ta fonction équivalente à B est recréée...

Bref, ce que tu as gagné en ressources, tu le reperds à chaque réutilisation...

Après, évidemment, ça dépend de l'utilisation que l'on en fait...

[Kaamo]

Ce n'est pas vraiment une bonne pratique mais plus une astuce sympa.
Uniquement dans Chrome à priori, pour afficher un tableau d'objets dans un format plus lisible, sous forme de tableau :

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
var monTableauDobjet = [
  {
    "id": 58,
    "value": "héhé"
  },
  {
    "id": 59,
    "value": "hoho"
  },
  {
    "id": 60,
    "value": "huhu"
  }
];
console.table(monTableauDobjet);

Testé sous Chrome Version 30.0.1599.101 m / dans un nouvel onglet (chrome://newtab)

[sekaijin]

non ça ne marche pas avec chrome

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
> var monTableauDobjet = [
  {
    "id": 58,
    "value": "héhé"
  },
  {
    "id": 59,
    "value": "hoho"
  },
  {
    "id": 60,
    "value": "huhu"
  }
];
> console.table(monTableauDobjet);
TypeError: Object #<Object> has no method 'table'

voici le méthode définies en standard par chrome pour l'objet console

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
console
Object {log: function, debug: function, info: function, warn: function, error: function…}
assert: function (){}
count: function (){}
debug: function (){}
dir: function (){}
dirxml: function (){}
error: function (){}
group: function (){}
groupEnd: function (){}
info: function (){}
log: function (){}
profile: function (){}
profileEnd: function (){}
time: function (){}
timeEnd: function (){}
trace: function (){}
warn: function (){}
__proto__: Object

A+JYT

[Kaamo]

J'aurais dû mentionner la version de Chrome avec laquelle j'ai testé : Version 30.0.1599.101 m

J'ai bien table dedans :

Code javascript :

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
assert: function assert() { [native code] }
clear: function clear() { [native code] }
constructor: function Console() { [native code] }
count: function count() { [native code] }
debug: function debug() { [native code] }
dir: function dir() { [native code] }
dirxml: function dirxml() { [native code] }
error: function error() { [native code] }
group: function group() { [native code] }
groupCollapsed: function groupCollapsed() { [native code] }
groupEnd: function groupEnd() { [native code] }
info: function info() { [native code] }
log: function log() { [native code] }
markTimeline: function markTimeline() { [native code] }
profile: function profile() { [native code] }
profileEnd: function profileEnd() { [native code] }
table: function table() { [native code] }
time: function time() { [native code] }
timeEnd: function timeEnd() { [native code] }
timeStamp: function timeStamp() { [native code] }
trace: function trace() { [native code] }
warn: function warn() { [native code] }

Voici ma source : Chrome Dev Tools / Annonce d'Addy Osmani
Le ticket webkit
L'équivalent Firebug

[sekaijin]

ce n'est pas présent dans la version
Version 31.0.1650.57 m
qui pourtant à un n° suppérieur à
Version 30.0.1599.101 m

je pense que la page que tu site modifie le proto de la console
si je me mets sur le forum et que j'ouvre la console j'obtiens

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
>console
Object {log: function, debug: function, info: function, warn: function, error: function…}
assert: function (){}
count: function (){}
debug: function (){}
dir: function (){}
dirxml: function (){}
error: function (){}
group: function (){}
groupEnd: function (){}
info: function (){}
log: function (){}
profile: function (){}
profileEnd: function (){}
time: function (){}
timeEnd: function (){}
trace: function (){}
warn: function (){}
__proto__: Object

si j'ouvre le lien https://developers.google.com/chrome...#console-table er que je fais la même opératio j'ai

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
>console
Console {memory: MemoryInfo, debug: function, error: function, info: function, log: function…}
memory: MemoryInfo
__proto__: Console
constructor: function Console() { [native code] }
__proto__: ConsoleBase
assert: function assert() { [native code] }
clear: function clear() { [native code] }
constructor: function ConsoleBase() { [native code] }
count: function count() { [native code] }
debug: function debug() { [native code] }
dir: function dir() { [native code] }
dirxml: function dirxml() { [native code] }
error: function error() { [native code] }
group: function group() { [native code] }
groupCollapsed: function groupCollapsed() { [native code] }
groupEnd: function groupEnd() { [native code] }
info: function info() { [native code] }
log: function log() { [native code] }
markTimeline: function markTimeline() { [native code] }
profile: function profile() { [native code] }
profileEnd: function profileEnd() { [native code] }
table: function table() { [native code] }
time: function time() { [native code] }
timeEnd: function timeEnd() { [native code] }
timeStamp: function timeStamp() { [native code] }
timeline: function timeline() { [native code] }
timelineEnd: function timelineEnd() { [native code] }
trace: function trace() { [native code] }
warn: function warn() { [native code] }
__proto__: Object

je dirais que c'est le script https://developers.google.com/_stati...script_foot.js qui fais ça.

A+JYT

[Kaamo]

Bien vu ! J'avais testé dans un nouvel onglet Chrome qui doit embarquer aussi une console améliorée. Quoiqu'il en soit, c'est à surveiller car le rendu est pas mal pour débugger

[NoSmoking]

Bonjour,

Uniquement dans Chrome à priori

cela existe sous FireFox mais pas de souvenir depuis quand, avec la présentation suivante

[Kaamo]

Je crois que c'est grâce à Firebug. D'ailleurs Chrome s'en est inspiré apparemment.