Ajax - passing an argument to the callback function
Hi folk,
I'm new to Ajax and have managed to get some fairly simple things working. But I've got a question. When I set my callback function for the onreadystatechange event, is there any way that I can pass an argument to that callback function so that when it is called I can access that argument?
I can think of some workarounds to get similar behaviour, but if this is possible, it'd be the nicest way of doing things. I'm also having problems finding any good docs for the XMLHttpRequest objects - lots of tutorials and articles but no docs. Any idea where I should look?
I'm new to Ajax and have managed to get some fairly simple things working. But I've got a question. When I set my callback function for the onreadystatechange event, is there any way that I can pass an argument to that callback function so that when it is called I can access that argument?...
Yes.
It took awhile for me to figure this out though. I came up with what I think is a pretty easy solution to the problem. Here's a chunk of code where I'm setting up the XMLHttpRequest Object
Code:
// ********************************************************************************************
// **** Function that will be called to request the Record Count via the XMLHttpRequest object.
// ****
// **** Parameter list:
// ****
// **** XMLHttpRec - XMLHttpRequest Object
// **** sSQLRecCnt - SQL Select Statement that returns a value for a "rec_ct" column
// **** ElementID - ID of Element on screen that will be updated
// **** TitleURL - Title for Hyper Link that will include the record count
// **** QueueURL - URL for Hyper Link that will send user to the correct queue page
function getRecCount(XMLHttpRec, sSQLRecCnt, ElementID, TitleURL, QueueURL) {
// Abort any currently pending requests for this XMLHttpRequest Object
XMLHttpRec.onreadystatechange = function () {}
XMLHttpRec.abort();
// Get variables from form and build URL to call
var url = "GetRecCount.jsp?sSQLRecCnt=" + escape(sSQLRecCnt);
// Tell the XMLHttpRequest object what the url is and that
// you will use the "GET" response not "POST" to call the external url
XMLHttpRec.open("GET", url, true);
// Assign the name of the JavaScript function which will be called
// when the request completed then send the request
XMLHttpRec.onreadystatechange = function () {
UpdateScreen(ElementID, XMLHttpRec, TitleURL, QueueURL);
}
XMLHttpRec.send(null);
} // end of function
If you look at the onreadstatechange assignment you'll see that all I'm doing is assigning it to a dynamically created function which just calls another function that accepts arguments.
Pretty easy huh? (then why did it take me a week to figure out then )
Thanks - that looks brilliant, and nice and simple. I'll give it a go. I have to confess that I'm really a server-side programmer, and I've never had to code anything more than really basic Javascript before!
he's right though. there is actually no reason why you should need to add parameters to a call back function when you do this in a object oriented manner.
It was not meant as a bad thing, I do plenty of talks with user groups and show them basic OO JavaScript and they see how it will make their life easier and the lightbulbs go off in their head.
Examples of OO programming is look at the code of prototype, Dojo, any other the other major toolkits. I will try to get my basic Ajax panel example up and running. Basically with OO JavaScript it eliminates a lot of the problems people face.
I am here to help and not mock people. I could crawl into a dark hole like a lot of tech writers, but I am on more forums than just this one.
Ah, I forgot, we released the Appendix B of my book Ajax In Action on sun.com's new JavaScript section of their website. The appendix talks about OO JavaScript. People think that this is a nice intro to OO JavaScript. You can see it here.
he's right though. there is actually no reason why you should need to add parameters to a call back function when you do this in a object oriented manner.
Except for it using less code and having easier maintainability you mean ?
I'm not new to this stuff. I've used JavaScript Objects with properties assigned to them as simple structures years before and I thought that they were a major pain to maintain. Easier on the initial programmer. But for the guy who needs to make changes months or years to someone elses code, it can become a maintanence nightmare.
I've found that a simple list of arguments much "cleaner" and easier to maintain than an object with invisible, undocumented properties passed as an argument. (Especially in this case where there would be a tendancy to use globally defined variables instead of passed parameters)
In the called function you do not have the name of the properties, just the object name. If you have to go back to that function months or years later, you don't have the faintest idea what the name is for the variable/property you need to manipulate because it is not spelled out for you in the argument list. Instead you have to dig around through multiple functions, backtracing to where the the object is initially created. A huge pain in the behind, especially since all the the people who tend to code this way seem to hate commenting their code.
So - in this case - I really don't think you can improve in the simplicity and maintainabilty.
Last edited by slaughters; 06-08-2006 at 06:41 AM.
I'm not new to this stuff. I've used JavaScript Objects with properties assigned to them as simple structures years before and I thought that they were a major pain to maintain. Easier on the initial programmer. But for the guy who needs to make changes months or years to someone elses code, it can become a maintanence nightmare.
Well if you run into the problems that you mentioned in your post, than the code is probbaly coded wrong in my eyes. at the top of almost every script I write I list what the properties are and a sample call so anyone that needs to use it in the future will not have a problem.
One reason why OO is good is that you never will see global variables clashing like we see all the time in the forums when people say I want to use this script and this other script. If everything was coded correctly, it would not matter.
I used to hate OO JavaScript, but that is because I did not understand it fully. I am not saying that you don;t understand it, but that is from personal experience. There is going to be a flood of OO JavaScript in the near future in the book market, just because there is nothing out there that really talks about it.
I seem to have sparked off the old robustness vs. readability (or OO vs. non-OO) chestnut, oops :-) Thanks for the reminder Eric that OO is a sensible option here - I keep forgetting that Javascript lets you do that type of stuff, which is a bit silly given that an XMLHttpRequest is an object.
Well if you run into the problems that you mentioned in your post, than the code is probbaly coded wrong in my eyes....
I agree.
I just wish everyone was drilled drilled drilled on commenting their code in a standard way. Every teacher and every boss should fail any progam they receive that lack comments.
*SIGH*
Unfortunatly they don't. Or worse - they don't change the comments after modifying the way the code works.
I don't know which I hate worse. No comments at all, or comments which lie.
As a workaround to not being able to pass parameters to your callback, you can just pass them to your server and then have the server pass the parameters back to your responsehandler as part of the response vars. It's a bit roundabout, but it works.
Bookmarks