Stateless Web, ASP.NET and AJAX
One of the most common things in the universe, (besides hydrogen and bureaucrats) is the inability of the uninitiated ASP.NET developer to understand the stateless nature of how HTTP works. This is true not only for ASP.NET, but also for classic scripting platforms such as ASP and PHP.
I say this because we at eggheadcafe.com get lots of forum posts that revolve around this subject. Sometimes they center around attempts to write to the filesystem at the browser from server-side code (which is long gone), other times they question how to tell if somebody has closed their browser, and many other variations in between.
But the common theme is a misunderstanding of just how disconnected the server and the browser really are in a web application. This disconnectedness and State are the two central issues that web developers face, and are the basis of the evolution of web applications to include IFRAMES, javascript callbacks, the XMLHTTP object, and finally, Remote Scripting ("AJAX") and JSON (Javascript Object Notation).
Let's go over some basics: When you put a Uri in the browser's address bar, or click on a link in a web page, the browser makes an HTTP Request for that resource. The two most common types of request are GET and POST. GET transmits any additional information as querystring items, e.g. http://www.yoursite.com/pagename.aspx?username=Howard .
POST only occurs when a FORM element's submit method is called. This packages up field names and values into the BODY of the HTTP Request, not on the querystring.
The server receives this request and routes it to the appropriate place (a web page, an image, a piece of javascript, etc.) and the resource is "served" back to the client (browser). In ASP.NET, an ASPX web page is processed via an instance of the Page class. Page builds the Control Tree, parses the tags, does all the logic, and all this is assembled into POHTML (Plain Old HTML) and sent back to the browser. At this point, the Page class instance at the server is GONE. Zippo, nada, efes, nuttin! It's GONE. If you needed to "Save" something, some "state" of this transaction, you have to have a separate way of storing it. The ASP.NET Page class is compiled - not interpreted, as it is with script languages. But the key thing to understand is that once that page has been "served", the server-side code is gone and the server has NO WAY to know anything about what may or may not be happening at the client browser until a new request comes in. If you are a n00b, try to get this concept to stick to your mind, like concrete on the sides of the Grand Coulee Dam. It will help you later. The Web is STATELESS, without extra "stuff" in the equation.
So, what's the "extra stuff" we need?
Traditionally, state storage is performed in several ways - client side and server side.
Client side state storage mechanisms includes Cookies, Querystring items, and hidden form fields (these only work in an HTTP POST scenario).
Server side state storage include Application, Session, and Cache, along with other mechanisms such as static fields in the Global class, A State Service, or a database.
There are also hybrid mechanisms such as having a hidden IFRAME in a page whose src attribute is dynamically set (via client - side script) to a page on the server, with specified Querystring items, and after the IFRAME has loaded the processed document, client script can use the information in it to update the HTML DOM of the page without the main page having to make a separate request to the server. In point of fact, this was the beginning of "AJAX", and people have been doing it since about 1996 in various forms.
Later on, about 1998, Microsoft came out with Remote Scripting, which uses a combination of javascript, the XMLHTTP object and / or a small JAVA applet to handle getting information from the server and updating the page in the browser without requiring a "reload" (a re-request to the server).
Later came JSRS (Javascript Remote Scripting), made popular by Brent Ashley (circa 2000), where javascript is used to do pretty much the same thing as with the hidden IFRAME.
The XMLHTTP object is simply a part of the MSXML ActiveX component that allows for making HTTP requests external to the browser, and it can be handled with both server-side and client - side script. Actually, there is very little XML involved with this in most cases, so it's poorly named. From a Microsoft perspective, however, that name is what got it into the product and so it "stuck". The rest is, well, history.
The first big implementation of Remote Scripting was for Outlook Web Access which came with Exchange Server, and although by current standards it could be considered clunky, it was pretty amazing at the time.
Later, Google started implementing advanced Javascript with arrays to do very cool things like Google Suggest. About this time the "other" browsers got religion and decided to follow Microsoft's lead and include their own "XMLHTTP" object built into the browser. When that happened, interest in the whole concept soared and people like Jesse Garrett came along and decided it was something they could make money promoting to the hordes of knowledge-hungry web developers. So "AJAX" was born. Essentially, just a catchy new name for Remote Scripting. I've commented on this mishap to death so I won't beat a dead horse. Suffice to say that even Microsoft got snookered into the buzzword hype and now calls their more sophisticated ATLAS Remote Scripting framework "Microsoft AJAX".
Finally, developers should be aware that IFRAME techniques require that the resource requested come from the SAME DOMAIN that the main page came from, due to security policies all browser makers have adopted.
Strangely, this "same domain" policy does not apply to the src of the SCRIPT tag, and so enterprising developers have engineered ways to dynamically inject a script tag into the HTML Document, and when it's src property is set via client script, the tag makes the browser dutifully request the resource EVEN IF IT IS FROM A DIFFERENT DOMAIN.
Developers have started using JSON as the return vehicle with this arrangement. JSON is simply annotated text that is legal javascript, and when it is passed into a callback javascript method in the page, or the "eval" method is applied to it, you get Javascript objects - which can be representations of virtually anything including handy things like DataSets. This "cool stuff" is then used to update the DOM of the page without a reload.
In JSON, objects take on these forms:
An object is an unordered set of name/value pairs. An object begins with { (left brace) and ends with } (right brace). Each name is followed by : (colon) and the name/value pairs are separated by , (comma).
An array is an ordered collection of values. An array begins with [ (left bracket) and ends with ] (right bracket). Values are separated by , (comma).
A value can be a string in double quotes, or a number, or true or false or null, or an object or an array. These structures can be nested.
A string is a collection of zero or more Unicode characters, wrapped in double quotes, using backslash escapes.
A character is represented as a single character string.
So there you have it. Some history, a little clarity (if that's actually possible with all these buzzwords and acronyms) and a bit of State, and JSON came along for the ride. If you want to find some good custom resources on JSON, put it in the custom search widget just below and take a look at the results.
I say this because we at eggheadcafe.com get lots of forum posts that revolve around this subject. Sometimes they center around attempts to write to the filesystem at the browser from server-side code (which is long gone), other times they question how to tell if somebody has closed their browser, and many other variations in between.
But the common theme is a misunderstanding of just how disconnected the server and the browser really are in a web application. This disconnectedness and State are the two central issues that web developers face, and are the basis of the evolution of web applications to include IFRAMES, javascript callbacks, the XMLHTTP object, and finally, Remote Scripting ("AJAX") and JSON (Javascript Object Notation).
THE BASICS
Let's go over some basics: When you put a Uri in the browser's address bar, or click on a link in a web page, the browser makes an HTTP Request for that resource. The two most common types of request are GET and POST. GET transmits any additional information as querystring items, e.g. http://www.yoursite.com/pagename.aspx?username=Howard .
POST only occurs when a FORM element's submit method is called. This packages up field names and values into the BODY of the HTTP Request, not on the querystring.
The server receives this request and routes it to the appropriate place (a web page, an image, a piece of javascript, etc.) and the resource is "served" back to the client (browser). In ASP.NET, an ASPX web page is processed via an instance of the Page class. Page builds the Control Tree, parses the tags, does all the logic, and all this is assembled into POHTML (Plain Old HTML) and sent back to the browser. At this point, the Page class instance at the server is GONE. Zippo, nada, efes, nuttin! It's GONE. If you needed to "Save" something, some "state" of this transaction, you have to have a separate way of storing it. The ASP.NET Page class is compiled - not interpreted, as it is with script languages. But the key thing to understand is that once that page has been "served", the server-side code is gone and the server has NO WAY to know anything about what may or may not be happening at the client browser until a new request comes in. If you are a n00b, try to get this concept to stick to your mind, like concrete on the sides of the Grand Coulee Dam. It will help you later. The Web is STATELESS, without extra "stuff" in the equation.
STATE STORAGE
So, what's the "extra stuff" we need?
Traditionally, state storage is performed in several ways - client side and server side.
Client side state storage mechanisms includes Cookies, Querystring items, and hidden form fields (these only work in an HTTP POST scenario).
Server side state storage include Application, Session, and Cache, along with other mechanisms such as static fields in the Global class, A State Service, or a database.
BIRTH OF AJAX
There are also hybrid mechanisms such as having a hidden IFRAME in a page whose src attribute is dynamically set (via client - side script) to a page on the server, with specified Querystring items, and after the IFRAME has loaded the processed document, client script can use the information in it to update the HTML DOM of the page without the main page having to make a separate request to the server. In point of fact, this was the beginning of "AJAX", and people have been doing it since about 1996 in various forms.
Later on, about 1998, Microsoft came out with Remote Scripting, which uses a combination of javascript, the XMLHTTP object and / or a small JAVA applet to handle getting information from the server and updating the page in the browser without requiring a "reload" (a re-request to the server).
Later came JSRS (Javascript Remote Scripting), made popular by Brent Ashley (circa 2000), where javascript is used to do pretty much the same thing as with the hidden IFRAME.
The XMLHTTP object is simply a part of the MSXML ActiveX component that allows for making HTTP requests external to the browser, and it can be handled with both server-side and client - side script. Actually, there is very little XML involved with this in most cases, so it's poorly named. From a Microsoft perspective, however, that name is what got it into the product and so it "stuck". The rest is, well, history.
The first big implementation of Remote Scripting was for Outlook Web Access which came with Exchange Server, and although by current standards it could be considered clunky, it was pretty amazing at the time.
Later, Google started implementing advanced Javascript with arrays to do very cool things like Google Suggest. About this time the "other" browsers got religion and decided to follow Microsoft's lead and include their own "XMLHTTP" object built into the browser. When that happened, interest in the whole concept soared and people like Jesse Garrett came along and decided it was something they could make money promoting to the hordes of knowledge-hungry web developers. So "AJAX" was born. Essentially, just a catchy new name for Remote Scripting. I've commented on this mishap to death so I won't beat a dead horse. Suffice to say that even Microsoft got snookered into the buzzword hype and now calls their more sophisticated ATLAS Remote Scripting framework "Microsoft AJAX".
Finally, developers should be aware that IFRAME techniques require that the resource requested come from the SAME DOMAIN that the main page came from, due to security policies all browser makers have adopted.
Strangely, this "same domain" policy does not apply to the src of the SCRIPT tag, and so enterprising developers have engineered ways to dynamically inject a script tag into the HTML Document, and when it's src property is set via client script, the tag makes the browser dutifully request the resource EVEN IF IT IS FROM A DIFFERENT DOMAIN.
Developers have started using JSON as the return vehicle with this arrangement. JSON is simply annotated text that is legal javascript, and when it is passed into a callback javascript method in the page, or the "eval" method is applied to it, you get Javascript objects - which can be representations of virtually anything including handy things like DataSets. This "cool stuff" is then used to update the DOM of the page without a reload.
In JSON, objects take on these forms:
An object is an unordered set of name/value pairs. An object begins with { (left brace) and ends with } (right brace). Each name is followed by : (colon) and the name/value pairs are separated by , (comma).
An array is an ordered collection of values. An array begins with [ (left bracket) and ends with ] (right bracket). Values are separated by , (comma).
A value can be a string in double quotes, or a number, or true or false or null, or an object or an array. These structures can be nested.
A string is a collection of zero or more Unicode characters, wrapped in double quotes, using backslash escapes.
A character is represented as a single character string.
So there you have it. Some history, a little clarity (if that's actually possible with all these buzzwords and acronyms) and a bit of State, and JSON came along for the ride. If you want to find some good custom resources on JSON, put it in the custom search widget just below and take a look at the results.
Comments
Post a Comment