(Note to readers: I leave on vacation tomorrow, so I will be posting sporadically next week if at all. I expect to be internet inaccessible for a few days. My family will be in Phoenix and Las Vegas.)
It used to be that Ajax was a scouring powder. Actually, it still is, but to us geeks there is also AJAX (all upper case) which stands for “Asynchronous Javascript and XML”. When a web developer programs in AJAX they can do cool things that markedly improves the usability of a web interface. Perhaps the most prominent example of AJAX in use was one of its pioneering applications, Google Maps. Somehow, wholly within a browser and without refreshing the page, Google was able to do things that hitherto seemed impossible, such as moving a map by dragging on the image. The new map images are fetched in the background; the web page itself is not redrawn.
This magic is possible in large part because finally we are using newer browsers. Hidden inside your browser is something called the XMLHttpResponse object. This little sucker makes it possible for your browser to contact the server without redrawing your web page. This seems like such obvious functionality you have to wonder why it was not designed into the browser ten years ago. Part of the reason was that HTML (the language used to describe web pages) was not standardized at that time. Both Netscape and Microsoft were unwisely adding nonstandard tags to differentiate their browsers. This had the effect making life hell for us web developers. In addition, the other part of AJAX, the XML part, did not even become an official standard until 1999. It took many years for the browser makers to agree they all needed to work from common references. The common references were HTML, Javascript (a programming language that lets your browser do dynamic things) and something weird called the HTML Document Object Model. The World Wide Web Consortium is the standards organization that created these standards.
Now that browser manufacturers are testing to a common set of standards, web developers can breathe easier. There are still browser quirks that need to be programmed around, but they are largely minor annoyances now. More importantly since these three components can be taken for granted at least 98% of the time it becomes possible for web browsers to do amazing things that used to require installing separate programs on your desktop computer. The logic to make it work in your browser gets a bit complex at times but it is possible to emulate most of the rich functionality of a desktop application inside the browser. Most web developers, however, have yet to dip their toes into this AJAX stuff. Until about a week ago, I was one of them.
I dallied because being a web developer is a very part time gig for me. My full time job is in Information Technology management, not in programming. You can make a programmer a manager but some part of the manager remains a programmer. On nights and weekends, I have been dipping my toes into the AJAX world. It is not entirely a waste of my time. I have a few practice domains where I can try this stuff out without embarrassing myself. What I learn I can often apply to my job. For example, we have a need to collect names and email addresses to run a customer satisfaction survey for the system that I manage. If we can avoid the overhead of having a page refresh, we can drop the form onto many of our web pages without disrupting their flow of business. This allows us to target particular kinds of system users so we can get a better response rate to particular kinds of questions.
I run two other domains. I use the Oak Hill Virginia site as my test bed. It is designed to be a community web site. While it does not get much in the way of traffic, judging from the ads served on my site by Google it is of interest to the real estate community. When I purchased the domain in 2001 there were little in the way of tools that I could use to integrate real estate content into my site. Fortunately, that has changed. Working with the husband of a local realtor, I became aware two sites. Zillow.com offers a home valuation service. Trulia.com offers a real estate search engine that can plop houses for sale on top of Google Maps. Both offer APIs, or Application Programming Interfaces. This means a developer like me can register to use their APIs and embed them in my web sites.
My first AJAX project was to integrate the Zillow.com home valuation service into my site. I did not want my page to refresh. I simply wanted someone to enter the address of a house and have its price unobtrusively appear on my web page. This could only be done using AJAX. My original hope was that I would not have to write any proxy script for my website to get the home price from zillow.com. Unfortunately, browsers have security mechanisms built in. Unless you specifically configure your browser otherwise, it cannot use the XMLHttpRequest object to call any other server other than the server that served the web page. (Not only that but the browser will assume http://www.domain.com is not the same server as domain.com.) Therefore, I had to create a proxy script on my server, which I wrote in PHP. It took the address and simply passed it on to zillow.com. It waited for a response from zillow.com then echoed back the value of the home. Zillow.com’s API, like most, uses a REST based XML service. It avoids the overhead of using SOAP. However, the lack of standardization in the REST world meant that I had to fine-tune my script to accommodate the eccentricities of the zillow.com API. Still, this was easier than dealing with the overhead of getting the data as a SOAP service.
It took about a day of development but I was able to make it work. You can see the service on my oakhillva.com website. I found the W3 Schools web site to be invaluable. It has a simple AJAX tutorial. I copied, pasted and changed a few things from their example to get it to work. To make the form usable I also had to dig into their HTML DOM reference and research a few things I forgot from their Javascript reference.
Now could I write my own AJAX web service instead of relying on someone else’s service? I created a contact form where people interested in buying or selling property in my community could simply type in their information and it would be sent to a local realtor. This was not that difficult a service to create either. For both services, I found I wanted to record information received into a MySQL database table on my server as well as have the service send me an email whenever someone invoked it. Since I know MySQL and its programming API rather well this was not terribly challenging. In addition, PHP comes with a handy mail function, so it was also straightforward to have the services send me email. Eventually if the services prove to attract sufficient contacts, the contact information will go automatically to the realtor. Right now, I am reviewing content for spam.
AJAX applications like Google Maps are of course an order of magnitude more complex than my little AJAX applications. For most of us in the IT business though, we early our bread and butter through standard business applications like these. Eventually as time permits I hope to create a real estate page for the site, integrating the service from Trulia.com that lets me show local home listings in Google Maps, and serving related ads (mostly from realtors) around the content.
Whether I will succeed in my ultimate goal of making this site profitable remains to be seen. I have learned a few things along the way: AJAX programming is not too hard if you have a decent understanding of HTML, Javascript, the HTML DOM and a server scripting language. My applications so far are simple, returning a single value. If I need to return multiple values in a single call, I will have to delve into the details of using the XML parser built into browsers, plucking and displaying the content that way.
If you do a View Source on my oakhillva.com web site, you can see the client side logic I used. I have exposed my PHP server side code for my real estate leads service in this file. I had to obscure certain information for security purposes, of course.
Leave a Reply