Ajax Patterns And Best Practices (2006)

C H A P T E R 2 ■ T H E N U T S A N D B O L T S O F A J A X

49

4.In the text box, add the website http://192.168.1.101 and click the Add button. Remember to deselect the check box labeled Require Server Verification. The added site will include all ports and is not necessary to specify.

After adding the trusted site, you can perform a cross-domain call, as illustrated in Figure 2-16.

Figure 2-16. Cross-domain HTTP request that retrieves http://www.cnn.com

Mozilla Firefox

Mozilla Firefox does not have any dialog boxes for defining a site as trusted. There are two solutions to enable cross-domain HTTP requests. The first is to use signed HTML pages,5 which is beyond the scope of this book. The second solution is a programmatic solution that will be illustrated.

Documented at many locations is use of the security manager, as illustrated by the following source code:

netscape.security.PrivilegeManager.enablePrivilege('UniversalBrowserRead');

5. http://www.mozilla.org/projects/security/components/jssec.html

50	C H A P T E R 2 ■ T H E N U T S A N D B O L T S O F A J A X

Using this line enables cross-domain calls. Yet if you were to run this JavaScript code, you would get a security failure because an additional security item has to be enabled. The security item could be added to the file [Mozilla or Firefox installation]\defaults\pref\ browser-pref.js, or the user’s prefs.js file. The security item is defined as follows:

pref("signed.applets.codebase_principal_support", true);

The security item enables a set of security descriptors, where one item includes the same origin policy descriptors.

Then, calling the netscape.se... method from a JavaScript file results in a security warning as illustrated in Figure 2-17.

Figure 2-17. Security descriptor dialog box to enable cross-domain calls

The user can click the Allow button of the dialog box for each time the method netscape.se... is called on the HTML page. Or the user can select the Remember This Decision check box to enable an automatic acceptance of the security policy. After the policy has been

C H A P T E R 2 ■ T H E N U T S A N D B O L T S O F A J A X

51

accepted, calling the XMLHttpRequest.open method with a cross-domain URL will download the contents. There is a catch in that the security descriptors are enabled only in the function where the security call is made. This means you cannot define a function to call the security descriptors, and another function to make the cross-domain call. Both calls need to be in the same function.

Having fulfilled all requirements, the content can be downloaded as in Internet Explorer and is illustrated in Figure 2-18.

Figure 2-18. Cross-domain request that downloads http://www.cnn.com

Some Final Thoughts

The mechanics of the XMLHttpRequest type are simple, but the ramifications are not. When using XMLHttpRequest, you should keep three points in mind: use a Factory pattern to enable cross-browser support, use asynchronous requests to avoid browser lockup, and enable security to allow cross-domain calls.

Using a Factory pattern is obvious and necessary, but some may balk at using asynchronous requests because it means reacting to events. Asynchronous programming when done improperly can result in an erratically behaving Ajax application. However, I tend to think that

52	C H A P T E R 2 ■ T H E N U T S A N D B O L T S O F A J A X

because we are already used to writing event-driven GUI code, most people will not have any problems.

The security issue is a bigger concern. When learning about how to circumvent a security measure, administrators may become nervous. This is not because they are worried about the security, but worried that many problems relating to security are often related to the Internet. Hence, getting an administrator to play along might become difficult. A solution is using the REST-Based Model View Controller pattern, described in Chapter 11.

Overall the purpose of this chapter was to introduce the nuts and bolts of an Ajax application and the XMLHttpRequest type. You can build on this basic knowledge to create more-complicated applications.

C H A P T E R 3

■ ■ ■

Content Chunking Pattern

Intent

The Content Chunking pattern makes it possible to incrementally build an HTML page, thereby allowing the logic of an individual HTML page to be distributed and the user to decide the time and logic of the content that is loaded.

Motivation

Originally, when the Web was in its infancy, HTML content designers created documents that were incomplete. The incomplete pages were made complete by using document links. The completeness of a document was the sum of the pages in the document tree.

Think of it as follows: instead of creating a book in which you follow through the content in a sequential manner, for the Web you would paste materials together like a bunch of magazine articles. But unlike a magazine that required you to go through one page after another, the Web allowed you to click a link and jump to different content. As time passed, websites moved away from this distributed web structure to a strictly hierarchical self-contained structure.

An example of a strictly hierarchical self-contained website is illustrated in Figure 3-1. In Figure 3-1, the website is split into two areas: blue-background navigation and brown-

background content. When a user clicks on a navigational link, the content is changed. But the problem is that the entire page is reloaded even though the user is only interested in the brown-background content. One way to get around this problem is to use HTML frames so that the navigational area is one frame, and the content area is another frame. When a link in the navigational area is clicked, only the frame containing the content is altered. However, as time has shown, although frames solve the problem of loading content individually, they are problematic from a navigational and user interface perspective. Thus websites have used fewer and fewer frames.

