passing a function name to another funtion

K

Kevin Blount

I have a system that I want to try, which requires me, from an aspx
page, to call a generic function to work perform one task, then i want
to call another function with the results of that task.

something like this:

in my aspx page:
<input type=button onClick="doFirstFunction('secondFunctionName');">

then in my .js file:

var functionToCall = '';

function doFirstFunction(functionName) {

functionToCall = functionName

// do the initial, common task
sResult = xmlHttp.responseText

//now call the second function, passing sResult to it

}

Right now I'm using 'switch' and manually adding possible values for
'functionName' then directing manually, but I'd like to make
"doFirstFunction" self-maintaining, i.e. without having to update it if
I add more 'second' functions later.

I thought I could use

eval('functionToCall('+sResult+')');

but this doesn't work so far.

any ideas?
 
V

VK

Kevin said:
I have a system that I want to try, which requires me, from an aspx
page, to call a generic function to work perform one task, then i want
to call another function with the results of that task.

something like this:

in my aspx page:
<input type=button onClick="doFirstFunction('secondFunctionName');">

Remove apos' and it will become ready to use function reference
(presuming that the secondFunctionName exists at the moment of click:
<input type="button" onclick="firstFunction(secondFunction);">
....
function firstFunction(ptr) {
// do stuff
ptr();
}

Alternatively (if you prefer handle strings) all existing functions are
tunelled through the window object, so:

<input type="button" onclick="firstFunction('secondFunction');">
....
function firstFunction(str) {
// do stuff
window[str]();
}
 
R

Randy Webb

VK said the following on 4/21/2006 4:22 PM:
Remove apos' and it will become ready to use function reference
(presuming that the secondFunctionName exists at the moment of click:
<input type="button" onclick="firstFunction(secondFunction);">
....
function firstFunction(ptr) {
// do stuff
ptr();
}

ptr is undefined unless that is the name of the function.
Alternatively (if you prefer handle strings) all existing functions are
tunelled through the window object, so:

<input type="button" onclick="firstFunction('secondFunction');">
....
function firstFunction(str) {
// do stuff
window[str]();
}

That is the only way to do it that you have mentioned. And the apos'
have to be on the initial function call.
 
V

VK

Randy said:
ptr is undefined unless that is the name of the function.

Are you positive about it? ;-)

<html>
<head>
<title>F2F</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script type="text/javascript">
function f1(ptr) {
alert('f1');
ptr();
}
function f2() {
alert('f2');
}
</script>
</head>

<body>
<p style="cursor:pointer; color:#0000FF; text-decoration:underline"
onClick="f1(f2);">Click me</p>
</body>
</html>
 
V

VK

Captain said:
Are entities (objects, whatever you call them) all elements in a window
array? (Sorry if this is newb Q; I am fairly new to javascript...)

They are "accessible as named properties of the window object" (I hope
that this diplomatic answer covers both IE and non IE situations wich
are rather different).
At the same time they are not enumerable.

The above means that having a conventional HTML page and function
called myFunction, you can call it in the conventional way:
myFunction();
and in the alternate way:
window["myFunction"]();
 
T

Thomas 'PointedEars' Lahn

VK said:
Alternatively (if you prefer handle strings) all existing functions are
tunelled through the window object, so:

<input type="button" onclick="firstFunction('secondFunction');">
...
function firstFunction(str) {
// do stuff
window[str]();
}

Better:

// in global context
var _global = this;

function firstFunction(str)
{
// do stuff
_global[str]();
}

Both approaches require that secondFunction() is declared in global context,
of course.


PointedEars
 
T

Thomas 'PointedEars' Lahn

VK said:
They are "accessible as named properties of the window object" (I hope
that this diplomatic answer covers both IE and non IE situations wich
are rather different).

It covers /only/ the _HTML environment_ in _known_ _graphical_
_Web browsers_, which is its major flaw.
At the same time they are not enumerable.

In the IE AOM.
The above means that having a conventional HTML page and function
called myFunction, you can call it in the conventional way:
myFunction();
and in the alternate way:
window["myFunction"]();

See

PointedEars
 
V

VK

Thomas said:
It covers /only/ the _HTML environment_ in _known_ _graphical_
_Web browsers_, which is its major flaw.

The statement "window host object and Global object are the same"
covers only non-IE based browsers. The statement "Global object
tunells/peers its members through the window host object" covers
IE-based browsers. Both segments are too big to neglect, so an
"abstracted" yet correct explanation is better IMHO if it's not the
main question of the topic.

<offtopic>
Concerning some beloved spooky cases "Global object is here, but window
host is not": no one of them unfortunately is qualified to be taken
seriously.
Adobe SVG Viewer or Corel SVG Viewer are ancient and proprietary
plugins which are not more of anyone's concerns than say some
FoobarPlugin 0.01 behavior. Whatever happens where - it happens, and
thanks God if you come out alive :)

