Stephen Cote

In IE's event model, the event object accessed as a global property on the window object, which makes it a global object and the "window." prefix is implied. In W3C event-compliant browsers, the event object is the first argument of the handler.

evt = (window.event) ? window.event : null;

This wouldn't work for non IE browsers because the evt variable now points to null instead of the event object. My preference when working with a single window frame is:

evt = (event) ? event : evt;

If evt is undefined to start with, then I don't see a point in setting it to null if it's going to be tossed out in the if(evt){ ... } condition.
[ November 22, 2005: Message edited by: Stephen Cote ]

Is there a reason you can't use addEventListener (non-IE) and attachEvent (IE) to add your own window onload event?

I would be careful with the DEFER attribute because if the script file gets cached, you aren't guaranteed that it will load after the other required script file containing the column code.

I'm assuming the "onxlick" should be "onclick" and you mistyped that.

One thing to check is to see if the requested resource is being served as text/xml. And, another thing to check is to make sure you can access the XML file at all with Mozilla.

You might try an alternate library for making the XML request as well, to see if this is an issue with prototype.js, an issue with your implementation of prototype, or an issue with your XML file.

Hi Deepika,

If you want to learn how to do this yourself, it might help by first separating out the various parts you'll need; the ingrediants.

1) You'll need an HTML Form to collect the data.

2) You'll need a way to collect the data from the HTML Form on the server, and that means you'll need to pick a server side language: .NET, Java, PhP - take your pick. You'll typically find somewhat consistent conventions, at least with dealing with HTML requests, but in this case the most important one is an object that represents the user's request. What you want to do is read the parameters from the user request. For example, if you have a form field with a name of "guest_name", then you would want to read out the "guest_name" parameter.

3) You'll need a place to save the collected data. Here I recommend you poke around for example code on whatever language you are using and whatever database you are using. It's only a google away: for instance: ASP.NET SQL Example, or PhP MySql Example.

After you get through all three steps, you should have a better understanding of how the pieces fit together. But, before you throw anything out onto the web, be sure to do a little research on form validation, sql injection, and script injection (aka cross-site scripting) to make sure you're not opening up any security hole.

JavaScript is interpreted and functions and object prototypes will consume memory when parsed, or for dynamic script, when evaluated. The memory is supposed be freed when no other reference to that object or function still exists. You will incur additional memory use by creating new instances of objects or functions. The difference is how many instances and closures you create with those implementations. There are also a number of caveats among the various browsers that result in memory leaks, such as stray event handlers and pointers (refer closures) at the time the document unloads.

Another thing to keep in mind is that JavaScript is single threaded. Objects available to JavaScript, such as XMLHttpRequest and the Browser DOM, may be multithreaded, but JavaScript is on one thread, asynchronous or no. Any claim JavaScript multi-threading should be assumed to imply psuedo-threading, or asynchronicity. Even if a multi-threaded object calls into JavaScript, JavaScript will have to handle those calls on one thread.

You can browse around for pseudo-threading libraries, or I have one in my rather large client-side library.

As far as lazy loading, you can start by verifying you are making asynchronous and not synchronous XML requests. I have a Cross Browser XML Library you can reference to see if that helps out at all. It includes connection pooling and response caching.

I think JavaScript has a lot of hidden and untapped potentional. I also think that potential has been already tapped, and only awaits rediscovery. Asking where it is going makes me wonder whether we need to re-examine the entire principle of the Web. The more we move JavaScript and Flash and XML and ActiveX towards a programming environment, the closer we return ourselves to a mainframe culture. How is improving JavaScript, et al, to the point that it becomes its own uber-language any different than the same mainframe environment that existed thirty years ago?

I think the main disadvantage is the expected end-user experience. People are conditioned to expect thick clients to behave one way, and Web applications to behave another. AJAX is nothing more than describing an approach to achieve the same effect of a thick client via a thin client. While I may seem dismissive about AJAX - which I am - I also recognize that it is now a part of our parlance, and that the chief hurdle is in helping the end-user to understand the principle of AJAX + Web = Thick Client mentality.

Fangs is a nice idea, but the trouble with using it to develop accessible Web applications is that you have to place a certain level of trust in Fangs to reproduce exactly what other software, such as JAWS, would produce for the accessibility-minded user. I used Fangs for about five minutes, four of which were "neat, nice, way-cool", and the last minute was, "uh, wait, this isn't exactly what JAWS is producing".

I don't think AJAX is going to affect blind users any more or less than before. If a Web application is developed with accessibility in mind, then the end result of any AJAX tranaction would include the requisite markup to be accessible, or otherwise it wouldn't.

Either the developers and/or business is accessiblility-minded, or it's not, and that will be reflected in the product, regardless of how that product is delivered, be it brick-and mortal, HTTP, Javascript + XML + HTTP (AJAX), or otherwise.

I created a framework for web applications (started on it in 2002; a lot of AJAX principles in it), and also have created a behavior monitor product that uses AJAX to send data.
[ November 11, 2005: Message edited by: Stephen Cote ]