As you have seen, the Content section may contain either inline content—including HTML, CSS, and JavaScript—or you may use a proxy file to load the content. This proxy file, which is the URL value of the href attribute, needs to be a file of type HTML, XHTML, PHP, or any other server-side language. The proxy cannot be, for instance, a link to a .swf Flash file, an image, or a .mov QuickTime movie. To embed these items, you must wrap them in an HTML document and serve them via that file.

“Is it better to inline your content or have a proxy?” is usually one of the first questions that comes up when developers start building their applications. As far as the accessibility of container-specific features, there are really no differences between the two methods. When a gadget is rendered, all Content sections are concatenated together in a similar fashion. Choosing one method over another really comes down to maintainability, number of server requests, and load time.

Most containers internally cache the gadget XML files that are uploaded to their systems so they can serve up gadgets quickly. Once you make edits to a gadget XML file, these containers will require you to reupload or update their cache by syncing the XML file. This can be a tedious task depending on how the container handles caching, and if you inline your content inside the gadget XML file, you will have to do it each time you wish to view edits.

On the other hand, if you proxy your content using the href attribute, you will not need to update the gadget XML spec file when you update that Content section. This significantly improves the efficiency of your gadget-engineering practices and allows you to work independently of the gadget architecture.

Another issue emerges when we look at how data is obtained for a proxy Content section. Proxied content will mainly be fetched at the time of gadget rendering, when a user is using your application. This means that a request to your server has to be made each time the gadget loads if the container lacks a caching mechanism for proxied content. If there isn’t a caching mechanism in place for storing Content section data, this could result in a much higher server load. In this case, gadget implementers should integrate a data-caching layer on their servers to decrease processing load.

Finally, you need to consider the speed at which the gadget will load. If you are serving the gadget inline from a cached state, the gadget will render almost immediately. This is the ideal situation. Under normal circumstances, having to make a server request for data and wait for that response would make the proxied content method the clear loser. But while we can’t prevent the server request, we can certainly control when the content starts being fetched. If we specify the same proxy URL in a Preload element in the gadget XML file, the data fetch begins immediately. This means that when processing begins for the Content sections, the response should have already completed and the gadget will render as though it were cached.

Table 3-10 summarizes the features and benefits for each request type.

It appears that we have a tie, but if we look closely at what each option does not do, we can figure out which is the best approach for any gadget.

If you are developing a small-scale gadget that will have minimal server load, the best approach may be to choose engineering and editing efficiency rather than taking advantage of the container’s caching mechanisms. Let’s face it, though: in 99% of cases, we will be developing applications that we believe will succeed and obtain a large number of users, so we should plan for scale here. This means choosing inline content to reduce server load allows you to serve more users at any given time.

To take advantage of both categories, we should ideally have two gadgets: a development gadget and a production gadget. The development gadget should use proxied content to allow us to work independently of the production-level gadget without having to worry about it taking down the application. The production gadget should embed those proxied scripts directly in the gadget, so that it may be served up as efficiently as possible.