In an ASP.NET application, whenever a control on a page is called, the action causes the entire page to reload. This is because the action is sent to the web server and the web server response is a new page that the browser draws to the screen. It may look exactly like the old page, and have the same name, but it's actually a new page.
For most websites, this isn't a problem. We don't spend a lot of time on interactive controls that require communication to the server, and so when a user presses a button like "SUBMIT" they are happy to wait a few moments for the page to reload and results to appear.
Unfortunately I was recently faced with a challenge where this situation of page reloading was a problem. I wrote a software package that allows customers to do data entry on magnetic tapes. Basically the customer is sending the tapes to a warehouse for protective storage. They data enter the tape's information into the system so that if they ever need to retrieve the tape, they can look it up based on various criteria they have entered. Typically this includes a barcode number, a description, and a date when they want the tape returned to them.
The date on the form was built with a third party control that is pretty heavy. The data control pops out a graphical calendar that allows the customer to select dates based on day, month and year, and then it synchronizes what was selected with a visible date text field on the form. Both of which are different styles of the same calendar control. The calendar control is heavy because it needs to calculate the dates years into the future. So if a customer wants to get a tape back in 2020 on leap year, the calendar control will allow them to do that. However, doing a refresh everytime a new date is chosen is cumbersome, so all of the dates are handled in Javascript and the calculations are done prior to the control landing on the page. Calculating two sets of 130 years worth of dates takes a few seconds longer than normal.
All of which wouldn't be a problem by itself, as we're all use to slow websites. The problem here is that the customer wants to use an attached scanner. An attached scanner is a barcode scanner that you program to fill in information on a data entry screen automatically. So you can sit at your desk and scan tapes one at a time... beep.... beep... beep... as each tape scans, the data is written to the screen and the submit button is pressed.
Herein lies the problem. As the screen refreshes it takes so long for it to come back (We're talking on the order of 5 seconds) that the person doing the barcode scanning has scanned too quickly and the data has now been entered incorrectly, requiring a hand fix.
The cry came out... "Can you make this any faster?"
Now, for the record, the calendar control isn't the only thing that slows it down. When the submit button is pressed, calculations and comparisons are conducted against a SQL server and FoxPro OLEDB database that tests whether or not we have a duplicate tape, or if the security credentials are legit, etc. These processes happen in moments but as you add the moments together, things start to slow.
However, the largest culprit is the calendar control, so not having to reload it on every page submission would be ideal, and the best way to handle this is through Ajax.
Ajax is a way of passing back and forth data that has changed on the page. While leaving everything else the way it was previously. So when the submit button is pressed, the same calculations and comparisons are formed, but the result isn't a brand new page, but the old page updated. This alleviates having to reload the calendar control on each tape entered.
My understanding of how Ajax works is limited. I know you need a javascript function on the client side that communicates to the web server, and the web server needs some sort of applet that sends the data back, and then more javascript code updates the controls. It sounds a bit nightmarish to me, because I build all my controls dynamically to the page. I do this because the customer wants their controls laid out a specific way, and that may differ from customer to customer. And so each control has a unique name that is built during runtime and Javascript, traditionally, doesn't have any way of knowing what these controls are called without me telling it beforehand. (At least so much as I've worked with it.)
So I expected to read through the new Microsoft Ajax documentation and find myself being overwhelmed with thinking up ways to syncrhonize the client script with the codebehind that I was developing with. Instead, I was told that if I put four lines of code on my page, I would be using Ajax.
Basically you put down code in the presentation (HTML) layer that looks like this...
<asp:ScriptManager ID="ScriptManager1" runat="server">
</asp:ScriptManager>
<asp:UpdatePanel ID="UpdatePanel1" runat="server">
<ContentTemplate>
</ContentTemplate>
</asp:UpdatePanel>
Everything between the two ContentTemplate tags is suddenly Ajax enabled. That's it. That's all that has to be done. Because my controls are built dynamically, I had 9 placeholders on the form. So I wrapped those placeholders with the ContentTemplate tags and reran the application. Sure enough, everything worked perfectly and was now Ajax enabled.
I feel like I'm missing something. It shouldn't be this easy. I can go back through my old applications and make them Ajax enabled in short order with minimal effort. It may be that because I design my software to be less reliant on client scripting and focus almost exclusively on the codebehind, that my implementation of Ajax is easier than what other people face. But whatever the case, it's like my applications have been given a power-pill to suddenly become better than they ever were before. All without requiring a single code change and only a slight modification to my presentation layer.
I figure, at some point I'll end up revisiting this subject because I'll find the piece that I missed has reared its ugly head and my impressions about it being so easy will be thrown out the window, but so-far, everything is now Ajax enabled without the slightest bit of effort. How great is that?