Liste/tableau "web 2.0"

Laurent Vilday

14/06/2006 à 05:00

-> outre les fonctions déclarées à l'intérieur d'une autre,

En js, une variable est intrinsèquement la même chose qu'une fonction.
Ce ne sont que des objets.

function foo() {}
est strictement la même chose que
var foo = function() {};

Donc de la même manière qu'on a le droit de créer des variables au sein
d'une fonction, on peut y créer également autant de fonctions qu'on
veut. Qui elles même peuvent créer d'autres fonctions et d'autres variables.

function foo()
{
function bar()
{
alert('private');
}
bar();
}
foo(); // => alerte : private

foo() est une fonction publique, accessible (et déclarée) depuis le
scope d'application global - l'objet window pour nos brouteurs favoris -
foo() faisant la même chose que window.foo() qui fait la même chose que
self.foo(), qui peux faire la même chose que top.foo() (suivant la
structure de frame du document), etc avec la folie des alias des noms
des fenêtres. A condition que aucun objet ne soit déclaré dans le
contexte d'exécution courant.

Par contre la fonction bar() qui est définie dans foo() est une fonction
privée qui n'est accessible que au sein du contexte de foo(). Seul foo()
peut accéder à cette function. C'est ce qui nous ouvre le monde
merveilleux des closures et de possibles fuites de mémoires (surtout
avec IE et la gestion des events mais pas seulement :p )

Une closure, c'est utiliser un objet (function, variable, etc) depuis un
autre contexte d'exécution que celui courant.

var name = 'ASM';
function foo()
{
function foobar()
{
var name = 'private';
}
function bar()
{
foobar();
alert(name);
name = 'updated';
foobar();
}
bar();
}
foo(); // alerte : ASM
alert(name); // alerte : updated.

On a modifié la variable hors du contexte de foo() et de bar();
Et même le double appel de foobar() depuis bar() ne peut affecter cette
variable puisque foobar() a declaré la variable name dans son contexte
(grace à var)

name est déclaré ni dans foo() ni dans bar() et pourtant la variable est
bien accessible. C'est une closure.

Ainsi on peut faire des trucs de fous

http://www.crockford.com/javascript/private.html

On peut, dans la même veine de trucs de maboules, s'amuser a faire des
fonctions anonymes privées qui s'auto exécutent lors de leur déclaration
(auto initialisation, préremplissages, etc)

var name = 'ASM';
function foo()
{
(function() { alert(name); name = 'updated'; }());
}
foo(); // alerte : ASM

Evidemment, dans cet exemple ca sert pas a grand chose voir même c'est
un peu couillon, mais c'est le principe qui compte :)

Pour en revenir à l'exemple d'origine qui t'as fait tiquer.
Grosso modo ça ressemblait à ça

function init(id)
{
function click(evt)
{
alert('click');
}
var elt = document.getElementById(id);
elt.onclick = click;
}

Hors c'est exactement la même chose que ce que tu as l'habitude de faire
qui est

function init(id)
{
var elt = document.getElementById(id);
elt.onclick = function (evt) { alert('click'); };
}

Et ca revient complètement a faire ceci :

function init(id)
{
var click = function (evt) { alert('click'); };
var elt = document.getElementById(id);
elt.onclick = click;
}

Le principal intérêt pour moi c'est de ne pas polluer mon global
namespace, mais au delà de ça, la possibilité d'utiliser des objets
privées est non négligeable, bien que je reconnaise l'utiliser peut
souvent dans ce sens.

On aurait évidemment pu faire à l'ancienne mode :) mais dès qu'on
commence à avoir plusieurs widgets sur la page, on s'en sort plus ou
tout du moins je m'en sors pas :)

function initEditeur(id)
{
var elt = document.getElementById(id);
elt.onclick = clickEditeur;
}
function initSlider(id)
{
var elt = document.getElementById(id);
elt.onclick = clickSlider;
}

function clickEditeur (evt) { alert('click'); };
function clickSlider (evt) { alert('click'); };
etc.

