addEventListener / attachEvent and grab Option Value

[pbd22]

Hi.

I am trying to dynamically attach / add an onchange
function for both Ff and IE scenarios. When an option
is clicked, I want the value of the option. How do I use
one function to handle the two different browsers? Can
somebody provide code ideas for toggleElem()?

Thanks.

function SomeFunction() {

....

var m_sel=document.getElementById("myselect");

if (m_sel) {

if(window.addEventListener) // Mozilla, Netscape, Firefox
m_sel.addEventListener('onchange', toggleElem,
false );

else // IE
m_sel.attachEvent('onchange', toggleElem);

}

....

}

function toggleElem()
{
// PSEUDO CODE OF DESIRED RESULTS
if(m_sel.addeventlistener) // Moz
// get the value of the option element being clicked;
else if (m_sel.attachEvent) // IE
// get the value of the option element being clicked;

}

 

[abozhilov]

Hi.

I am trying to dynamically attach / add an onchange
function for both Ff and IE scenarios. When an option
is clicked, I want the value of the option. How do I use
one function to handle the two different browsers? Can
somebody provide code ideas for toggleElem()?

var CONSTANTS = {
select_obj : 'eg_select'
}

function addEvent(obj, evtName, handler)
{
if (obj.addEventListener)
{
obj.addEventListener(evtName, handler, false);
}
else if (obj.attachEvent)
{
obj.attachEvent('on' + evtName, handler);
}
}

function getElValue(el_id)
{
return document.getElementById(el_id).value;
}

window.onload = function()
{
var el_id = CONSTANTS.select_obj,
obj = document.getElementById(el_id);
if (obj)
{
addEvent(obj, 'change', function(){
alert(getElValue(el_id));
});
obj = null;
}
}

 

[Thomas 'PointedEars' Lahn]

var CONSTANTS = {
select_obj : 'eg_select'
}

function addEvent(obj, evtName, handler)
{
if (obj.addEventListener)
{
obj.addEventListener(evtName, handler, false);
}
else if (obj.attachEvent)
{
obj.attachEvent('on' + evtName, handler);
}
}

Nobody in their right mind does that anymore:

function getElValue(el_id)
{
return document.getElementById(el_id).value;
}

Unnecessary. You have the object reference already.

window.onload = function()
{
var el_id = CONSTANTS.select_obj,
obj = document.getElementById(el_id);
if (obj)
{
addEvent(obj, 'change', function(){
alert(getElValue(el_id));
});
obj = null;
}
}

Nobody in their right mind does that (anymore).

<select ... onchange="window.alert(this.value);">

suffices and works everywhere. As for "dynamically", use

<select ... onchange="foo(this);">

and in foo() it can be determined when to do what.


PointedEars

 

[abozhilov]

Unnecessary.  You have the object reference already.

Absolutely right. If i pass reference from closure, that means
circular reference to that `object'. I don't want to complicate
example. I just want, simple code here.
If i want to pass reference:

addEvent(obj, 'change', (function(o){
return function(){alert(getElValue(el_id))};
})(obj));
obj = null;

I will be isolate circular reference in different execution context.

Nobody in their right mind does that (anymore).

  <select ... onchange="window.alert(this.value);">

suffices and works everywhere.  As for "dynamically", use

  <select ... onchange="foo(this);">

and in foo() it can be determined when to do what.

I don't thing this is proper way. This mixing two complete different
layer. Structured and Behaviour. What's happen if your server for
static content is offline? This produce JavaScript error. I thing one
web application must be work in that case.

 

[Thomas 'PointedEars' Lahn]

Absolutely right. If i pass reference from closure, that means
circular reference to that `object'. I don't want to complicate
example. I just want, simple code here.

s/simple/inefficient, error-prone/

If i want to pass reference:

addEvent(obj, 'change', (function(o){
return function(){alert(getElValue(el_id))};
})(obj));
obj = null;

I will be isolate circular reference in different execution context.

^^^^^^^^^^^^^^^^^
I beg your pardon?

I don't thing this is proper way.

But you don't seem to know what you are talking about, so what you think
about this hardly matters, does it? As a matter of fact, the "unobtrusive",
"dynamical", partially proprietary way is in effect much more obtrusive and
error-prone than the "static", fully standards-compliant one. To begin
with, the listener is not going to be added before the document was fully
loaded, if that; so the user is going to encounter two different behaviors
of the control without necessarily knowing why.

This mixing two complete different layer. Structured and Behaviour.

"Unobtrusive JavaScript" rubbish. Structure and behavior are undoubtedly
bound to one another here.

What's happen if your server for static content is offline?
This produce JavaScript error.

Nobody in their right mind would serve markup from one server
and client-side scripting bound to that markup from another.

I thing one web application must be work in that case.

A Web application is not going to work if its Web server is unavailable.
That applies both to HTML and client-side scripting.


PointedEars

 

[pbd22]

suffices and works everywhere.  As for "dynamically", use

  <select ... onchange="foo(this);">

and in foo() it can be determined when to do what.

OK, does the below code work for setting the onchange function?
If not, can you correct what I am doing wrong.

if(window.addEventListener)
m_sel.addEventListener('onchange', function(){toggleElem(this);},
false);
else
m_sel.attachEvent('onchange', function(){toggleElem(this);});

Also, I am guessing this.target.value exposes the value in FF and
this.value in IE?

 

[Thomas 'PointedEars' Lahn]

OK, does the below code work for setting the onchange function?
If not, can you correct what I am doing wrong.

