A Short History of the Web

In the late 1950s, the U.S. government formed the Advanced Research Projects Agency (ARPA). This was largely a response to the Russian success in launching the Sputnik satellite and employed some of the country's top scientific intellects in research work with U.S. military applications.

During the 1960s, the agency created a decentralized computer network known as ARPAnet. This embryonic network initially linked four computers located at the University of California at Los Angeles, Stanford Research Institute, the University of California at Santa Barbara, and the University of Utah, with more nodes added in the early 1970s.

The network had initially been designed using the then-new technology of packet switching and was intended as a communication system that would remain functional even if some nodes should be destroyed by a nuclear attack.

Email was implemented in 1972, closely followed by the telnet protocol for logging on to remote computers and the File Transfer Protocol (FTP), enabling file transfer between computers.

This developing network was enhanced further in subsequent years with improvements to many facets of its protocols and tools. However, it was not until 1989 when Tim Berners-Lee and his colleagues at the European particle physics laboratory CERN (Conseil Européen pour le Recherche Nucléaire) proposed the concept of linking documents with hypertext that the now familiar World Wide Web began to take shape. The year 1993 saw the introduction of Mosaic, the first graphical web browser and forerunner of the famous Netscape Navigator.

The use of hypertext pages and hyperlinks helped to define the page-based interface model that we still regard as the norm for web applications today.

The XML DOM

The XML Document Object Model defines a standard way for accessing and manipulating XML documents. The DOM enables JavaScript to completely access XML or XHTML documents by providing access to the elements which define the structure. The accessibility is possible through a set of intrinsic JavaScript objects that focus on DOM manipulation. This model is something that we will be using throughout the rest of this book because it is required to parse the responses that we receive from the server side when we create an XMLHTTPRequest (XHR). As mentioned earlier, the XHR is the core of the Ajax model and without it the model would not exist. This is the piece of the Ajax puzzle that has created the recent buzz because it allows HTTP requests to be made to the server without refreshing the browser.

Though there has been a lot of recent hype surrounding Ajax, it has existed for quite some time. Microsoft originally released the XHR object in 1999 with Windows IE 5 as an ActiveX object available through the use of JavaScript and VBScript. It is now supported by Mozilla, Firefox, Safari, Opera, and Netscape by using a native JavaScript object. This native JavaScript object will also be supported with the release of Windows Internet Explorer (IE) 7. Although the technologies have been in existence and used by some developers in the past, it has only recently gained large popularity. The cause of its recent popularity is largely based on the support that is offered by browsers because not many browsers had the support necessary for powerful DHTML, XHTML, CSS, and XMLHTTPRequests until more recent versions. Now it is possible to create such interactions with successful cross-browser and cross-platform results. The adoption of better support for these technologies has brought Ajax to the forefront and it is once again an exciting time to be a web developer. Small, independent operations are regularly emerging with applications that rival the desktop by providing powerful functionality while immensely improving the user experience.

Measuring the Benefits

Ajax is a powerful collection of languages that, when brought together, create extremely intuitive user interfaces and client-side interactions. Although this is true, there are many developers who get so excited by the hype surrounding it that they simply throw the code into their applications without measuring the benefits of using it beforehand. Not every web application has a need for Ajax, but there are many parts of an application that can be enhanced by utilizing its benefits. In this book, we will cover usability patterns that will handle feedback, server-side form validation before we even submit the form, and Ajax-enabled components that can enhance sections of our web applications without overdoing it. Ajax is also great to use if you would like to make a server-side connection and possibly a database interaction without refreshing the browser. This is what makes Ajax so powerful because it allows us to interact with the server, receive HTTP status codes, save data to a database, and determine what to present to the user without ever refreshing the page. This request/response pattern can continually persist as a desktop application does, but Ajax-enabled web applications are, well, on the Webaccessible by anyone with a connection, without any downloads or shipping costs for delivering large fancy boxes. The Web is the new desktop, and we are on the verge of a major software shift that we can actively participate in as the pioneers of on-demand information.

Ajax can be a valuable connection between the interface and back-end logic, allowing the back end to be robust and powerful with a simple yet intuitive interface that provides on-demand feedback to users. It also provides ways to exchange data with server-side languages and store it in databases without disconnecting the user from the application like standard applications do when refreshing the browser window. After reading this book, you will have the information needed to create fully functional Ajax applications.

The Response

Each format can be useful depending on the results you are trying to achieve. However, deciding on a single format for your application can be useful as a convention for future management, especially if you are building a large-scale application. For example, if you decide to use XML as the response in one situation, it would be much easier to continue to count on that format as the response when making all other requests. This might differ from one application to the next but, if possible, it is an important theory to keep in mind. It is also good to keep in mind the scalability of the technology that you choose, especially if you are planning on creating a scalable application in which you expect exponential growth. Let's get started by taking an in-depth look at XML, the syntax, how to parse it, and how to use it in your next application.

XML

XML (Extensible Markup Language) is a popular choice for XHRs, simply because it is the standard intermediate language that all programming languages are able to share. It is also supported both on the server side and client side, which makes it the most flexible solution. XML is essentially a custom tag-based structure that you, the developer, define. XML's tag-based structure is similar to that of HTML, except that HTML has predefined tags that represent its structure, such as the head, the body, tables, and so on. The following is an extremely simple example of an HTML table, which could easily be translated or used as XHTML:




XML can be passed between the front end and the back end for easy communication of multiple languages. Having this common language between the front end and the back end is extremely powerful. It enables us to create direct connections from the GUI to a server-side language and, ultimately, if desired, a database. Communicating with XML between the GUI and the front end allows for complete separation of the two application layers. Separation of the GUI and the back-end logic is extremely important because it enables us to have a completely decoupled application in which GUI developers can work on the front end, while the back-end developers work on the back end. This might seem like common sense, but it is an approach lacking approach in many companies. It keeps specific parts of the application separated for easier management, and allows teams or individual developers to focus on the layer that is in need of growth. Not only is this approach ideal for teams of developers, it is also important for any individual developer who might be working on every part of the application. With this structure, an individual developer can focus on specific layers of the application without interfering or having to make changes to the adjacent layers.

XML formatting is trivial, but there are important principles to consider when planning a solution. Imagine having to format email data into a structure that could be requested through an Ajax engine and displayed with client-side JavaScript objects. This is a structure that we will be creating for the sample in this book. When architecting this structure, we want to keep in mind that we may use it in multiple objects or locations of the application and should therefore keep it as abstract as possible. We will start by defining the main elements that will create this structure.