a créer plein de variables globales (fonction == variable == Object) on
créé une pollution des scripts qui tend à les rendre illisibles voir non
maintenables. Pire ça entraine très vite des écrasements si on ne
maitrise pas tous les morceaux de js incorporés à la page.

comment imaginer qu'on puisse faire ça :
this._selected = !this._selected;
et en plus (à ce que je comprends?) en affubler un TR

sur le même principe qu'on peut faire ça

var XXX = document.getElementById('monlien');
XXX.className = 'maCSS';
XXX.onclick = function(evt) { alert(this.className); };

ou plus simplement

var X = new Object();
X.ma_variable = 'ma valeur';

ou encore

var X = { ma_variable: 'ma valeur' };

On peut attribuer comme ça n'inporte quoi à n'importe quel élément ?

oui, puisque c'est pas à l'élément HTML que c'est assigné mais à l'objet
javascript qui référence cet élément. Et donc l'objet javascript se
comporte comme tous les autres objets.

Si on reprend l'exemple du lien <a> que j'évoquais dans mon message
précédent

<a id="monlien">

var XXX = document.getElementById('monlien');
XXX.ma_variable = 56789
XXX.onclick = function(evt)
{
// quand je suis ici
// this correspond à l'objet javascript qui s'appelle XXX
// this.ma_variable revient donc au même que XXX.ma_variable
// sauf que this est déclaré dans le contexte courant
// et il est plus facile, imo, de manipuler le contexte d'exécution
// courant plutot que des variables déclarées dans un autre contexte
// car c'est là que peuvent apparaitre des closures non controlées
// cf blabla d'avant pour le concept des closures
alert(XXX.ma_variable);
alert(this.ma_variable);
// les deux alertent 56789
};

C'est juste l'assignation d'une propriété à un objet.
Vala, j'espère ne pas avoir été trop confus, si c'est pas clair, comme
d'hab n'hésites pas.

--
laurent

-> outre les fonctions déclarées à l'intérieur d'une autre,

En js, une variable est intrinsèquement la même chose qu'une fonction.
Ce ne sont que des objets.

function foo() {}
est strictement la même chose que
var foo = function() {};

Donc de la même manière qu'on a le droit de créer des variables au sein
d'une fonction, on peut y créer également autant de fonctions qu'on
veut. Qui elles même peuvent créer d'autres fonctions et d'autres variables.

function foo()
{
function bar()
{
alert('private');
}
bar();
}
foo(); // => alerte : private

foo() est une fonction publique, accessible (et déclarée) depuis le
scope d'application global - l'objet window pour nos brouteurs favoris -
foo() faisant la même chose que window.foo() qui fait la même chose que
self.foo(), qui peux faire la même chose que top.foo() (suivant la
structure de frame du document), etc avec la folie des alias des noms
des fenêtres. A condition que aucun objet ne soit déclaré dans le
contexte d'exécution courant.

Par contre la fonction bar() qui est définie dans foo() est une fonction
privée qui n'est accessible que au sein du contexte de foo(). Seul foo()
peut accéder à cette function. C'est ce qui nous ouvre le monde
merveilleux des closures et de possibles fuites de mémoires (surtout
avec IE et la gestion des events mais pas seulement :p )

Une closure, c'est utiliser un objet (function, variable, etc) depuis un
autre contexte d'exécution que celui courant.

var name = 'ASM';
function foo()
{
function foobar()
{
var name = 'private';
}
function bar()
{
foobar();
alert(name);
name = 'updated';
foobar();
}
bar();
}
foo(); // alerte : ASM
alert(name); // alerte : updated.

On a modifié la variable hors du contexte de foo() et de bar();
Et même le double appel de foobar() depuis bar() ne peut affecter cette
variable puisque foobar() a declaré la variable name dans son contexte
(grace à var)

name est déclaré ni dans foo() ni dans bar() et pourtant la variable est
bien accessible. C'est une closure.

