GammaGeek: Ajax mistake

Sunday, October 23, 2005

Well, I recently had my first opportunity to work on an AJAX application.

I do some work for a friend of mine who runs a business doing consulting/development work for ministries.

He asked me to implement an AJAX solution to a form.

In essence, he wanted a form that would display a form and when a specific checkbox was checked, additional fields from the form would show up. Now, the first failure I had was that I didn’t look carefully at the requirements of the project before beginning.

I did many of the main things first such as identifying the desired goal, identifying my starting point and doing the research to figure out how to go about accomplishing my task.

However, what I failed to do was look at the project and compare technologies to see which would work best.I was able to get the main functionality working.

However, this is where my lack of detail comes in.

I failed to anticipate all the other things that would be required of the project.

Instead of simply getting the form to show up, one of the things that I should have done as a good programmer is to make options for what happens when bad data is entered into the form.When you enter data into a form online and there is some sort of error in the data such as the password having too few letters or the user accidentally entering a pipe ‘|’ character into his name, many of you will attest to the fact that you expect certain behavior.

If I were in that situation, I would expect the form to return back to me with my error clearly explained and all the correct data that I had entered the previous time would be prepopulating the form so I could simply re-enter the incorrect field and submit.

If I had to re-enter my data, I would assume that was a poor developer or a bad site.But I made a mistake when I worked on it and didn’t assume that.

I turned the project in and of course two days later, this friend contacted me and said there was a problem. So I set in to try to fix this problem in the code.

That’s when I discovered the other error I’d made, that of not comparing technologies.

As you may be aware, HTML is a stateless protocol, meaning that it does not remember where you are, what you’ve entered, where you’ve been or know where you want to go.

It simply displays what it’s told.

So developers have had to come up with other ways of remembering that you are Joe Websurfer and you just entered that you live in Fargo, N.D.

Here is where the Ajax mistake comes in.

Ajax does not deal well with the tools that maintain state.

It is possible to set cookies or to use a scripting language like PHP to set global variables but when the XMLHTTPRequest is made, unless you use the GET method in the URL, it doesn’t remember those global variables.

Cookies are the only option.

However, cookies get messy. I was just about to work on implementing a cookie solution when I thought a little more about my project.

In essence, all I was needing was to hide some form fields until a box was checked.

This is exactly the kind of thing that some simple Javascript will excel at. Long story short, I changed the code from using an XMLHttpRequest to using the display:none; feature in javascript.

I checked the status of the checkbox and altered the display based on that value.

I hope to go more into detail on my site later (). Just chalk this one up to eagerness to use a ‘new’ technology when an existing one worked so much better.Anyone learning coding, I hope you take that warning.

Make sure that the tool you’re using is really the best one for the job.

And make sure you familiarize yourself with a variety of technologies.

When all you have is a hammer, everthing begins to look like a nail.MN

posted by MikeyN @



Previous Posts

Leave a Reply

Your email address will not be published.