variable in object string

[bmgz]

sorry for the stupid question, bu6 I haven't been able to find the
answer anywhere..

consider this useless function which assigns an object to a var..

function(myParam){
var select1 = document.myForm.mySelectName;
}

I simply want this line to subsitute "mySelectName" with a var string

function(myParam){
var select1 = document.myForm.myParam;
}

It doesn't work, ive tried umpteen variations with []+ "" '' etc..
How would I do this stupid-simple thing?

 

[Martin Honnen]

bmgz wrote:

function(myParam){
var select1 = document.myForm.myParam;

var select1 = document.myForm.elements[myParam];

but in most cases you can simply pass around objects like for instance
the form or select itself, there is hardly the need to pass in a string
to use it to find an object reference.

 

[VK]

Each object inherits hash (associative array) mechanics, this is how
objects properties are stored. So:

function f1(propertyName) {
var myVar = someObject[propertyName];
// in the particular:
// var myVar = document.formName[propertyName];
}

 

[Mick White]

bmgz wrote:
[...]

function(myParam){
var select1 = document.myForm.myParam;
}

It doesn't work, ive tried umpteen variations with []+ "" '' etc..
How would I do this stupid-simple thing?

Are you passing an object or a string?

Mick

 

[bmgz]

bmgz wrote:
[...]

function(myParam){
var select1 = document.myForm.myParam;
}

It doesn't work, ive tried umpteen variations with []+ "" '' etc..
How would I do this stupid-simple thing?

Are you passing an object or a string?

Mick

An object, I want to know how to refer to the object that triggered the
function?

 

[bmgz]

bmgz wrote:
[...]

function(myParam){
var select1 = document.myForm.myParam;
}

It doesn't work, ive tried umpteen variations with []+ "" '' etc..
How would I do this stupid-simple thing?

Are you passing an object or a string?

Mick

An object, I want to know how to refer to the object that triggered the
function?

oh um, from within the function itself..
ie.

function(){
var a = "[the object that called me ie. myButton]";
}

<input type="button" name="mybutton" onclick='function();' />

 

[RobG]

bmgz wrote:
[...]

An object, I want to know how to refer to the object that triggered
the function?

oh um, from within the function itself..
ie.

function(){
var a = "[the object that called me ie. myButton]";
}

<input type="button" name="mybutton" onclick='function();' />

You have to pass a reference in your onclick:

<input type="button" name="mybutton" onclick="function(this);" />

in the script of your onclick use 'this' ---------------^^^^
Then in your function:

function( a ){
alert( 'the object that called me is ' + a );
...
}

or

function(){
alert( 'the object that called me is ' + arguments[0] );
...
}

 

[VK]

want to know how to refer to the object that triggered the function?

from within the function itself..

Oh I see now... It depends on how your function was called: by event
capturer or by another function during normal program flow.

If by event capturer, then you simply *cannot* do it.
At least nothing reliable that would work for all browsers. You can do:

function myFunction(e) {
// "e" argument is important placeholder
// in case of working in NN/DOM event model
// IE sets global "event" variable for you
var myCaller = (e)? e.currentTarget : event.srcElement;
}

Of course you have to add event capturers programmically in this case.
You cannot do <element onclick="myFunction()">,
Empty parenthesis will kill the "e" and the script will fail for FF &
Co
You have to:
obj.onclick = myFunction;
or
using addEventListener (DOM) / attachEvent (IE) methods

This works fine as long as there is no more elements below the element
that capturing events. Otherwise all this mess fails onto the ground.
In FF you still can get the right object by using currentTarget. But in
IE event.srcElement will point to the first element in the bubble
history. So in the majority of situations your only option is to use
intrinsic capturers and "manually" forward the right object to the
function: <element onclick="myFunction(this)">

If your function is called by another function during normal program
flow, you can check the caller property.
function myFunction {
if (myFunction.caller != null) {
myCaller = myFunction.caller
}
else {
// I'm the first one!
}
}

P.S. There is a lot of bubbles in docs about "caller is deprecated".
But deprecation doesn't mean "removal", it means "substitution". As
long as *no one* provided a reasonable substitution for caller, we just
keep using it. It's supported by all main browsers.

 

[Michael Winter]

want to know how to refer to the object that triggered the function?
from within the function itself..

[snip]

If by event capturer, then you simply *cannot* do it.

Of course you can.

<... onclick="myFunction(this);">

function myFunction(element) {
/* The element argument is a reference to the HTML element */
}

Or:

<... id="myElement">

document.getElementById('myElement').addEventListener(
'click',
function() {
/* The this operator refers to the HTML element, myElement */
},
false
);

Or:

<... id="myElement">

document.getElementById('myElement').onclick = function() {
/* The this operator refers to the HTML element, myElement */
};

function myFunction(e) {
[...]

var myCaller = (e)? e.currentTarget : event.srcElement;
}

You've been told before that referring directly to the event identifier
is not wise as it could be undefined in some browsers. Refer to it via
the global object and test that it exists.

Also, the above could produce very wrong results: the currentTarget and
srcElement properties refer to very different things. The former is the
same as the element variable or the this operator in my examples, whilst
the latter (and the target property) refer to the original element that
fired the event.

Of course you have to add event capturers programmically in this case.
You cannot do <element onclick="myFunction()">,
Empty parenthesis will kill the "e"

So instead, one could write:

<... onclick="myFunction(event);">

or to be really cautious:

<... onclick="myFunction(('object' == typeof event) && event);">

The first argument to myFunction will either be false or an event object.

[snip]

P.S. There is a lot of bubbles in docs about "caller is deprecated".
But deprecation doesn't mean "removal", it means "substitution".

Deprecation often means this feature may be removed in the future, and
more generally, this feature should not be used.

As far as ECMAScript is concerned, the caller property has never
existed, which is potentially a bigger concern than whether or not it is
deprecated.

Finally, the caller property doesn't provide the information that the OP
wants, at least as I understand the problem.

As long as *no one* provided a reasonable substitution for caller, we just
keep using it.

If a function must really need to know what called it, then it should
have a required argument that contains a reference to the relevant
function object. No-one needs to provide a substitute for the caller
property as it isn't necessary.

Mike

 

[VK]

from within the function itself.

That was the keyword in OP. The "manual feeding" of the right object
was already given by RobG.
But what if we need to keep our HTML/XML code and scripting totally
separate?
The code below illustrates the problem many posters in this group
really encounting (even w/o knowing it):

<html>
<head>
<title>Event target</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
<script type="text/javascript">
function init() {
document.getElementById('DIV1').onclick = f1;
}

function f1(e) {
var myTarget = ((e)&&(e.currentTarget))?
e.currentTarget : event.srcElement
alert(myTarget.id);
}

window.onload = init;
</script>
</head>

<body>
<div id="DIV1">DIV 1
<span id="SPAN1">SPAN 1</span>
</div>
</body>
</html>

Click on "SPAN 1" (nested element). FF still works properly grace to
the e.currentTarget property. This is actually why you should not use
e.target unless you're making some event tracking.
e.target will fail in any more or less complicated situation.

event.srcElement shows as before the original event source (SPAN1).
There is *no* way to tell from the function itself that the actual
event capturer is DIV1. The only side walk is using closures with
memory leak in IE.

You find a way (w/o closures, w/o inline "helpers") - you'll be better
than the whole Microsoft. ;-)

 