Ainsi on peut faire des trucs de fous

http://www.crockford.com/javascript/private.html

On peut, dans la même veine de trucs de maboules, s'amuser a faire des
fonctions anonymes privées qui s'auto exécutent lors de leur déclaration
(auto initialisation, préremplissages, etc)

var name = 'ASM';
function foo()
{
(function() { alert(name); name = 'updated'; }());
}
foo(); // alerte : ASM

Evidemment, dans cet exemple ca sert pas a grand chose voir même c'est
un peu couillon, mais c'est le principe qui compte :)

Pour en revenir à l'exemple d'origine qui t'as fait tiquer.
Grosso modo ça ressemblait à ça

function init(id)
{
function click(evt)
{
alert('click');
}
var elt = document.getElementById(id);
elt.onclick = click;
}

Hors c'est exactement la même chose que ce que tu as l'habitude de faire
qui est

function init(id)
{
var elt = document.getElementById(id);
elt.onclick = function (evt) { alert('click'); };
}

Et ca revient complètement a faire ceci :

function init(id)
{
var click = function (evt) { alert('click'); };
var elt = document.getElementById(id);
elt.onclick = click;
}

Le principal intérêt pour moi c'est de ne pas polluer mon global
namespace, mais au delà de ça, la possibilité d'utiliser des objets
privées est non négligeable, bien que je reconnaise l'utiliser peut
souvent dans ce sens.

On aurait évidemment pu faire à l'ancienne mode :) mais dès qu'on
commence à avoir plusieurs widgets sur la page, on s'en sort plus ou
tout du moins je m'en sors pas :)

function initEditeur(id)
{
var elt = document.getElementById(id);
elt.onclick = clickEditeur;
}
function initSlider(id)
{
var elt = document.getElementById(id);
elt.onclick = clickSlider;
}

function clickEditeur (evt) { alert('click'); };
function clickSlider (evt) { alert('click'); };
etc.

a créer plein de variables globales (fonction == variable == Object) on
créé une pollution des scripts qui tend à les rendre illisibles voir non
maintenables. Pire ça entraine très vite des écrasements si on ne
maitrise pas tous les morceaux de js incorporés à la page.

comment imaginer qu'on puisse faire ça :
this._selected = !this._selected;
et en plus (à ce que je comprends?) en affubler un TR

sur le même principe qu'on peut faire ça

var XXX = document.getElementById('monlien');
XXX.className = 'maCSS';
XXX.onclick = function(evt) { alert(this.className); };

ou plus simplement

var X = new Object();
X.ma_variable = 'ma valeur';

ou encore

var X = { ma_variable: 'ma valeur' };

On peut attribuer comme ça n'inporte quoi à n'importe quel élément ?

oui, puisque c'est pas à l'élément HTML que c'est assigné mais à l'objet
javascript qui référence cet élément. Et donc l'objet javascript se
comporte comme tous les autres objets.

Si on reprend l'exemple du lien <a> que j'évoquais dans mon message
précédent

<a id="monlien">

var XXX = document.getElementById('monlien');
XXX.ma_variable = 56789
XXX.onclick = function(evt)
{
// quand je suis ici
// this correspond à l'objet javascript qui s'appelle XXX
// this.ma_variable revient donc au même que XXX.ma_variable
// sauf que this est déclaré dans le contexte courant
// et il est plus facile, imo, de manipuler le contexte d'exécution
// courant plutot que des variables déclarées dans un autre contexte
// car c'est là que peuvent apparaitre des closures non controlées
// cf blabla d'avant pour le concept des closures
alert(XXX.ma_variable);
alert(this.ma_variable);
// les deux alertent 56789
};

C'est juste l'assignation d'une propriété à un objet.
Vala, j'espère ne pas avoir été trop confus, si c'est pas clair, comme
d'hab n'hésites pas.

--
laurent

Vous avez filtré cet utilisateur ! Consultez son message

-> outre les fonctions déclarées à l'intérieur d'une autre,

