Discussion :

[Hibou57]

Kikou les gens d'ici,

Une petite info pour ceux/celles qui ne l'ont pas encore découvert (je viens de le découvrir à l'instant) :

Bien que l'instruction setAttribute fonctionne apparement bien sous IE, il semble qu'elle ne fonctionne plus lorsqu'il s'agit de fixer un attribut de classe.

Sous IE, il ne faut donc jamais faire

Code JavaScript :

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

myElement.setAttribute ('class', 'aClass');

mais il est préférable (et même obligatoire) de faire en lieu et place

Code JavaScript :

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

myElement.className = 'aClass';

J'en ignore la raison :-/

Un autre phénomène similaire a d'ailleurs été plusieurs fois constatés sur ce forum-même, s'agissant de fixer des handlers d'événements. Dans ce cas également, setAttribute ne fonctionne plus, et il faut en passer par les propriétés associées, comme onclic, onkeyup, etc, ou par les instructions attachEvent/detachEvent.

à-bajour, à-breuvoir

[SpaceFrog]

en gros evitez setAttribute en toutes circonstances

[Hibou57]

en gros evitez setAttribute en toutes circonstances

Dans la majorité des cas, c'est possible, mais lorsque l'on utilise des attributs « fait maison » pour véhiculer certaines données par les attributs, alors getAttribute/setAttribute reste la seule solution.

1) Ne communiquez jamais à quelqu'un tout votre savoir...

Pour le moment ça va ? Je ne communique pas trop ?

[SpaceFrog]

heu je ne vois pas quand tu ne ppeux pas remplacer getAttribute / setAttribute ???
même pour les attributs perso (pas le bijoux de famille ...)

http://www.developpez.net/forums/sho...d.php?t=387462

[Hibou57]

[...]http://www.developpez.net/forums/sho...d.php?t=387462

Ca ressemble à ce que je fais, effectivement, des attributs codés dans un code source, qui doivent pouvoir êtres lus/modifiés/etc.

Mais je n'utilisais pas d'expression du genre « myObject.myAttribut », en pensant que setAttribut était plus portable. Bon, apparement, ça n'est pas portable sur FF, qui n'accepte que ce que j'ai mis entre guillemet.