[Michael Winter]

On 19/06/2005 17:12, VK wrote:

[snip]

But what if we need to keep our HTML/XML code and scripting totally
separate?

I just demonstrated how to accomodate that, and I've done it several
times in the past, too.

[snip]

Mike

 

[VK]

I just demonstrated how to accomodate that,

and I've done it several times in the past, too.

(1) <... onclick="myFunction(this);">

Manual feeding of the right object to the function I just mentioned.
Not an option in many cases (like OP)

(2) document.getElementById('myEle­ment').addEventListener(
'click',
function() {
/* The this operator refers to the HTML element, myElement */
},
false
);

A closure I just mentioned. A memory leak in IE. Can spit on it I guess
in *small-scale* projects(?)


(3) document.getElementById('myEle­ment').onclick = function() {
/* The this operator refers to the HTML element, myElement */
};

Anonymous functions... May get really ugly in big projects. Also forget
about reusable .js libraries you could use in your code. Of course you
could wrap named functions, but it brings you right back to the
situation (2)
On a *small scale* is well usable though.

So (2) and (3) may be used by OP unless "this and that". Should be
close the topic?

 

[Michael Winter]

On 19/06/2005 20:02, VK wrote:

[snip]

(1) <... onclick="myFunction(this);">

I wasn't referring to that one.

[snip]

(2) document.getElementById('myEle­ment').addEventListener(
'click',
function() {
/* The this operator refers to the HTML element, myElement */
},
false
);

A closure I just mentioned.

That isn't a closure. That is two function calls with a string argument
passed in the first call, and a string, function expression, and boolean
passed in the second.

If this code is executed in a function then the function expression will
become an inner function and, as it survives after the outer call
returns, it will form a closure. However, that isn't an issue in itself
and, as written...

A memory leak in IE.

....the problem in IE that you refer to will not occur.

Given a more realistic implementation:

function listener(e) {
/* Some event listener */
}

function addListener(elementId) {
var element;

if(document.getElementById) {
element = document.getElementById(elementId);
}
if(element && element.addEventListener) {
element.addEventListener('click', listener, false);
}
}

there is still no problem as a closure isn't necessary. Altering it
slightly to use a closure (because sometimes they are necessary):

function addListener(elementId) {
var element;

if(document.getElementById) {
element = document.getElementById(elementId);
}
if(element && element.addEventListener) {
element.addEventListener('click', function(e) {
/* Some event listener */
}, false);
}
}

we now do have the potential for a memory leak in IE because the
reference in element will persist. However, that is trivial to deal with:

function addListener(elementId) {
/* ... */

element = null;
}

No circular reference. No memory leak.