En js, une variable est intrinsèquement la même chose qu'une fonction.
Ce ne sont que des objets.

function foo() {}
est strictement la même chose que
var foo = function() {};

Donc de la même manière qu'on a le droit de créer des variables au sein
d'une fonction, on peut y créer également autant de fonctions qu'on
veut. Qui elles même peuvent créer d'autres fonctions et d'autres variables.

function foo()
{
function bar()
{
alert('private');
}
bar();
}
foo(); // => alerte : private

foo() est une fonction publique, accessible (et déclarée) depuis le
scope d'application global - l'objet window pour nos brouteurs favoris -
foo() faisant la même chose que window.foo() qui fait la même chose que
self.foo(), qui peux faire la même chose que top.foo() (suivant la
structure de frame du document), etc avec la folie des alias des noms
des fenêtres. A condition que aucun objet ne soit déclaré dans le
contexte d'exécution courant.

Par contre la fonction bar() qui est définie dans foo() est une fonction
privée qui n'est accessible que au sein du contexte de foo(). Seul foo()
peut accéder à cette function. C'est ce qui nous ouvre le monde
merveilleux des closures et de possibles fuites de mémoires (surtout
avec IE et la gestion des events mais pas seulement :p )

Une closure, c'est utiliser un objet (function, variable, etc) depuis un
autre contexte d'exécution que celui courant.

var name = 'ASM';
function foo()
{
function foobar()
{
var name = 'private';
}
function bar()
{
foobar();
alert(name);
name = 'updated';
foobar();
}
bar();
}
foo(); // alerte : ASM
alert(name); // alerte : updated.

On a modifié la variable hors du contexte de foo() et de bar();
Et même le double appel de foobar() depuis bar() ne peut affecter cette
variable puisque foobar() a declaré la variable name dans son contexte
(grace à var)

name est déclaré ni dans foo() ni dans bar() et pourtant la variable est
bien accessible. C'est une closure.

Ainsi on peut faire des trucs de fous

http://www.crockford.com/javascript/private.html

On peut, dans la même veine de trucs de maboules, s'amuser a faire des
fonctions anonymes privées qui s'auto exécutent lors de leur déclaration
(auto initialisation, préremplissages, etc)

var name = 'ASM';
function foo()
{
(function() { alert(name); name = 'updated'; }());
}
foo(); // alerte : ASM

Evidemment, dans cet exemple ca sert pas a grand chose voir même c'est
un peu couillon, mais c'est le principe qui compte :)

Pour en revenir à l'exemple d'origine qui t'as fait tiquer.
Grosso modo ça ressemblait à ça

function init(id)
{
function click(evt)
{
alert('click');
}
var elt = document.getElementById(id);
elt.onclick = click;
}

Hors c'est exactement la même chose que ce que tu as l'habitude de faire
qui est

function init(id)
{
var elt = document.getElementById(id);
elt.onclick = function (evt) { alert('click'); };
}

Et ca revient complètement a faire ceci :

function init(id)
{
var click = function (evt) { alert('click'); };
var elt = document.getElementById(id);
elt.onclick = click;
}

Le principal intérêt pour moi c'est de ne pas polluer mon global
namespace, mais au delà de ça, la possibilité d'utiliser des objets
privées est non négligeable, bien que je reconnaise l'utiliser peut
souvent dans ce sens.

On aurait évidemment pu faire à l'ancienne mode :) mais dès qu'on
commence à avoir plusieurs widgets sur la page, on s'en sort plus ou
tout du moins je m'en sors pas :)

function initEditeur(id)
{
var elt = document.getElementById(id);
elt.onclick = clickEditeur;
}
function initSlider(id)
{
var elt = document.getElementById(id);
elt.onclick = clickSlider;
}

function clickEditeur (evt) { alert('click'); };
function clickSlider (evt) { alert('click'); };
etc.

