• Choose a category
• All
• Classic-Fiction

We define a ContentPopup object that composes one of the generic Window objects, creates an IFrame to use as the main content in the window body, and loads the given URL into it. In this case, we have simply constructed the name of a static HTML file as the URL. In a more sophisticated system with dynamically generated data, we would probably add querystring parameters to the URL

instead. The simple file that we load into the IFrame in this example, shown in listing 5.3, is generated by the server.

Listing 5.3 info_earth.html

Nothing remarkable there—we can just use plain HTML markup as we would for a classic web application.

In a content-centric pattern, the client-tier code needs only a limited understanding of the business logic of the application, being responsible for placing the IFrame and constructing the URL needed to invoke the content. Coupling between the client and presentation tiers is quite loose, with most responsibility still loaded onto the server. The benefit of this style of interaction is that there is plenty of HTML floating around on the Web, ready to use. Two scenarios in which it could be useful are incorporating content from external sites—possibly business partners or public services—and displaying legacy content from an application. HTML markup can be very effective, and there is little point in converting some types of content into application-style content. Help pages are a prime example. In many cases where a classic web application would use a pop-up window, an Ajax Licensed to jonathan zheng

The details: exchanging data

181

application might prefer a content-centric piece of code, particularly in light of the pop-up blocker features in many recent browsers.

This pattern is useful in a limited set of situations, then. Let’s briefly review its limitations before moving on.

Problems and limitations

Because they resemble conventional web pages so much, content-centric interactions have many of the limitations of the old way of doing things. The content document is isolated within the IFrame from the page in which it is embedded. This partitions the screen real estate to some extent. In terms of layout, the IFrame imposes a single rectangular window for the child document, although it may be assigned a transparent background to help blend it into the parent document.

It may be tempting to use this mechanism to deliver highly dynamic subpages within the highly dynamic application, but the introduction of IFrames in this way can be problematic. Each IFrame maintains its own scripting context, and the amount of “plumbing” code required for scripts in the IFrame and parent to talk to one another can be considerable. For communication with scripts in other frames, the problem worsens. We’ll return to this issue shortly when we look at script-centric patterns.

We also suffer many of the usability problems of traditional web applications. First, if the layout of the IFrame involves nontrivial boilerplate markup, we are still resending static content with each request for content. Second, although the main document won’t suffer from “blinking” when data is refreshed, the IFrame might, if the same frame is reused for multiple fetches of content. This latter issue could be avoided with a bit of extra coding to present a loading message over the top of the frame, for example.

So, “content-centric” is the first new term for our vocabulary of Ajax server request techniques. Content-centric approaches are limited in usefulness, but it’s good to have a name for them. There are many scenarios that can’t be easily addressed by a content-centric