Even if element had to remain for the benefit of something else (for
example, it's a private member in an object) the reference can be
cleared when the unload event is fired, so we still don't have a problem.

(3) document.getElementById('myEle­ment').onclick = function() {
/* The this operator refers to the HTML element, myElement */
};

Anonymous functions... May get really ugly in big projects.

The use of a function expression was for my convenience, just as it was
with the addEventListener example in my previous post. Nothing prevents
the use of function declarations, or function expressions assigned to
identifiers.

Also forget about reusable .js libraries you could use in your code.

I have no idea what makes you think that, unless you're using some badly
designed libraries.

Of course you could wrap named functions, [...]
What!?

[snip]

So (2) and (3) may be used by OP unless "this and that". Should be
close the topic?

Perhaps you should just refrain from commenting on it until you know
what you're talking about. I'm sorry for being so harsh, but from
experience in previous threads, you seem incapable of understanding the
issues. Maybe I'm not providing decent explanations, but if that's the
case, you've never said anything to help me help you.

Mike

 

[VK]

Maybe I'm not providing decent explanations,

but if that's the case, you've never said anything
to help me help you.

Maybe Michael, and sorry if I'm "trolling" sometimes from your point of
view. But this group is not my place of work, but a place to put some
of my thoughts onto the public view and discussion. As long as I follow
the group netiquette, it's fine I guess.

To really close this topic (that really started a few month ago), let
us this question to the ground-zero level:

Below is the HTML. The task: acting only from within scriptboded code
(<script></script> section) insure that no matter where did I click (on
div or span) I always get in f1() the real event capturer (which is
DIV1). You can change the <script></script> section in any way you
want. The <body></body> section is out of your control. No more
quotations. Just the code, the task and you.


<html>
<head>
<title>Event target</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
<script type="text/javascript">
function init() {
document.getElementById('DIV1'­).onclick = f1;



}


function f1(e) {
var myTarget = ((e)&&(e.currentTarget))?
e.currentTarget : event.srcElement
alert(myTarget.id);


}


window.onload = init;
</script>
</head>

<body>
<div id="DIV1">DIV 1
<span id="SPAN1">SPAN 1</span>
</div>
</body>
</html>

 

[Michael Winter]

On 20/06/2005 14:21, VK wrote:

[snip]

The task: acting only from within scriptboded code (<script></script>
section) insure that no matter where did I click (on div or span) I
always get in f1() the real event capturer (which is DIV1).

[snip]

At its simplest:

<script type="text/javascript">
function f1() {
alert(this.id);
}

window.onload = function() {
document.getElementById('DIV1').onclick = f1;
};
</script>

Mike

 

[VK]

<html>
<head>
<title>Event target</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
<script type="text/javascript">

function f1() {
alert(this.id);
}

window.onload = function() {document.getElementById('DIV1').onclick =
f1;};
</script>
</head>

<body>
<div id="DIV1">DIV 1
<span id="SPAN1">SPAN 1</span>
</div>
</body>
</html>

Michael Winter,
if it's not a circular reference as you say,
then your're my hero, and I'm an a**hole

 

[Richard Cornford]

VK wrote:

... . As long as I
follow the group netiquette, it's fine I guess.

<snip>

But you don't follow the group netiquette. the vast majority of your
posts to date have been mal-formed, lacking quoted material to provide
context for the responses. And in creating mal-formed posts you have
encouraged your corespondents to do likewise, diminishing their chances
of getting responses from informed contributors to the group.

Richard.

 

[VK]

But you don't follow the group netiquette.

the vast majority of your posts to date have
been mal-formed, lacking quoted material to provide
context for the responses. And in creating mal-formed
posts you have encouraged your corespondents to do
likewise, diminishing their chances of getting responses
from informed contributors to the group.

I see this fault only in long thread, there are sometimes 20-40 posts.
Should I include the entire thread in each of my post? Or sould I do
some kind of a self-censorship by including only selected posts and
parts? I can start include the entire body of the parent post I'm doing
a follow up for. Would it be a solution? (very inconvenient though as
I'm using Google groups so I have to ">" manually)

 

[Michael Winter]

On 21/06/2005 14:51, VK wrote:

[Not quoting previous posts]

I see this fault only in long thread, there are sometimes 20-40 posts.

It doesn't matter how long a thread is. A reader might want to jump to
the end of a long thread. That reader really shouldn't need to have read
every single post along the way - they should be able to understand the
gist of the conversation at whatever point they enter.

Should I include the entire thread in each of my post? [...]

No. You should do what all of the regulars do when posting: quote any
text that is relevant to the point you are trying to make so it is clear
what you are responding to. Everything else should be deleted,
preferably including some indication that you have omitted something.

Mike

 

[Randy Webb]

I see this fault only in long thread, there are sometimes 20-40 posts.
Should I include the entire thread in each of my post? Or sould I do
some kind of a self-censorship by including only selected posts and
parts? I can start include the entire body of the parent post I'm doing
a follow up for. Would it be a solution? (very inconvenient though as
I'm using Google groups so I have to ">" manually)

Please don't quote an entire post. Its only requested that you quote the
parts that you are replying to and leave enough attribution to show who
posted what.