a créer plein de variables globales (fonction == variable == Object) on
créé une pollution des scripts qui tend à les rendre illisibles voir non
maintenables. Pire ça entraine très vite des écrasements si on ne
maitrise pas tous les morceaux de js incorporés à la page.

comment imaginer qu'on puisse faire ça :
this._selected = !this._selected;
et en plus (à ce que je comprends?) en affubler un TR

sur le même principe qu'on peut faire ça

var XXX = document.getElementById('monlien');
XXX.className = 'maCSS';
XXX.onclick = function(evt) { alert(this.className); };

ou plus simplement

var X = new Object();
X.ma_variable = 'ma valeur';

ou encore

var X = { ma_variable: 'ma valeur' };

On peut attribuer comme ça n'inporte quoi à n'importe quel élément ?

oui, puisque c'est pas à l'élément HTML que c'est assigné mais à l'objet
javascript qui référence cet élément. Et donc l'objet javascript se
comporte comme tous les autres objets.

Si on reprend l'exemple du lien <a> que j'évoquais dans mon message
précédent

<a id="monlien">

var XXX = document.getElementById('monlien');
XXX.ma_variable = 56789
XXX.onclick = function(evt)
{
// quand je suis ici
// this correspond à l'objet javascript qui s'appelle XXX
// this.ma_variable revient donc au même que XXX.ma_variable
// sauf que this est déclaré dans le contexte courant
// et il est plus facile, imo, de manipuler le contexte d'exécution
// courant plutot que des variables déclarées dans un autre contexte
// car c'est là que peuvent apparaitre des closures non controlées
// cf blabla d'avant pour le concept des closures
alert(XXX.ma_variable);
alert(this.ma_variable);
// les deux alertent 56789
};

C'est juste l'assignation d'une propriété à un objet.
Vala, j'espère ne pas avoir été trop confus, si c'est pas clair, comme
d'hab n'hésites pas.

--
laurent

Laurent Vilday

14/06/2006 à 06:29

grrr, ca m'apprendre

Regrrgrr, mon mailer a explosé juste avant d'envoyer mon message. Grrr
ça m'apprendrA cette fois à sauvegarder mes messages en cours de
rédaction. :)

bon, là, je refile une fois de plus ma méthode CSS+FF/JS+IE
Oui, totalement d'accord, mais est-ce que un behavior IE est

réellement plus lent comme le souligne PG ?

Alors j'ai fais deux petites pages sur la base d'un de tes exemples. Les
hover sont définis dans la CSS et un behavior ou une rustine JS sont
appliqués pour IE.

http://mokhet.com/tests/hover_behavior.php
http://mokhet.com/tests/hover_js.php

Honnêtement je ne saurais pas dire qui est le plus lent (on ne parlera
pas de vitesse mais bien de lenteur pour IE au dela de 200 lignes merci
:) Faudrait benchmarker tout ça.

D'une part je ne sais ce qu'est un behavior

http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/behavior_1.asp

Comme tu t'en doutes c'est spécial IE, ça s'associe à un élément dans la
css et le fichier .htc est un fichier XML qui bind les events avec du
Jscript. On doit même pouvoir y faire du vbScript, m'étonnerais pas tient :)

* dans CSS
element { behavior: url(fichier.htc); }

* dans HTC
<?xml version="1.0"?>
<public>
<component>
<attach event="onmouseover" onevent="hover()" />
<attach event="onmouseout" onevent="hout()" />
</component>

<script type="text/Jscript">
function hover()
{
element.$$current_classname = element.className;
element.className = element.className + ' IEhover';
}

function hout()
{
element.className = element.$$current_classname;
}
</script>

</public>

D'autre part est-ce qu'un behavior interpellera mon IE (Mac) ?
... j'en doute fort.

Je doute aussi, mais sait on jamais
http://mokhet.com/tests/hover_behavior.php

D'autre part, par principe, y pas d'raison qu'on se surcharge le job du
brouteur alors que des css sont là pour l'emoustiller et qu'il en rafolle.

Exactement, jamais assez répété.