And missing window host in a XSLT transformed page or a SVG page is not
a feature of the relevant formats, but a strong sign of a clueless
design. It just shows that the author still did not get that in XML the
used *parts* are not anyhow equal to the *resulted document*. In the
particular she may missed to tell in .xsl layout something like:
<xsl:eek:utput
method='html'
media-type='text/html'
version='4.01'
doctype-public='-//W3C//DTD HTML 4.01 Strict//EN'
doctype-system='http://www.w3.org/TR/html401/strict.dtd'
encoding='ISO-8859-1'
indent='no'/>
And again in this case no one is more responsible for the script
behavior than say in case of not closed properly <script> tag.

In the IE AOM.

As a reflection of Global/window differences in IE I started this post
with.
 
T

Thomas 'PointedEars' Lahn

VK said:
The statement "window host object and Global object are the same"
covers only non-IE based browsers.

It covers exactly _no_ browser.


PointedEars
 
V

VK

Captain said:
How do I test for existence of
such an entity?

if(window["myFunction']) window["myFunction"](a,b,c);

Within the conditional checks JavaScript resolves empty strings, 0,
null, undefined and NaN to false.

Non-empty strings, non-zero numbers and references of any kind are
resolved to true.

If property doesn't exist, you'll get undefined which is covered by the
list above. So the frequently used way is:

// undefined gets resolved to boolean false:
if (window["myFunction"]) { window["myFunction"](); }
else { alert("Function doesn't exists"; }
 
T

Thomas 'PointedEars' Lahn

VK said:
Captain said:
How do I test for existence of such an entity?

if(window["myFunction']) window["myFunction"](a,b,c);

Within the conditional checks JavaScript resolves empty strings, 0,
null, undefined and NaN to false.

Evaluated, not resolved. And that goes for all ECMAScript implementations.
Non-empty strings, non-zero numbers and references of any kind are
resolved to true.

Evaluated, not resolved.
If property doesn't exist, you'll get undefined which is covered by the
list above. So the frequently used way is:

Probably used by /you/. Along with your other numerous failed attempts at
proper programming.
// undefined gets resolved to boolean false:
if (window["myFunction"]) { window["myFunction"](); }
else { alert("Function doesn't exists"; }

However, much better is:

// in global context
var _global = this;

// anywhere "after" the above
if (typeof _global["myFunction"] == "function")
{
_global["myFunction"]();
}
else
{
window.alert("Function does not exist");
}

Under the provision that `myFunction' is declared globally.

And the bracket property accessor is not necessary at all
if you already know the identifier: _global.myFunction

If all the code is in global context, one can use `this'
explicitly and does not have to declare the `_global'
variable. And `typeof myFunction' would suffice then.


PointedEars
 
L

Lasse Reichstein Nielsen

Randy Webb said:
VK said the following on 4/21/2006 4:22 PM:

ptr is undefined unless that is the name of the function.

ptr is a parameter (and therefore a local variable) of firstFunction.
It is declared in the context where it is used, and will have a value
if one is passed to firstFunction, as it appears from the usage
that one is.
It's not undefined, and it's independent of the name of the function
being passed.

This is the best way to pass functions to other functions: as values.
Passing their names and requireing an explicit lookup is much more
fragile, less readable, requires the passed function to be globally
availalbe, and is all together unnecessary if you have the function
available where you call the first function.
That is the only way to do it that you have mentioned. And the apos'
have to be on the initial function call.

That's the only way to pass a function's name, which was what to OP
asked for.
It's definitly not the only way to have one function call a second,
where which second function is called is controlled by a parameter of
the first, which perhaps was what to OP really wanted.

/L
 
K

Kevin Blount

I finally got back around to this, and found that this solution worked
perfectly. Manty thanks VK
 
R

RobG

Kevin said:
I finally got back around to this, and found that this solution worked
perfectly. Manty thanks VK

Please don't top-post.


No, they aren't[1].

Functions may be accessed through a property of the global object where
they are declared in a global scope or the value of a global property is
assigned a reference to a function (e.g. using function expression).

In browsers, the window object is equivalent to the global object, but
not all user agents are browsers and not all have a window object.


1. What does 'tunelled' mean in a JavaScript context? The correct
spelling is 'tunneled', and when used in an IT or computing context
refers to the encapsulation of one network protocol inside another. It
is normally used to transport a network protocol across a network that
otherwise wouldn't support it. I don't see how that applies to
JavaScript at all.
 
R

RobG

RobG wrote:
[...]
1. What does 'tunelled' mean in a JavaScript context? The correct
spelling is 'tunneled'

'Tunneled' is the US spelling, 'tunnelled' is the English spelling
(Oxford dictionary).
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,764
Messages
2,569,566
Members
45,041
Latest member
RomeoFarnh

Latest Threads

Top