[Prototype] Event.observe ne marche qu'une fois

Jérémie

21/11/2007 à 16:34

"SAM" a écrit dans le message
de news: 47444a63$0$27392$

Heu en fait parce que la function changerSemaine se présente ainsi :

function changerSemaine(evt, typeInf)
{
alert(typeof(evt));
...
}

et donc ? ça renvoie 'undefined' ?
Ce qui, peut-être, devrait être un peu normal avec IE si evt est un event
?

Vois plus bas.

Je voulais juste pas avoir le même nom dans les différentes définitions
de paramètres; il me semble que ça ne devrait pas poser de problèmes, si
?

si par 'paramètre' tu entends 'argument' c'est à dire le nom de la
variable entre les ( ) dans
function truc(x, y, z)
Si, bien sûr, ces x y z sont exploités tels que tt au long de la fonction
truc.

Oh je le confonds toujours ces deux-là : paramètre et argument...
Je suis d'accord avec toi, mais si l'on a :

function f1(evt)
{
f2(evt);
}

function f2(event)
{
alert(event);
}

je ne me trompe pas en faisant alert(event) et pas alert(evt), si ?

Heu ... pendant qu'on y est ... event n'est-il pas un objet du JS ?
<http://fr.selfhtml.org/javascript/objets/event.htm>
et bien sûr complètement interprété différemment par IE et les autres
brouteurs.

J'avais cru comprendre que prototype uniformise cela avec son objet Event.

c'est celui-ci qui m'intéresse, pas le event du Core JS.
C'est dommage de ne pas pouvoir "spécifier le type" de l'argument evt (par
exemple : Event evt)...

--
sm

SAM

21/11/2007 à 16:36

"Bruno Desthuilliers" a
écrit dans le message de news: 47441347$0$24310$

Je voulais juste pas avoir le même nom dans les différentes définitions
de paramètres;
???

Ben quoi ?

J'aurais du avoir toutes ces fonctions avec pour premier argument nommé
event ?
Ces trois points d'interrogation me laissent perplexe ...

c a d qu'il vaut mieux appeler les choses par leurs noms ?
et peut-être mieux préciser de quelle(s) chose(s) tu parles ?

Bon ... je ne sais ce que trafique

Event.stop(evt);

mais normalement IE pour alert(evt) ne devrait pas répondre [object]
il devrait répondre [object DIV] c a d objet et balise de l'élément

et à alert(typeof evt) il doit répondre : object

essaie