--
laurent

Laurent Vilday

14/06/2006 à 06:35

Il y a déjà des choses que l'on peut faire avec CSS (changement de
couleur au survol), mais pour le reste je n'ai jamais bien creusé car il
s'agissait à chaque fois de choses assez compliquées à comprendre (bcp
de choses pour isoler ce qui m'intéresse)...

Est-ce que quelqu'un aurait des exemples simples (peut être lié à des
bibliothèques Google ou Yahoo ou ... ?), qui me permettrait d'obtenir
une telle interface au sein de mes applications Web ?

J'ai un exemple pas simple du tout mais ça permet d'imaginer beaucoup de
choses.

Qooxdoo - http://qooxdoo.org/
http://old.qooxdoo.org/public/demo/showcase/Showcase_1.html

--
laurent

ASM

14/06/2006 à 09:45

-> outre les fonctions déclarées à l'intérieur d'une autre,

En js, une variable est intrinsèquement la même chose qu'une fonction.
Ce ne sont que des objets.

C'est seulement que je ne pratique pas.
Au contraire de toi : ça m'embrouille le neurone.
Pour le moment, les fonctions à double ou triple rebondissements je ne
trouve pas ça facile à gérer.

Je suppose que c'est une simple gymnastique à acquérir ?
En attendant, je me suis fait un dossier 'Laurent'
J'imprime tout ça et le met sur ma table de chevet.

--
Stephane Moriaux et son [moins] vieux Mac

ASM

14/06/2006 à 10:10

Alors j'ai fais deux petites pages sur la base d'un de tes exemples. Les
hover sont définis dans la CSS et un behavior ou une rustine JS sont
appliqués pour IE.

http://mokhet.com/tests/hover_behavior.php

Ha oui ! mais c'est triché !
ce n'est même pas le navigateur qui crée les tables ! :-)

et, bien sûr, question roll-over IE Mac n'en fait rien.

D'une part je ne sais ce qu'est un behavior

Comme tu t'en doutes c'est spécial IE, ça s'associe à un élément dans la
css et le fichier .htc est un fichier XML qui bind les events avec du
Jscript. On doit même pouvoir y faire du vbScript, m'étonnerais pas
tient :)

Je voulais dire :
Je ne suis pas équipé pour :
- en profiter
- les créer et surtout les tester
Qu'en conséquence je préfère utiliser un petit JS que je commence à
avoir bien rodé.

* dans CSS
element { behavior: url(fichier.htc); }

* dans HTC

J'y comprends rien (et ne veux pas comprendre)
mais ça a l'air assez simple et automatique.

Je me demande pourquoi ce n'est pas intégré directement dans le
programme, si ces qques lignes suffisent.

--
Stephane Moriaux et son [moins] vieux Mac

Pierre Goiffon

14/06/2006 à 10:19

Pierre Goiffon wrote:

http://pgoiffon.free.fr/_temp/datagrid_20060613.html

Ce qui bloque c'est :
tableau.tBodies[i].rows[j].onclick = LigneCliquee(this.id);

Merci à tous pour vos réponses !

ASM (message-ID : <448f4947$0$819$) : je
cherchais à faire un rollover, ainsi que la gestion du clic sur une
ligne (pour retenir le no de ligne sélectionnée, la changer de couleur,
etc). Merci de tes exemples en tout cas, ils sont parfaits !

A tous, merci de vos compléments sur la définition du onClick... J'aurai
du mieux lire la doc... Merci à tous. En particulier, merci à Laurent
(message-id : <448f52b9$0$1170$) pour ces
explications très détaillées !

Juste une petite question : pourquoi Function et pas function ?

Concernant le rollover, j'avais testé ceci dans les styles :

tr:hover
{
background-color: #d8d9cc;
}

tr
{
hover:expression(this.onmouseover=new
Function("this.style.backgroundColor='#d8d9cc'"),this.onmouseout=new
Function("this.style.backgroundColor='transparent'"));
}

