Using an HTML page as a data provider

Here’s a new example in the charting doc. It shows how someone might use some or all of an HTML page they load via an HTTPService tag as a data provider for their charting component. It includes logic to extract just the data from the target page.

The benefit to this is that if you have a wiki or blog that you can edit via a browser, you can build and update a data page without having to hit a database. The code extracts specially-tagged data from the HTML page, so even if it’s part of a larger block of HTML, you can still extract just the data.

One thing to note: The target domain in this example works because it has a crossdomain.xml file. If you want to load a page from your own target domain, you must be sure that your target domain has a crossdomain.xml file in place, and that that policy file lets the domain on which the Flex app is running request data from it.

Here’s the running example:

Here’s the data page that drives this chart:

You can download the source MXML file here: (1KB)

The exact location of the data page is passed into the application as a flashVars property. To change the data page, you only have to edit the HTML wrapper for the SWF file.

In the HTML wrapper, we pass the target HTML page as a param in the <object> tag:

<param name="flashVars" value="dataPage=" />

And again as an attribute of the <embed> tag:


Note that you can view the source of this blog entry page to see the complete object/embed tags.

In the Flex app, the data page is read from the Application’s application.parameters property:

dataPage = Application.application.parameters.dataPage;

To initially get the page’s contents into the Flex app, we use an HTTPService object:

<mx:HTTPService id="serviceInput"

To get the HTML in a single string we get the lastResult property of the HTTPService in the ResultEvent handler:

var htmlBlob:String = serviceInput.lastResult.toString();

And to extract just the portion of the data page that we need (the part between the “data starts here” and “data ends here” comments), we use the slice() method:

htmlBlob = htmlBlob.slice( htmlBlob.indexOf("&lt;!-- data starts here --&gt;", 0) + 25, htmlBlob.length );
htmlBlob = htmlBlob.slice( 0, htmlBlob.indexOf("&lt;!-- data ends here --&gt;", 0) );

We then do a couple more passes on the remaining HTML string to replace HTML entities with angle brackets, so that we will end up with well-formed XML:

var tagPattern:RegExp = /<[^]*>/g;
htmlBlob = htmlBlob.replace(tagPattern, "");

var ltPattern:RegExp = /&lt;/g;
htmlBlob = htmlBlob.replace(ltPattern, "<");

var gtPattern:RegExp = /&gt;/g;
htmlBlob = htmlBlob.replace(gtPattern, ">");

At this point, we just need to pass the XML to the XMLList constructor so that it can be used as a data provider in the chart:

chartData = new XMLList(htmlBlob);

That’s it. If you compile and deploy this app, you can use the provided data page, or create your own. If your data page is on the same domain as the application, then you do not need a crossdomain.xml file.

3 Responses to Using an HTML page as a data provider

  1. Terry says:

    I have recently worked on project where we used XHTML as a dataprovider for Flex. To my astonishment we have had good results using E4X to create models that consume XHTML.One thing I would like to mention here for people that find this article via a search is: be careful of namespaces, namespaces in XHTML can make valid markup appear as if it is not parsing. My fix was to remove the XHTML namespace from a template string before I passed it into an XML constuctor. If you want to keep the NS intact then just about everywhere you want to use e4x to find an element you will have to declare a default NS.

  2. Tathagat Banerjee says:

    I was looking at the code and it was really helpful, I’m trying to implement some of this in a wiki. Just one question: in line 26 why do you have a (+ 25) in your code. I did a and without the +25 it seems to work better, otherwise there is an extra –> at the start.

  3. Tathagat,The +25 refers to the number of characters to adjust the index from which to start extracting the XML from the string… Unfortunately, that value is based on using angle brackets (>)and not the HTML entities (&gt;), so it’s a few characters off. I had to adjust it a few times, based on how the blog output would render the characters and it looks like I did not do that properly. It should probably be something like 30 to avoid catching any of the characters in the initial comment tag.hth,matt