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.