Sur IE6 hier, un changement rapide de ligne et le rollover ne suivait
pas toujours... Prb que je ne reproduis pas aujourd'hui (hier, je
travaillais sur mon Duron 800, aujourd'hui sur un Sempron 2800, ceci
explique peut-être cela ?)

Pierre Goiffon

14/06/2006 à 10:27

Laurent Vilday wrote:

J'ai un exemple pas simple du tout mais ça permet d'imaginer beaucoup de
choses.

Qooxdoo - http://qooxdoo.org/
http://old.qooxdoo.org/public/demo/showcase/Showcase_1.html

Merci
Je m'oriente plutôt vers du "home made", grace à toutes les explications
que je récolte ici.
En fait, l'idée est d'utiliser cela au sein d'une application pour
plusieurs tableaux de données qui pourront contenir un certain volume de
données. Aussi, je préfère avoir un table HTML "nu" et n'avoir qu'à
ajouter un .js et un appel à une fonction pour transformer ce tableau
standard. Je continue mes essais en tout cas (encore qq heures...), on
verra bien.

ASM

14/06/2006 à 11:05

J'ai un exemple pas simple du tout mais ça permet d'imaginer beaucoup de
choses.

Qooxdoo - http://qooxdoo.org/
http://old.qooxdoo.org/public/demo/showcase/Showcase_1.html

Malheureusement : tout est en "virtuel"

à mon premier essai, j'ai réussi à bloquer tout l'truc ...

Par contre là c'est super interressant
http://old.qooxdoo.org/public/demo/test/

Du JS de très haute volée pour créer, supprimer, copier, bouger tt un
tas de choses, et bien qu'il y ait qques (rares) Qx_MachinChose qui
capotent, je peux aller me rhabiller avec mes 'tites démos pas abouties
http://perso.orange.fr/stephane.moriaux/truc/jouer_avec_divs

--
Stephane Moriaux et son [moins] vieux Mac

ASM

14/06/2006 à 11:15

Pierre Goiffon wrote:

Juste une petite question : pourquoi Function et pas function ?

je crois que c'était YD qui nous avait donné cet exemple (perdu l'url)
montrant que c'est pareil au même, seule la syntaxe change.

<HTML><HEAD>
<script type="text/javascript">
onload= function(){
var allBtns=document.getElementsByTagName("BUTTON");
for( var i=0; i< allBtns.length;i++)
allBtns[i].onclick=Function("Dynamique(this);");
// ou allBtns[i].onclick=function(){Dynamique(this);};
}
function
Dynamique(obj){document.getElementById("witness").innerHTML=obj.id;}
</script>

</HEAD>
<BODY>
<button id='truc'>Clic...</button><br>
<button id='machin'>Clic...</button><br>
<button id='bidule'>Clic...</button><br>
<P id="witness"> </P></BODY></HTML>

Sur IE6 hier, un changement rapide de ligne et le rollover ne suivait
pas toujours... Prb que je ne reproduis pas aujourd'hui (hier, je
travaillais sur mon Duron 800, aujourd'hui sur un Sempron 2800, ceci
explique peut-être cela ?)

Sûr que, vu la lenteur de comprenette intrinsecte à IE, si on le confie
à un ordi un peu bas du cerveau, ça va pas améliorer :-)

--
Stephane Moriaux et son [moins] vieux Mac

ASM

14/06/2006 à 13:21

Alors j'ai fais deux petites pages sur la base d'un de tes exemples. Les
hover sont définis dans la CSS et un behavior ou une rustine JS sont
appliqués pour IE.

http://mokhet.com/tests/hover_behavior.php
http://mokhet.com/tests/hover_js.php

Suis-je autorisé à les mettre dans mon dossier de démos /truc/ ?
(je suppose que tu ne les garderas pas pendant 5 ans ?)

--
Stephane Moriaux et son [moins] vieux Mac

Liste/tableau "web 2.0"

10 réponses

Veuillez sélectionner un problème