Showing posts with label google. Show all posts
Showing posts with label google. Show all posts

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:

Wednesday, July 1, 2009

The Journey Thus Far (Day 8)

As I mentioned in the previous post, the first part of this project involved finding a way to make the Grids "Logging and Bookkeeping" (L&B) data accessible to a Google Gadget. Initially it was suggested that I used a python CGI script to simply parse the tab delimited data files provided. This data could then be used to the build a JSON object, using the Google Visualization API, which could be returned in response to a GET request sent to the CGI. However, upon receiving a sample of the L&B data it immediately became clear that this would not be a sensible approach. This was because for just one weeks worth of data the uncompressed file size exceeded several hundred MB. As such using a single CGI script to parse, process and return the data would result in all 882MB (or more if additional weeks are to be considered) of data being read in response to each GET request. This would be very computationally inefficient and result in large delays for the end user (it is also likely that the GET request would timeout before any data was returned).

I therefore determined that the best approach would be to load the L&B data into a database, which could then be queried to in response to a GET request and the required JSON object built from the database's response. The architecture I had planned for the system looked something like this:

For the database RDBMS I am currently using a the excellent open-source mySQL, although the L&B data only forms a single table. I think, although I haven't quite reached the current state of the project, I'll end this post for now, as I feel an explanation of the basic structure/layout of Google Gadget is needed before going any further.