Ideally, what a website developer wants is the ability to alter the content that needs to be altered and to leave the rest of the content as is. After all, untouched content is content that stays the same and works.

53

54	C H A P T E R 3 ■ C O N T E N T C H U N K I N G P A T T E R N

Figure 3-1. Strict hierarchical structure of a website

Applicability

Use the Content Chunking pattern in the following contexts:

•When it is not known what the HTML page should look like because of the nature of the website. In Figure 3-1, there is a blue-background navigational area and a brown-back- ground content area. The content of each area is unknown, but what is known is the area where the content is destined.

•When the content to be downloaded is too large and would cause an excessive wait for the user. For example, doing a search and waiting for all found elements to be collected as a result set is not an option because the user would have to wait too long. A better approach would be to keep a search executing while displaying whatever is found.

C H A P T E R 3 ■ C O N T E N T C H U N K I N G P A T T E R N

55

•When the displayed content is not related. Yahoo!, MSN, and Excite are portal applications displaying content side-by-side with other content that has no relation to it. If the content is generated from a single HTML page, the server-side logic would have to contain a huge decision block to know which content is loaded and not loaded. A better approach would be to consider each block of content as a separate piece that is then loaded separately.

Associated Patterns

The Content Chunking pattern is a core pattern to any Ajax application. You could even make the assertion that the Content Chunking pattern is implicit to Ajax. Be that as it may, it is still necessary to identify and define the context of the Content Chunking pattern. What makes the Content Chunking pattern unique is that it always follows the same steps: generated event, request, response, and chunk injection. The other patterns covered in this book are similar, but do take deviations such as sending a request and not getting an immediate response (for example, the Persistent Communications pattern).

Architecture

The architecture of the Content Chunking pattern is relatively simple. A URL is called by the client. The server responds with some content that is received and processed by the client. An implementation of the Content Chunking pattern always follows these steps:

1.An event is generated that could be the result of a button being clicked or of an HTML page being loaded.

2.The event calls a function that is responsible for creating a URL used to send a request to the server.

3.The server receives the request and associates the request with some content. The content is sent to the client as a response.

4.The client receives the response and injects the response in an area of the HTML page.

Implementing Order in a Web Application

Looking back at Figure 3-1, the strict hierarchical nature of the website is not a bad thing. With respect to HTML, the result of the strictness is to generate the content in one step, and this all- in-one generation causes problems. Traditional applications do not function in such a manner, as illustrated in Figure 3-2.

56	C H A P T E R 3 ■ C O N T E N T C H U N K I N G P A T T E R N

Figure 3-2. Traditional client application

In Figure 3-2, the RealPlayer is an example of a traditional client application that mixes newer HTML-type technologies with traditional user interface elements. Clicking the Burn Your CD button causes RealPlayer to burn your CD but does not affect the advertisement that is running at the top half of the application. The logic associated with the advertisement and the logic associated with burning the CD are two separate, distinct pieces of logic that happen to be sharing the same window area.

Figure 3-3 dissects the web application of Figure 3-1 into distinct pieces of logic.

			C H A P T E R 3 ■ C O N T E N T C H U N K I N G P A T T E R N				57

Figure 3-3. Website architecture

In Figure 3-3, the original HTML page has links to two other pages that represent an example blog and article content. The example content has two execution blocks: Get Navigation and Get Content (1,2). The logic used to generate Get Content 1 is distinct from the logic used to generate Get Content 2. In the context of generating an HTML page, when either Get Content 1 or Get Content 2 is executed, the logic Get Navigation is executed. This means the logic Get Navigation is executed multiple times, generating the same data each time. Some readers might argue that different data is generated by Get Navigation (e.g., different folders are opened), but in fact it is the same data formatted a different way. In a nutshell, there is an inherent datageneration redundancy that should be avoided.

The solution is to distribute the logic so that an HTML page is generated, by using an architecture similar to Figure 3-4.

58	C H A P T E R 3 ■ C O N T E N T C H U N K I N G P A T T E R N

Figure 3-4. Improved website architecture

In Figure 3-4, the HTML page is the result of multiple pieces of server-side logic. When the main outline of the HTML page has been loaded, the XMLHttpRequest object retrieves the content blocks Get Navigation, Get Content 1, and Get Content 2. When and how the individual content blocks are retrieved depends on the events and links created by the content blocks. Each content block is a separate request that needs to be called by the XMLHttpRequest type.

The proposed architecture has the following advantages:

•The client downloads only what is necessary, when it is necessary. There is no need to re-retrieve a content block unless necessary.

•The architecture is separated into different code blocks that can be assembled dynamically in different contexts.

•The architecture resembles that of a traditional client in that only those elements that pertain to the event are manipulated.

•The overall look and feel is not affected because the generated code blocks delegate the look and feel to the parent HTML page retrieving the content blocks.

Figure 3-4 shows how the Content Chunking pattern got its name: a single HTML page is the sum of its chunks of content, which are referenced and loaded separately.