Thursday, July 2, 2009

Google Gadgets (Day 9)

For those unfamiliar with the concept of a Google Gadget, they are generally small "widgets" which can be added to any web page (although they are rarely used outside of iGoogle homepages). Two sample gadgets are shown below, one very simple one and one less simple one.

Counter gadget:



Date/time gadget:




The gadget its self consists of a publicly accessible XML file, for example: Counter gadget or Date/time gadget. These XML files can contain a range of preference values including gadget title and author, but most importantly they contain a "CDATA" section. Within this section the data is read as HTML text instead of XML, this is where the main content of the gadget resided. The HTML in this section is very similar to the HTML found in any standard web page, with a few key differences.

Probably the biggest of these of differences is that the HTML no longer contains <head> or <body> tags, only the content of the "body" tag (as shown below). However this does not prevent the inclusion of CSS or JavaScript which can still be included with the <script> or <style> tags in the "body" of the gadget.
<?xml version="1.0" encoding="UTF-8" ?>
<Module>
<ModulePrefs title="hello world example" />
<Content type="html">
<![CDATA[
<!-- START OF HTML -->
Hello, World
<!-- END OF HTML -->
]]>
</Content>
</Module>

For anyone considering developing Google Gadgets it is definitely worth noting that Google implement heavy caching of Gadgets, as such even if you update the publicly accessible XML file for a Gadget you may not immediately see any change in the browser rendered Gadget. One easy way around this is to test your Gadget on an iGoogle homepage and adding the developer gadgets, which allows you to disable the caching of certain Gadgets. However this will not prevent the caching of any external JavaScript or CSS files linked to by your Gadget.

A further complication caused by the caching of gadgets is that this means they must be static, not dynamically generated. In the context of this project that means that the gadget file itself can not contain any of the ever-changing Grid data. As such any data required by the Gadget must be loaded with an AJAX type call (in the project I will be using JSON responses instead of XML), the simplest way to prevent the requested page from being cached is to add a randomly generated number on to the end of the GET request url each time the page is called e.g. "'http://www.url.com/file.php?rand=' + randomNumber()". The more experienced web developer may at this point be asking, "aren't JavaScript GET requests locked to the current domain? How are you going to acess data outside of google.com", well the answer is yes it is domain locked, however Google provide a range of alternatives to the standard JavaScript "XmlHttpRequest()" function, each of which triggers google to act as an "AJAX proxy" such that the browser accesses the data from within the Google domain. This is shown schematically in the picture below, where steps 4-8 would be skiped if the Gadget file was already cached and 9-13 would be skipped if the requested page was already cached:

No comments:

Post a Comment