function changerSemaine(evt, typeInf)
{
alert(evt);
alert(typeof evt);
alert(evt.id);
// puis seulement après
Event.stop(evt);

et puis aussi voir sans ce stop ?

--
sm

SAM

21/11/2007 à 17:20

mais si l'on a :

function f1(evt)
{
f2(evt);
}

function f2(event)
{
alert(event);
}

je ne me trompe pas en faisant alert(event) et pas alert(evt), si ?

Non.

Heu ... pendant qu'on y est ... event n'est-il pas un objet du JS ?
<http://fr.selfhtml.org/javascript/objets/event.htm>
et bien sûr complètement interprété différemment par IE et les autres
brouteurs.

J'avais cru comprendre que prototype uniformise cela avec son objet Event.

c'est celui-ci qui m'intéresse, pas le event du Core JS.

je ne connais pas prototype
mais ... event est un mot JS que ça m'étonnerait que prototype le
modifie ... donc à n'utiliser qu'à bon et sciant.
Enfin, moi dans le doute, j'essaierais de ne pas utiliser comme variable
personnelle un mot du JS (proto ou pas).

C'est dommage de ne pas pouvoir "spécifier le type" de l'argument evt (par
exemple : Event evt)...

dans : function bindForm(e) { blabla }
je comprends que :

Event.observe($('cmdSemainePrecedente'),'click',changerSemaine,false);

ne fait qu'attribuer un onclick
à l'élément (div ?) d'id = cmdSemainePrecedente
avec comme fonction : changerSemaine(this)

reviendrait à écrire directement dans le html :

<div id="cmdSemainePrecedente"
onclick="changerSemaine(this); return false;">

Si c'est ça ... est-ce vraiment indispensable de charger 40 ou 60ko de
bibli + 10 ou 20ko de code d'exploitation de la bibli pour écrire qques
onclick ?

--
sm

Jérémie

21/11/2007 à 20:02

mais si l'on a :

function f1(evt)
{
f2(evt);
}

function f2(event)
{
alert(event);
}

je ne me trompe pas en faisant alert(event) et pas alert(evt), si ?

Non.

Heu ... pendant qu'on y est ... event n'est-il pas un objet du JS ?
<http://fr.selfhtml.org/javascript/objets/event.htm>
et bien sûr complètement interprété différemment par IE et les autres
brouteurs.

J'avais cru comprendre que prototype uniformise cela avec son objet

Event. c'est celui-ci qui m'intéresse, pas le event du Core JS.

je ne connais pas prototype
mais ... event est un mot JS que ça m'étonnerait que prototype le
modifie ... donc à n'utiliser qu'à bon et sciant.
Enfin, moi dans le doute, j'essaierais de ne pas utiliser comme variable
personnelle un mot du JS (proto ou pas).

C'est dommage de ne pas pouvoir "spécifier le type" de l'argument evt
(par exemple : Event evt)...

dans : function bindForm(e) { blabla }
je comprends que :

Event.observe($('cmdSemainePrecedente'),'click',changerSemaine,false);

ne fait qu'attribuer un onclick
à l'élément (div ?) d'id = cmdSemainePrecedente
avec comme fonction : changerSemaine(this)

reviendrait à écrire directement dans le html :

<div id="cmdSemainePrecedente"
onclick="changerSemaine(this); return false;">

Si c'est ça ... est-ce vraiment indispensable de charger 40 ou 60ko de
bibli + 10 ou 20ko de code d'exploitation de la bibli pour écrire qques
onclick ?

C'est pas si simple que ça. Event est un objet spécifique à Prototype

indépendant de event, d'où le E majuscule (non ce n'était ni une faute,
ni une majuscule automatique ;-)).
Mon but est aussi de faire de l'inobstrusive JS; c'est à dire séparer au
max l'XHTML et le JS.
Le fichier JS est bien plus conséquent que ce que j'ai montré, avec de
l'AJAX entre autres(exploitation de services REST, images chargés
dynamiquement, etc).
Les fonctions de Prototype permettent AMHA d'écrire du code de manière
plus simple et plus concise. Je l'ai essayé, il m'a séduit.
Pour ce qui est du poids, ce n'est pas vraiment pertinent dans mon cas
car cette appli est utilisée en interne (local + RPV dédié), donc les
pages sont chargées à très grande vitesse, sans compter que nous
maitrisons la mise en cache de la feuille sur le client. Donc à moins
d'une réinstallation ou d'un vidage du cache programmée, elle est
chargée une fois pour toutes ... ;-)
Sinon pour en revenir au problème, j'ai trouvé une solution avec un try
catch. Peut-être pas forcément élégant, mais ça marche dans tous les cas
d'utilisation.

mais si l'on a :

function f1(evt)
{
f2(evt);
}

function f2(event)
{
alert(event);
}

je ne me trompe pas en faisant alert(event) et pas alert(evt), si ?

Non.

Heu ... pendant qu'on y est ... event n'est-il pas un objet du JS ?
<http://fr.selfhtml.org/javascript/objets/event.htm>
et bien sûr complètement interprété différemment par IE et les autres
brouteurs.

J'avais cru comprendre que prototype uniformise cela avec son objet

Event. c'est celui-ci qui m'intéresse, pas le event du Core JS.

je ne connais pas prototype
mais ... event est un mot JS que ça m'étonnerait que prototype le
modifie ... donc à n'utiliser qu'à bon et sciant.
Enfin, moi dans le doute, j'essaierais de ne pas utiliser comme variable
personnelle un mot du JS (proto ou pas).

C'est dommage de ne pas pouvoir "spécifier le type" de l'argument evt
(par exemple : Event evt)...

dans : function bindForm(e) { blabla }
je comprends que :

Event.observe($('cmdSemainePrecedente'),'click',changerSemaine,false);

ne fait qu'attribuer un onclick
à l'élément (div ?) d'id = cmdSemainePrecedente
avec comme fonction : changerSemaine(this)

reviendrait à écrire directement dans le html :

<div id="cmdSemainePrecedente"
onclick="changerSemaine(this); return false;">

Si c'est ça ... est-ce vraiment indispensable de charger 40 ou 60ko de
bibli + 10 ou 20ko de code d'exploitation de la bibli pour écrire qques
onclick ?

C'est pas si simple que ça. Event est un objet spécifique à Prototype