Ca m'embête, parce que la forme même des attributs interdit cela : il ne sont pas compatible avec des identificateurs JavaScript valides. Donc pour IE, je suis obligé de me tenir à set/getAttribute, et pour FF... beh, j'espère que je trouverai une alternative, car sans cela, le portage s'avère compromis d'avance (je n'ai pas FF, alors je n'ai encore pas put m'y atteler, et le portage vers Opéra en général ne semble interesser personne, alors je ne me suis encore pas du tout occupé de cette question là).

Apparement, ça va pas être du coton.... Oouuuuuiiiin::!!!!

Demande: veuillez installer un smile Ouiiin sur ce forum s'y'ous plaît

[SpaceFrog]

a moins de faire une focntion ini qui définisse tous les attributs persos ...

[Shinuza]

[B][COLOR="DarkOrange"]

J'en ignore la raison :-/

Un autre phénomène similaire a d'ailleurs été plusieurs fois constatés sur ce forum-même, s'agissant de fixer des handlers d'événements. Dans ce cas également, setAttribute ne fonctionne plus, et il faut en passer par les propriétés associées, comme onclic, onkeyup, etc, ou par les instructions attachEvent/detachEvent.

à-bajour, à-breuvoir

La raison est simple, class fait partir des mots réservés pour javascript 2.0 (ECMAScript Edition 4)

Pour les events handlers, c'est très mauvais de les mettre directement dans le html, alors génerer un objet avec ces attributs...

Etant donné que le DOM est objet, autant utiliser les propriétés de l'objet pour y attacher des méthodes. Et encore mieux, passer par les gestionnaires d'évenement tels que ceux proposés par addEventListener et attachEvent (on trouve des scripts qui unifient les deux cf. le site de Dean Edwards)

[Hibou57]

La raison est simple, class fait partir des mots réservés pour javascript 2.0 (ECMAScript Edition 4)

Cale explique pourquoi la propriété s'appel className au lieu de class, mais ça n'explique pas pourquoi setAttribute ('class', ...); ne fonctionne pas. Il n'y a pas encore de chaîne reservée.

Pour les events handlers, c'est très mauvais de les mettre directement dans le html, alors génerer un objet avec ces attributs..

I agree with you, avec juste une précision : ce qui est mauvais, c'est de les mettre dans le source, et non pas de les mettre dans des attributs, parce que fixer un attribut avec setAttribute, fixer une propriété, ou fixer avec attachEvent, c'est la même chose. Le tout est de ne pas le placer dans le code source HTML, pour séparer la structure du document et son comportement, tout comme on doit séparer le contenu et sa présentation.... quand c'est possible.

[Shinuza]

Setattribute est évalué avant d'être appliqué, et cela donne une conversion d'une string vers une propriété, du coup la string devient un objet -> c'est un mot réservé.

De plus, c'est évidement par soucis de post compatibilité que la propriété s'appelle className et pas class.

Sinon pour les events ce n'est pas du tout la même chose.

Code :

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

1
2
3
4
5
6
7
			var test = document.getElementById('test');
 
			function alertIt() {alert(this);}
			function logIt() {this.style.color ='red'}
 
			test.onclick = alertIt;
			test.onclick = paintIt;

Sur ce schéma, étant donné que onclick est considéré comme un attribut de l'objet test, une fois que je le réaffecte j'écrase alertIt par paintIt.

Code :

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

1
2
3
4
5
			function alertIt() {alert(this);}
			function paintIt() {this.style.color ='red'}
 
			test.addEventListener('click',alertIt,false);
			test.addEventListener('click',paintIt,false);

Ici les deux marchent en même temps.
De plus on peut détacher des events, éviter les fuites de ram sous Ie, gérer plus facilement les inibiteurs, ect...

[Hibou57]

Setattribute est évalué avant d'être appliqué, et cela donne une conversion d'une string vers une propriété, du coup la string devient un objet -> c'est un mot réservé.

Mais non. La preuve en est qu'on peut affecter avec setAttribute, des attributs dont le nom ne pourrait pas être un identificateur JavaScript (cf. un des précédents message sur ce-même fil)

De plus on peut détacher des events, éviter les fuites de ram sous Ie, gérer plus facilement les inibiteurs, ect...

Peux-tu en dire plus sur attachEvent et les fuites de RAM sous IE ? Ca m'interesse beaucoup (je suis trés attentif aux questions de consomations de resources)

Sinon, c'est vrai que la différence de pouvoir lister plusieurs gestionnaire avec addEventListener est importante. Du moins pour les applications qui y sont sensibles. Dans la plupart des cas un seul gestionnaire d'événement est attaché, et il ne change le plus souvent pas au cours de la cession de l'application, parce que si le comportement change, ce sont le plus souvent des testes logique dans le gestionnaire qui s'en occupe (en fonction d'un état de l'application par exemple).

Mais merci d'avoir souligné pour addEventListener, ... je vais peut-être l'envisager pour certaines choses. Reste à savoir comment les chose se passe, si on ajoute des gestionnaire par addEventListener, et que l'on ajoute ensuite ou avant, un gestionnaire avec onxxxx = ....; Cette question peut être importante si on emploie des objet JavaScript concus sur mesure, car les objets fonctionnant en boite noire, on ne devrait pas avoir à se soucier de leur implémentation, et elle devrait donc être transparente à l'utilisation.

Par exemple, si un objet, à son initialisation (dans son constructeur), ajoute des gestionnaire avec addEventListener, et qu'ensuite l'utilisation faite de l'objet y ajoute un gestionnaire avec onxxxx = ....; il faudrait savoir comment cela se passe.

Sans compter que ça peut-être compliquer de fédérer des gestionnaire s'ignorant les un les autres.

Tout cela dit, je pense qu'il est préférable de n'employer qu'un seul gestionnaire finalement.