In the first part of this tutorial, we explored the basics gadgets, URL and HTML content types, pulling information from the Web and displaying it. In this section, let's investigate how to process content fetched and present it in a more appealing format.
The first step in processing received data is to understand what is in the response and the formation. If you visit the following MarkMail URL: http://markmail.org/browse/org.wso2.carbon-commits and view the source of that page, you will notice that there is a div with the ID browse and this div has the main content of the page.
Inside this <div> you will find a table with the monthly svn activity data. So from our gadget, we like to pick this <div> and the table with the data, and use that as the main content as opposed to the whole page.
This gadget extends the previous sample gadget we discussed in the dynamic height section in part 1 of this tutorial. The key difference here is that, instead of using the response text as it is, we use some logic to pick the table with the content.
Since we get the response as text, in order to use some DOM logic to pick the table, we need to attach the text response data into an element on the current HTML document that the Web browser is aware of. For this, we use the hidden <span> element declared on line 10. Note 'style="display:none;"'. This is why the span is not visible on the gadget.
In line 23, we locate the <div> with ID browse and pick the table element as follows:
We also wrap this content with a tag as the above logic will strip tag:
"<table>" + document.getElementById('browse').getElementsByTagName('table').innerHTML +"</table>"
This processed content is assigned to be the inner HTML of contentDiv. To make sure we give due credit to MarkMail for the content, in line xx we provide the logo and link to the MarkMail gadget. The rest of the logic of this gadget is the same as the previous gadget sample.
Here is the output of the new gadget:
Using TEXT vs DOM Content Type when Working with HTML
In the gadget that we discussed, we used the content type request parameter set to TEXT as follows:
parameters[gadgets.io.RequestParameters.CONTENT_TYPE] = gadgets.io.ContentType.TEXT;
There are four content types: TEXT, DOM, FEED and JASON, defined in the Google Gadget API (http://code.google.com/apis/gadgets/docs/remote-content.html#Content_Types). Using the TEXT content type and setting the text content to inner HTML of a hidden element and them processing it as a part of HTML DOM document seems incorrect, when we have the opportunity to use content type DOM.
parameters[gadgets.io.RequestParameters.CONTENT_TYPE] = gadgets.io.ContentType.DOM;
This is not entirely correct, given that our use case is to fetch HTML from a URL, process that and build the gadget content. DOM content type is more appropriate when we want to deal with XML data fetched from SOAP or REST service endpoints. An example on the use of DOM can be found in Google gadget documentation (http://code.google.com/apis/gadgets/docs/remote-content.html#Fetch_XML). The pitfalls of working with HTML using DOM content type is also discussed on iGoogle developer forum (http://markmail.org/message/fophexdfdakwnitr#query:+page:1+mid:d77dptoyzqenxdtu+state:results).
The main point here is that the DOM returned by makeRequest is not part of the HTML document DOM. It is rather a separate DOM representation of the feted content. Since the fetched content’s DOM is not part of the HTML document's DOM tree, even though the fetched content is HTML, it cannot be easily attached to the gadget’s HTML document.
So when working with HTML, we are better off using TEXT content type and adopt the strategy of processing the response as text and attaching to the HTML document as inner HTML.
Following is the source code for the complete gadget. On the left hand side is the gadget source and on your right, the description.
It is advisable not to incorporate code comments to the code itself. In case of gadgets, even the comments get downloaded to the browser as content, increasing the download size. It is best to keep comments to a minimum.
Here is the output of this gadget, with the graph in place:
Also take a look at how to set preferences and make use of the same gadget to present different data in different formats in tutorial Setting User Preferences.