indépendant de event, d'où le E majuscule (non ce n'était ni une faute,
ni une majuscule automatique ;-)).
Mon but est aussi de faire de l'inobstrusive JS; c'est à dire séparer au
max l'XHTML et le JS.
Le fichier JS est bien plus conséquent que ce que j'ai montré, avec de
l'AJAX entre autres(exploitation de services REST, images chargés
dynamiquement, etc).
Les fonctions de Prototype permettent AMHA d'écrire du code de manière
plus simple et plus concise. Je l'ai essayé, il m'a séduit.
Pour ce qui est du poids, ce n'est pas vraiment pertinent dans mon cas
car cette appli est utilisée en interne (local + RPV dédié), donc les
pages sont chargées à très grande vitesse, sans compter que nous
maitrisons la mise en cache de la feuille sur le client. Donc à moins
d'une réinstallation ou d'un vidage du cache programmée, elle est
chargée une fois pour toutes ... ;-)
Sinon pour en revenir au problème, j'ai trouvé une solution avec un try
catch. Peut-être pas forcément élégant, mais ça marche dans tous les cas
d'utilisation.

Vous avez filtré cet utilisateur ! Consultez son message

mais si l'on a :

function f1(evt)
{
f2(evt);
}

function f2(event)
{
alert(event);
}

je ne me trompe pas en faisant alert(event) et pas alert(evt), si ?

Non.

Heu ... pendant qu'on y est ... event n'est-il pas un objet du JS ?
<http://fr.selfhtml.org/javascript/objets/event.htm>
et bien sûr complètement interprété différemment par IE et les autres
brouteurs.

J'avais cru comprendre que prototype uniformise cela avec son objet

Event. c'est celui-ci qui m'intéresse, pas le event du Core JS.

je ne connais pas prototype
mais ... event est un mot JS que ça m'étonnerait que prototype le
modifie ... donc à n'utiliser qu'à bon et sciant.
Enfin, moi dans le doute, j'essaierais de ne pas utiliser comme variable
personnelle un mot du JS (proto ou pas).

C'est dommage de ne pas pouvoir "spécifier le type" de l'argument evt
(par exemple : Event evt)...

dans : function bindForm(e) { blabla }
je comprends que :

Event.observe($('cmdSemainePrecedente'),'click',changerSemaine,false);

ne fait qu'attribuer un onclick
à l'élément (div ?) d'id = cmdSemainePrecedente
avec comme fonction : changerSemaine(this)

reviendrait à écrire directement dans le html :

<div id="cmdSemainePrecedente"
onclick="changerSemaine(this); return false;">

Si c'est ça ... est-ce vraiment indispensable de charger 40 ou 60ko de
bibli + 10 ou 20ko de code d'exploitation de la bibli pour écrire qques
onclick ?

C'est pas si simple que ça. Event est un objet spécifique à Prototype

indépendant de event, d'où le E majuscule (non ce n'était ni une faute,
ni une majuscule automatique ;-)).
Mon but est aussi de faire de l'inobstrusive JS; c'est à dire séparer au
max l'XHTML et le JS.
Le fichier JS est bien plus conséquent que ce que j'ai montré, avec de
l'AJAX entre autres(exploitation de services REST, images chargés
dynamiquement, etc).
Les fonctions de Prototype permettent AMHA d'écrire du code de manière
plus simple et plus concise. Je l'ai essayé, il m'a séduit.
Pour ce qui est du poids, ce n'est pas vraiment pertinent dans mon cas
car cette appli est utilisée en interne (local + RPV dédié), donc les
pages sont chargées à très grande vitesse, sans compter que nous
maitrisons la mise en cache de la feuille sur le client. Donc à moins
d'une réinstallation ou d'un vidage du cache programmée, elle est
chargée une fois pour toutes ... ;-)
Sinon pour en revenir au problème, j'ai trouvé une solution avec un try
catch. Peut-être pas forcément élégant, mais ça marche dans tous les cas
d'utilisation.

Bruno Desthuilliers

21/11/2007 à 23:26

"Bruno Desthuilliers" a
écrit dans le message de news: 47441347$0$24310$

Heu en fait parce que la function changerSemaine se présente ainsi :

function changerSemaine(evt, typeInf)
{
alert(typeof(evt));
...
}

Je voulais juste pas avoir le même nom dans les différentes définitions
de paramètres;

???

Ben quoi ?

J'aurais du avoir toutes ces fonctions avec pour premier argument nommé
event ?