if(window.addEventListener)
m_sel.addEventListener('onchange', function(){toggleElem(this);},
false);

Where is the logic in testing for a property on a proprietary Window
instance, and then calling another standards-compliant property on an
element object? Test exactly what you are going to use, not something else.

else
m_sel.attachEvent('onchange', function(){toggleElem(this);});

(as discussed ad nauseam before)

Do not use attachEvent(); in a listener added with attachEvent(), `this'
refers to the Window instance (or the ECMAScript Global Object, I don't
remember), and by comparison order of execution is not guaranteed (see the
URL I have posted in my other reply).

Where addEventListener() is unavailable, use the proprietary, but
backwards-compatible event-handler properties:

m_sel.onchange = function() {
toggleElem(this);
};

See also _addEventListener() or dhtml.addEventListener or (yet to be
released) jsx.dom.addEventListener().

Also, I am guessing this.target.value exposes the value in FF and
this.value in IE?

(Do not) guess again. (RTFFAQ, RTFM, STFW instead.)

Please leave an attribution line for each quotation level.

<http://jibbering.com/faq/#posting> pp.


PointedEars

 

[abozhilov]

s/simple/inefficient, error-prone/

error-prone? Where error-prone in that example? attachEvent itself
produce error only if pass handler who isn't referred to `object'.

  ^^^^^^^^^^^^^^^^^
I beg your pardon?

I don't understand what are you mean with this expression. Maybe
ironic? But in your latest post, example with closure handler, again
needs from breaking circular reference. Whatever.

But you don't seem to know what you are talking about, so what you think
about this hardly matters, does it?  As a matter of fact, the "unobtrusive",
"dynamical", partially proprietary way is in effect much more obtrusive and
error-prone than the "static", fully standards-compliant one.  To begin
with, the listener is not going to be added before the document was fully
loaded, if that; so the user is going to encounter two different behaviors
of the control without necessarily knowing why.

Please excuse me. Before parsing all page, you don't need handler.
What are you thing about the case when, that handler related with
element who is down in the DOM tree? That error will be hard to
debugging. And any mixing like this is hard to hold clear
application.
What are you thing about the case, where html code is complete same in
any template. Only you can change behaviour and presentation of
application?

Regards.
Again good discussion. Thanks.

 

[Thomas 'PointedEars' Lahn]

error-prone? Where error-prone in that example? attachEvent itself
produce error only if pass handler who isn't referred to `object'.

You are (needlessly) accessing the property of an object before you have
made sure that there is an object to begin with, an inherently error-prone
design pattern that I have coined a reference worm[tm].

You also overlooked the "inefficient" part. It is very inefficient to call
a method, on every occurence of an event, in order to return a reference to
an object that one has already stored elsewhere in a readily available
fashion. And that approach would hardly be simplifying the example for
better understanding.

I don't understand what are you mean with this expression. Maybe
ironic?

Not at all.

But in your latest post, example with closure handler, again
needs from breaking circular reference. Whatever.

AFAIK it is the polite way of saying "I did not understand what you were
saying or why" in formal English, the question mark emphasizing the
politeness. Synonyms are "Excuse me?" or "(I'm) sorry?". Compare
"извините" in Russian, or, as you appear to post from Bulgaria, probably
"извинете" in Bulgarian.

(Maybe you should learn the *basics* of the English language before
discussing in English?)

Please excuse me. Before parsing all page, you don't need handler.

But you do. It is unwise at best to assume that a document will not be
displayed and accessible by the user before it was completely loaded (with
a rather wide margin about what "loaded" really means -- does that include
all referred resources, e.g. images, or not? -- even current browser vendors
do not agree on a definition). Incremental rendering is prevalent these days.

What if the user accesses the already displayed element while the document
is loading? Granted, with a `change' event that may not be as likely
(although entirely possible), but what about a `click' event? We have
discussed the unwanted change in behavior of the user interface depending on
the loading state here before.

What are you thing about the case when, that handler related with
element who is down in the DOM tree? That error will be hard to
debugging.

It will not, for the erroneous method can be tracked down in the markup,
where its identifier is included verbatim, per element (and its ancestor
elements, if the event happens to be a bubbling one).

And adding listeners dynamically will help nothing to avoid a perceived, but
non-existing problem; instead, it will add more problems, such as a not
future-proof dependency on a certain subset of (currently known) DOMs. By
comparison, event-handler attributes have worked ever since client-side
scripting was introduced, everywhere where script support was present, and
are going to continue to work there and then regardless of changes in the
ways in which event listeners may be added.

Granted, there are instances where adding event listeners dynamically is
preferable, such as non-bubbling events that need to be handled on a large
number of elements. However, in all other cases the standards-compliant
*and* most compatible approach should be followed, which are event-handler
attributes.

And any mixing like this is hard to hold clear application.

Quite the contrary. With event-handler attributes, one knows which element
does what and when at a glance. With the so-called (but misnamed)
unobtrusive approach you have to look for the element by ID or whatever, and
even then you cannot be sure that it does what it is supposed to do as you
are dealing with a host object that it is represented by. Especially the
addEventListener() and addEvent() approaches are comparably hard to debug
because no debugging tool so far lists them on inspection of an element (not
even Firebug; while it has the Log Events feature, that requires the event
to occur -- so to be caused by the developer -- first).

What are you thing about the case, where html code is complete same in
any template. Only you can change behaviour and presentation of
application?

I would submit that if the very same markup would produce a user interface
that behaved differently, something would be terribly wrong with the
application's user interface design.


PointedEars