In a broader sense, Ajax represents a cluster of technologies that were so designed as to create a developer comprehensive and user-end facile language. At both ends, developer and remote user, Ajax creates and delivers rich web applications on a desktop application basis, providing lower bandwidth usage and speeding up loading page time by retrieving data from servers in the background of the page asynchronously.
The above definition was a simple yet debated fact at the time when Jesse James Garret first wrote about Ajax and its implications. In 2005, the programming techniques that Ajax implied were far from anything new or out of the ordinary. But put together, they envisioned a programming language that would reduce development time and efforts for building a web page to half and would extent user experience to richer web page imagery and faster viewing time. In simpler words, the Ajax technology would make possible the update of a web page or a section of a web application with input from the server, but without page refreshing. Server-side technologies are still needed but reduced in importance, because the web page data is still subject to some updating by accessing the server but at a different level.
- Standards-based presentation using XHTML and CSS
- Dynamic display and interaction using Document Object Model
- Data interchange and manipulation using XML and XSLT
- Asynchronous data retrieval using XMLHttpRequest
In the following sections of the article, we shall discuss the basic elements, requirements and possibilities of each technique component in Ajax. As a more personal guide, we have also created an exemplified article on how to choose the most suitable Web programming language for websites with specific purposes.
Standards-based presentation using XHTML and CSS
Let’s take a deeper approach to what both XHTML and CSS imply. Most persons from the IT world are familiar with the HyperText Markup Language, or HTML, which is basically the most common “spoken” language of the web. eXtensible HyperText Markup Language, XHTML, is the successor of plain HTML, and is in fact the HTML standard specified as an XML document and since 2000 is a World Wide Web Consortium recommendation. What differs is that where HMTL was somewhat facile and the browser made a reasonable attempt to display anything that was placed within tags, XHTML runs within an XML framework, meaning that if XML documents must be well formed so must the XHTML pages be. This is especially required in order to properly use the Document Object Model to gain access to different parts of the web page.
If HTML is an application of Standard Generalized Markup Language, or the SGML which is a very flexible markup language, XHTML is an application of XML, a more restrictive subset of SGML. Due to their need of well-formating, true XHTML documents permit automated processing to be executed using standard XML tools, unlike HTML which requires a more complex, lenient and overall custom parser.
The XHTML family was revised in August 2002, according to W3C, as being ” the next step in the evolution of the Internet. By migrating to XHTML today, content developers can enter the XML world with all of its attendant benefits, while still remaining confident in their content’s backward and future compatibility.”
Cascading Style Sheets, or the CSS, are the templates behind HTML pages that describe the presentation and layout of the text and data contained within the actual HTML page. The importance of the CSS comes from the developer who makes changes to the style sheet that are instantly depicted in the display of the page. CSS properties are also accessible via the Document Object Model which we will discuss further on in this article.
CSSs may be subject to local use by viewers of web pages in order to define colors, fonts, layout and other elements of a document presentation. Its primary purpose is to enable the separation of document content which is written in XHTML, from document presentation. By separating the two components, content accessibility is improved, more flexibility and control in the specification of presentation characteristics are provided, and complexity and repetition in the structural content are reduced. CSS also enables the same markup page to be presented in different styles for different rendering methods, such as on-screen, in print, by voice, on Braille-based or tactile devices. This is done by specifying a priority scheme to determine which style rules apply if more than one rule matches against a particular element. This is the so called cascade, where priorities or weights are calculated and assigned to rules, so that these rules would be predictable.
Although having a style sheet is not completely necessary, in order to maintain a proper organization style sheets are definitely an indispensable aid. Among other advantages of using style sheets is that by combining CSS with the functionality of a Content Management System, a considerable amount of flexibility can be programmed into content submission forms. This feature enables an editor or any person not familiar with CSS or HTML code editing to select the layout of a article or entire page in the same form. The information the editor inputs into the Content Management System is logically evaluated by the program and, based on a certain number of combinations, the program determines in which way to apply classes and Ids to the XHTML elements, styling them and positioning them as the pre-defined CSS dictated. This is really beneficial when working with large-scale, complex sites that have many contributors like news and informational sites, where this advantage influences to a great extent the feasibility and maintenance of the website.
Dynamic display and interaction using Document Object Model
DOM can be usually represented as a tree, the trunk being the document and the branches representing different elements on the web page. In this case, every part of the tree would be a node, which can also be tags , like HTML or XML, or attributes of tags. As for structure, a node can be a part of another larger node, which would be the “parent” of that node. Logically, a node can also be a parent to any number of image nodes, its “children”, and these in turn are parents to their attribute child nodes. The Document Object Model is then just like the tree which is parent to the branch which is parent for its leafs.
DOM scripting methods have several developing advantages such as the simple creation of elements, which does not require anymore document writing to insert HTML and CSS into the page, or object constructors. DOM simply allows the creation of entire elements with no prerequisites. The insertion of new text, the change and removal of text from any element are possible without resorting to inner HTML or document write. Also, with DOM techniques one can grab all the tags of the document, or grab the text, leaving the tags behind, or even move entire parts of the document, or just parts and fragments and work with just those.
One of the best advantages of DOM scripting techniques is that all of them are suitable for any DOM compliant browser, which means that there is no need for creating different web page versions for each browser, when DOM offers just one common set of scripting techniques. Provided now with full DOM support applications like Netscape 6 and Mozilla , almost every element or node is now accessible.
Data interchange and manipulation using XML and XSLT
Extensible Markup Language or XML is an extensible language because developers that use it can define their own elements through it. Its general purpose specification is to create custom markup languages and it facilitates the share of structured data through different information systems, like via Internet, being subject to use for both encoding of documents and serialization of data. Application languages can be implemented in XML, by adding semantic constraints, and such languages start at XHTML, RSS, MathML, Scalable Vector Graphics and continue to thousands more.
Along with XML comes an entire range of supporting technologies that have individual purposes. These technologies have emerged mostly because an XML document does not contain information on how it should be displayed or searched, so once the data is rendered as an XML document, developers usually need other supporting technologies to search and display information from it. Browsers like Internet Explorer and Firefox contain XML and XSLT engines, and can parse XML documents.
In 1998 XML was defined early as a markup language in order to represent structured content independent of its presentation, due to previous experiences with SGML in the print publishing environment. The tags used within XML are entirely user defined, being intended to relate to objects in specific domains of interests, like persons, places, prices or dates. If in HTML the elements are basically typographic, although just at an abstract level, XML aims at describing real-world object through elements.
As XML, XSLT is also a standard supported by the World Wide Web Consortium. As stated above, although IE and Firefox have XSLT processors, XSLT documents are not always subject to the same treatment. This is because XSLT uses another type of language, the Xpath, in order to query the XML document when applying it transformations. Xpath queries can be used to locate specific items or groups of items within an XML document, by using a syntax that appears similar to the way browsers locate web pages.
The advantage of these methods is that they can be used to retrieve sections of data for display on the web page, thus offering instant updates in the browser without the need to access the server. XSLT was designed to separate information content from presentation on the web and as the web filled with commercial content, publishers grasped for the same control over quality of output as in printed medium. The use of concrete presentation controls like explicit fonts and absolute positioning of material on the web page kept increasing, but directly proportional with this trend so has the difficulty of delivering the same content to alternative devices such as digital TV sets and WAP phones, which would otherwise would be called “repurposing” in the jargon of publishing trade.
The common known benefit stated for the above high-level languages is development productivity. In reality, the true value comes from their potential to adjustments. An XSLT application that transforms XML data structures can be designed to be much more resilient to changes in the details of the XML documents than a procedural application coded that uses the low-level DOM and SAX interfaces. In database jargon this capability is known as “data independence” , and it was this trait that acted as the golden fleece for development argonauts that successfully created declarative languages like SQL, putting aside older navigational data access languages.
It is also known that, as with all declarative languages, there is a slight performance penalty. But nevertheless, for the wider majority of applications, the performance of present days XSLT processors is already good enough to meet application requirements, and it’s getting better and better.
Asynchronous data retrieval using XMLHttpRequest
The XMLHttpRequest Object had a rather peculiar beginning. At first, Microsoft introduced an obscure little ActiveX control in Internet Explorer version 5 (IE 5) called the XMLHttp Object. Obvious, ActiveX controls are tied to IE, and shortly afterwards, Mozilla developers followed the act and came up with their own version for Mozilla 1 and Netscape 7, with the corresponding XMLHttpRequest Object. Versions of this object have been included in Safari 1.2 and Opera as well.
The traditional interface model for a web application consists of a few actions: the user requests a page from a server, which is build and delivered to the browser. The page includes a HTML form element for gathering data from the user that, once the user posts their input back to the server, enables the next page be build and served based on the input, and so on. The process revolves around the nature of the HTTP and differs from the former desktop application model of an interface which is inherently connected to the application layer. Lets look at an exemplified situation: entering a user name and a password for accessing a desktop application on a platform like Microsoft Windows. By convention, once typed in the boxes the correct user name and password, a green “tick” icon appears indicating that the user has introduced the correct user name and password. This takes place instantly as a result of the interface being developed within the application, right after the user types in the data, the application is able to check the validity and answer back. As opposed to this we have the standard behavior of the same task performed through a web interface. The user interface may look the same, with the same controllers and data forms, but on introducing data, the user needs to submit the page back to the server in order for the input to be validated. A new page would then be loaded with a message indicating whether the information was correct or not, and if not, then the user needs to go back to the previous page and re-input the information all over again.