ou evt, ou même toto si tu veux, mais bon... . En quoi le fait
d'utiliser le même nom d'argument pour plusieurs fonctions te pose-t-il
problème, au juste ? Au contraire, dans la mesure où tu a plusieurs
fonctions qui recoive un évènement en paramètre, autant le nommer
systématiquementde la même façon, c'est plus lisible et ça évite de se
prendre les pieds dans le tapis.

Ces trois points d'interrogation me laissent perplexe ...

L'affirmation qui les précède me laissant également perplexe, on est à
égalité !-)

Bruno Desthuilliers

21/11/2007 à 23:33

mais si l'on a :

function f1(evt)
{
f2(evt);
}

function f2(event)
{
alert(event);
}

je ne me trompe pas en faisant alert(event) et pas alert(evt), si ?

Non.

Heu ... pendant qu'on y est ... event n'est-il pas un objet du JS ?
<http://fr.selfhtml.org/javascript/objets/event.htm>
et bien sûr complètement interprété différemment par IE et les autres
brouteurs.

J'avais cru comprendre que prototype uniformise cela avec son objet

Event. c'est celui-ci qui m'intéresse, pas le event du Core JS.

je ne connais pas prototype
mais ... event est un mot JS

Non, c'est un attribut de l'objet window - et donc l'identifiant d'un
objet global, sauf quand il est masqué par un identifiant local, comme
c'est le cas dans le corps d'une fonction si c'est le nom d'un argument
de ladite fonction.

que ça m'étonnerait que prototype le
modifie ...

En effet. Dans prototype, il y a un objet Event (E majuscule), qui gère
(autant que possible) les différences d'implémentation de la gestion
d'évènement entre différents navigateurs.

C'est dommage de ne pas pouvoir "spécifier le type" de l'argument evt
(par exemple : Event evt)...

dans : function bindForm(e) { blabla }
je comprends que :

Event.observe($('cmdSemainePrecedente'),'click',changerSemaine,false);

ne fait qu'attribuer un onclick
à l'élément (div ?) d'id = cmdSemainePrecedente
avec comme fonction : changerSemaine(this)

reviendrait à écrire directement dans le html :

<div id="cmdSemainePrecedente"
onclick="changerSemaine(this); return false;">

Non. Event utilise la gestion "avancée" d'évènements, qui permet
d'associer plusieurs gestionnaires d'évènements au même évènement - ce
qui n'est pas possible avec l'utilisation du par ailleurs déplorable
attribut onclick (déplorable dans le sens où le code javascript n'a rien
à faire dans le balisage).

SAM

22/11/2007 à 02:37

je ne connais pas prototype
mais ... event est un mot JS

Non,

Oui, bon, j'ai fait un petit raccourci ...

c'est un attribut de l'objet window - et donc l'identifiant d'un
objet global, sauf quand il est masqué par un identifiant local, comme
c'est le cas dans le corps d'une fonction si c'est le nom d'un argument
de ladite fonction.

C'est bien pourquoi je préfère ne pas le faire et ne pas me prendre les
pieds dans le tapis.

je comprends que :

Event.observe($('cmdSemainePrecedente'),'click',changerSemaine,false);

ne fait qu'attribuer un onclick
à l'élément (div ?) d'id = cmdSemainePrecedente
avec comme fonction : changerSemaine(this)

reviendrait à écrire directement dans le html :

<div id="cmdSemainePrecedente"
onclick="changerSemaine(this); return false;">

Non. Event utilise la gestion "avancée" d'évènements, qui permet
d'associer plusieurs gestionnaires d'évènements au même évènement

Je n'ai pas compris.

ce qui n'est pas possible avec l'utilisation du par ailleurs déplorable
attribut onclick (déplorable dans le sens où le code javascript n'a rien
à faire dans le balisage).

Bon, là ( ) on est d'accord.
(encore que il faut qd même s'y retrouver pour la gestion comme ça à
distance - depuis le head vers le body - )

--
sm

Bruno Desthuilliers

22/11/2007 à 09:59

je ne connais pas prototype
mais ... event est un mot JS

Non,

Oui, bon, j'ai fait un petit raccourci ...

!-)

c'est un attribut de l'objet window - et donc l'identifiant d'un objet
global, sauf quand il est masqué par un identifiant local, comme c'est
le cas dans le corps d'une fonction si c'est le nom d'un argument de
ladite fonction.

C'est bien pourquoi je préfère ne pas le faire et ne pas me prendre les
pieds dans le tapis.

