Welcome!

Kurt Cagle

Subscribe to Kurt Cagle: eMailAlertsEmail Alerts
Get Kurt Cagle via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: RIA Developer's Journal, AJAX World RIA Conference

RIA & Ajax: Article

Real-World AJAX Book Preview: The Drawbacks to Inline AJAX

Real-World AJAX Book Preview: The Drawbacks to Inline AJAX

This content is reprinted from Real-World AJAX: Secrets of the Masters published by SYS-CON Books. To order the entire book now along with companion DVDs for the special pre-order price, click here for more information. Aimed at everyone from enterprise developers to self-taught scripters, Real-World AJAX: Secrets of the Masters is the perfect book for anyone who wants to start developing AJAX applications.

The Drawbacks to Inline AJAX
The use of JavaScript as a scripting language has emerged primarily in response to this largely monolithic approach to extensions and components. Similarly, the use of the HTML (and later, XML) DOM provided the hooks by which each particular tag could be treated as its own internal component. This approach, the finite set approach, has meant that so long as the underlying browser implementation has support for a given feature, one can create more elaborate structures that essentially built upon this fixed set. Much of the existing AJAX methodology is ultimately built around this particular view of Web programming.

Put in basic terms, this approach works reasonably well for comparatively simple Web pages - perhaps the majority of such pages currently out there. In those cases, even if there's a comparatively large amount of code in play, that code can be stored in libraries, with functional components then added once the page instantiates itself. Many AJAX applications are built in this manner, combining incoming HTML with scripting, and to a certain extent even downloading specific functional libraries depending upon the capabilities of the Web browser.

However, there is an upper limit to this approach, driven largely by the fact that you are mixing markup code - the HTML (or preferably XHTML) that defines the substrate of the Web pages, and the scripting languages that define the user interaction on those Web pages outside of the innate capabilities of the objects defined within the XHTML DOM.

An assumption needs to be made, then, when looking beyond simple scripts to more complete "component" frameworks that ultimately the best design principles for building components should work on the idea of using XML (or in the case of Internet Explorer, the somewhat modified quasi-XML HTML that the application supports) as the declarative blocks that define the starting functionality of the page, and using JavaScript (and other AJAX tools) primarily as the means to define the behavior of these XML building blocks.

Mozilla defines the concept of an XML Binding Language, while Internet Explorer has long supported the notion of behaviors. In both cases, what you are doing is associating with an XML tag (or an XHTML tag) a specific set of behaviors that are either completely new or that extend the existing implementation. By doing this, you are in essence extending the set of functional tags that you can work with.

Using AJAX for Binding
Unfortunately, an XML-based binding language (XBL) is only used by Mozilla (the behaviors of IE are HTML based). As it turns out, however, you can use AJAX and JSON to create a fairly sophisticated binding layer surprisingly easy, one that will work across multiple browser environments. Such a binding system can hide much (if not most) of the scripting on a Web page and keep the environment consequently largely declarative, making Web pages and Web applications considerably simpler to write, maintain, and modify.

For instance, one of the more interesting problems that I've had to deal with as an author has been how to break up a large article into smaller, digestible chunks. There are usually very clear breakpoints within an article, but turning a single document into a number of separate subdocuments makes it difficult to edit it. Moreover, when such a document is broken up on the server, a link back to it will usually link only to a point in the middle of the article, not at the logical start of the article.

Thus, I chose to create a particular "tag" called <xinclude> that will automatically load into the Web page the contents given by the URL given in the tag's src attribute. If this URL contains multiple elements with ID tags, you can also specify that only a subsection with a given ID be loaded by including the ID after a hash mark, myFile.xhtml#intro for instance.

Finally, if the buttons attribute is included, the behavior changes a little bit. If there are multiple ID elements, then a buttonbar will be filled with one button for each section and the src should then point to the section that represents the initial block that the user will see, usually the first ID'd element in the document.

The initial XHTML file (binding.xhtml) is viewable using both Opera and Mozilla browsers (and a version including support for IE6 and IE7 will be included on the Website):

This content is reprinted from Real-World AJAX: Secrets of the Masters published by SYS-CON Books. To order the entire book now along with companion DVDs, click here to order.

More Stories By Kurt Cagle

Kurt Cagle is a developer and author, with nearly 20 books to his name and several dozen articles. He writes about Web technologies, open source, Java, and .NET programming issues. He has also worked with Microsoft and others to develop white papers on these technologies. He is the owner of Cagle Communications and a co-author of Real-World AJAX: Secrets of the Masters (SYS-CON books, 2006).

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.