By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
464,789 Members | 1,447 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 464,789 IT Pros & Developers. It's quick & easy.

If else for literal

P: n/a
Can some sort of is else condition be used for the following to change the
onclick to onmouseover depending on an argument in the surrounding function?
All of the code in the .. code to execute ... is very long and exactly
the same for both onclick or onmouseover events. Otherwise I would just make
2 functions.
function doIt(argument){
element.onclick = function {
.. code to execute ...
};
}
-------------------------------------
Laymens terms, like this..

function doIt(argument){
if(argument == 1){
element.onclick = function {
}else{
element.onmouseover = function {
}
.. code to execute ...
};
}
David

Feb 19 '07 #1
Share this Question
Share on Google+
7 Replies

P: n/a
On Feb 19, 12:17 pm, "David" <n...@none.netwrote:
Can some sort of is else condition be used for the following to change the
onclick to onmouseover depending on an argument in the surrounding function?
All of the code in the .. code to execute ... is very long and exactly
the same for both onclick or onmouseover events. Otherwise I would just make
2 functions.

function doIt(argument){
element.onclick = function {
.. code to execute ...
};}

-------------------------------------
Laymens terms, like this..

function doIt(argument){
if(argument == 1){
element.onclick = function {}else{

element.onmouseover = function {}

.. code to execute ...
};

}

David
Ahh, carrying bad PHP habits into the browser space...

For one thing, you shouldn't assign rogue function handlers in
function bodies, mostly because IE's garbage collector can't clean
them up:

http://blogs.msdn.com/ie/archive/200...iciencies.aspx

but also because a new copy of the anonymous function is created for
each element, which is much less efficient than having all elements
sharing the same function:

var userAction = function(e) {
// your code here
}

function doIt(argument) {
if (argument == 1) {
element.onclick = userAction;
} else {
element.onmouseover = userAction;
}
}

-David

Feb 19 '07 #2

P: n/a
David wrote:
Can some sort of is else condition be used for the following
to change the onclick to onmouseover depending on an argument
in the surrounding function? All of the code in the .. code
to execute ... is very long and exactly the same for both
onclick or onmouseover events. Otherwise I would just make 2 functions.
function doIt(argument){
element.onclick = function {
.. code to execute ...
};
}
-------------------------------------
Laymens terms, like this..

function doIt(argument){
if(argument == 1){
element.onclick = function {
}else{
element.onmouseover = function {
}
.. code to execute ...
};
}
You could do:-

element[((argument == 1)?'onclick':'onmouseover')] = function(){ ...

See:-
<URL: http://jibbering.com/faq/faq_notes/square_brackets.html >

- but that is going to be pretty obscure source code, and a slightly
unexpected design to be suing the same function for one of either onclick
or onmouseover depending on a parameter.

Richard.

Feb 19 '07 #3

P: n/a
[..]
"David Golightly" <da******@gmail.comwrote in message
Ahh, carrying bad PHP habits into the browser space...

For one thing, you shouldn't assign rogue function handlers in
function bodies, mostly because IE's garbage collector can't clean
them up:
but also because a new copy of the anonymous function is created for
each element, which is much less efficient than having all elements
sharing the same function:
[..]

var userAction = function(e) {
// your code here
}

function doIt(argument) {
if (argument == 1) {
element.onclick = userAction;
} else {
element.onmouseover = userAction;
}
}

Thanks for the info. I may have to rethink the script because ( using your
example ) the argument for the "element" is inside of the userAction var.
The doIt() function has no knowledge of what the "element" is.

David
Feb 19 '07 #4

P: n/a

"Richard Cornford" wrote:
You could do:-

element[((argument == 1)?'onclick':'onmouseover')] = function(){ ...

See:-
<URL: http://jibbering.com/faq/faq_notes/square_brackets.html >

- but that is going to be pretty obscure source code, and a slightly
unexpected design to be suing the same function for one of either onclick
or onmouseover depending on a parameter.

Richard.
That works. I had no idea you could put if else statements inside of the
brackets like that.

Thnkas, David
Feb 19 '07 #5

P: n/a

"David Golightly" <da******@gmail.comwrote >
>
For one thing, you shouldn't assign rogue function handlers in
function bodies, mostly because IE's garbage collector can't clean
them up:

http://blogs.msdn.com/ie/archive/200...iciencies.aspx

but also because a new copy of the anonymous function is created for
each element, which is much less efficient than having all elements
sharing the same function:

You know, I don't think this would apply in this case. The outer function is
called only once onload to initiate the script, and the inner function. So
this function and the nested function objects ( applied to specific id'd
anchor tags ) are already stored in memory. I don't think extra instances of
these function objetcs are created when the event happens?

David
Feb 20 '07 #6

P: n/a
On Feb 20, 6:53 am, "David" <n...@none.netwrote:
"David Golightly" <davig...@gmail.comwrote >
For one thing, you shouldn't assign rogue function handlers in
function bodies, mostly because IE's garbage collector can't clean
them up:
http://blogs.msdn.com/ie/archive/200...performance-re...
but also because a new copy of the anonymous function is created for
each element, which is much less efficient than having all elements
sharing the same function:

You know, I don't think this would apply in this case. The outer function is
called only once onload to initiate the script, and the inner function. So
this function and the nested function objects ( applied to specific id'd
anchor tags ) are already stored in memory. I don't think extra instances of
these function objetcs are created when the event happens?

David
It's true that, if you only call this once, you'll only get one copy
of the function. But you're still getting into a potentially
problematic circular reference with your closure. Any time a function
exists has an element in its scope that it in turn is attached to (as
an event handler), you're creating exactly the kind of circular
reference referred to in the MSIE blog article - the one the IE team
decided wasn't worth fixing.

Also, were you to put this event handler assignment (doIt) in a loop,
you'd get multiple copies of the function literal assigned as
properties of your different DOM objects, instead of your DOM objects
having references to the same function object, since with each outer
function call you'll get a different scope chain and therefore a new
closure. See:

http://developer.mozilla.org/en/docs...considerations

Finally, it's probably not good programming practice to just say "Oh,
I'll just do it like this because it's a one-off thing, no need to
worry about scalability." If I can get the same result using a more
scalable technique, I get in the habit of doing it that way. You
never know when you may need to scale in the future! Just my 2c,
however; you're welcome to develop your own technique.

-David

Feb 20 '07 #7

P: n/a

"David Golightly" wrote
you're creating exactly the kind of circular
reference referred to in the MSIE blog article - the one the IE team
decided wasn't worth fixing.
lol...
Finally, it's probably not good programming practice to just say "Oh,
I'll just do it like this because it's a one-off thing, no need to
worry about scalability." If I can get the same result using a more
scalable technique, I get in the habit of doing it that way. You
never know when you may need to scale in the future! Just my 2c,
however; you're welcome to develop your own technique.
This function will only be called once onload and that's it. It will never
be placed in a looping condition ( scary thought ), however I do agree with
you about good coding habits. I'm not a rebel trying to re-create new
techniques nor take the easy way out.

Thanks again,
David


Feb 21 '07 #8

This discussion thread is closed

Replies have been disabled for this discussion.