Tu peux toujours accéder à l'objet "global" par window.event.

je comprends que :

Event.observe($('cmdSemainePrecedente'),'click',changerSemaine,false);

ne fait qu'attribuer un onclick
à l'élément (div ?) d'id = cmdSemainePrecedente
avec comme fonction : changerSemaine(this)

reviendrait à écrire directement dans le html :

<div id="cmdSemainePrecedente"
onclick="changerSemaine(this); return false;">

Non. Event utilise la gestion "avancée" d'évènements, qui permet
d'associer plusieurs gestionnaires d'évènements au même évènement

Je n'ai pas compris.

En utilisant la gestion d'évènement DOM (elt.addEventListener), tu peux
associer plusieurs gestionnaires d'évenènement (fonctions de rappel) au
même évènement pour un même élément. Sur le déclenchement de
l'évènement, les gestionnaires seront appelés les uns après les autres
dans l'ordre d'enregistrement.

ce qui n'est pas possible avec l'utilisation du par ailleurs
déplorable attribut onclick (déplorable dans le sens où le code
javascript n'a rien à faire dans le balisage).

Bon, là ( ) on est d'accord.
(encore que il faut qd même s'y retrouver pour la gestion comme ça à
distance - depuis le head vers le body - )

je ne vois pas où est le problème. Au contraire, ça tend à simplifier
notoirement les choses AMHA. Au lieu d'avoir un mélange indigeste de
balisage, script serveur et script client, tu a des aspects bien séparés
les uns des autres, bien factorisés et tout.

SAM

22/11/2007 à 13:55

ne pas me prendre les pieds dans le tapis.

Tu peux toujours accéder à l'objet "global" par window.event.

Certes mais mon tapis a des franges :-)
(déjà que je préfère les variables en français pour qu'elles se
différencient facilement de tout le vocabulaire JS DOM etc )

Non. Event utilise la gestion "avancée" d'évènements, qui permet
d'associer plusieurs gestionnaires d'évènements au même évènement

Je n'ai pas compris.

En utilisant la gestion d'évènement DOM (elt.addEventListener), tu peux
associer plusieurs gestionnaires d'évenènement (fonctions de rappel) au
même évènement pour un même élément.

est-ce à dire que je puis faire :

elt.addEventListener("click", gestion_clic_un, false);
elt.addEventListener("click", gestion_clic_deux, false);
elt.addEventListener("click", gestion_clic_troix, false);

et ça me fera l'équivalent de :

onclick="
gestion_clic_un(this);
gestion_clic_deux(this;
gestion_clic_troisthis);
return false;">

--
sm

Bruno Desthuilliers

22/11/2007 à 14:42

ne pas me prendre les pieds dans le tapis.

Tu peux toujours accéder à l'objet "global" par window.event.

Certes mais mon tapis a des franges :-)

Coupe les, c'est chiant à entretenir !-)

(déjà que je préfère les variables en français pour qu'elles se
différencient facilement de tout le vocabulaire JS DOM etc )

Ah tiens ? Moi je préfère éviter les sabirs franglais. D'une part je
trouve ça laid, d'autre part ça n'aide pas nécessairement à partager du
code.

Non. Event utilise la gestion "avancée" d'évènements, qui permet
d'associer plusieurs gestionnaires d'évènements au même évènement

Je n'ai pas compris.

En utilisant la gestion d'évènement DOM (elt.addEventListener), tu
peux associer plusieurs gestionnaires d'évenènement (fonctions de
rappel) au même évènement pour un même élément.

est-ce à dire que je puis faire :

elt.addEventListener("click", gestion_clic_un, false);
elt.addEventListener("click", gestion_clic_deux, false);
elt.addEventListener("click", gestion_clic_troix, false);

et ça me fera l'équivalent de :

onclick="
gestion_clic_un(this);
gestion_clic_deux(this;
gestion_clic_troisthis);
return false;">

A peu de choses près (propagation des évnements etc):oui. Avec surtout
l'intérêt que les appels à addEventListener peuvent être dans des
scripts distincts. Par contre, of course, IE ne supporte pas cette
syntaxe, et utilise à la place une syntaxe proprio et pas tout à fait
compatible. D'où l'intérêt de bibliothèques comme prototype ou jQuery
qui 'unifient' tout ça.

[Prototype] Event.observe ne marche qu'une fois

10 réponses

Veuillez sélectionner un problème