I guess that Cloud Computing stuff doesn’t only apply to data storage. There are also things like Google’s Visualization API for manipulating and presenting data. In this paradigm, the data is under my control but the code to manipulate it lives on Google’s servers.
Good or bad? That’s up for debate, but the table visualization definitely caught my eye. Look at the experimental results when I put FATE data into the table. Notice how easy it is to sort by columns (the default sort is such that the failed builds float to the top). I may be a little too close to the situation, but I think it’s a little better than my last attempt. Again, no more up-to-15-minute delay with this system; new build data is available for presentation as soon as it is submitted to the database.
Let me know what you think. Personally, I think we may have a winner here. Maybe Google’s other visualizations (assorted graphs and such) could be just the thing we have been searching for in order to plot trends like performance and code size.
I just wish I could understand the data source wire protocol. As it stands, the index-v3.php script generates JavaScript on the fly to populate the table. It would be a bit more elegant if the data were provided by a separate script. But, hey, this works.
Cool! (sorry, nothing more intelligent to add…)
Hm? The wire protocol is just a normal HTTP GET, you have to parse out the parameters, check if you support what was requested (I’m sure if the request tried using the SQL-like query language you’d just want to reply with error:not_supported), and then return the data, just like for a normal web site except that instead of a HTML page you (e.g.) return a JSON object that contains the table.
I do think that implementing it properly would be a bit of a pain though…
@Reimar: That’s what I thought. So far, I have tried to send the table very basic CSV data, which it is supposed to accept. But it doesn’t take. I have watched the data on the wire and an HTTP request/response is occurring, and the correct data is being sent to the browser. The table doesn’t render and after a little while, I get a browser dialog explaining that JavaScript timed out.
@Mike: You misunderstood. You must implement _all_ output types to make it work with all Google stuff, though most things will work with JSON. And you will have to return exactly the output type the request asked for or return an error, just returning CSV can’t work (how should that work if the calling application just does a javascript eval on the response but you gave it a CSV?).
I was under the impression that I controlled the client side as well. In the JavaScript app, I set the parameters of the query, including the output type that I expect.
Just to clarify: from the documentation it says:
Parameter tqx: has among others the following sub-parameter:
out – [Optional in request; Data source must handle] A string describing the format for the returned data. It can be any of the following values:
* json – [Default value] A JSON response string (described below).
As I understand it, unless this is set to something else, JSON and only JSON is a valid response format.
Maybe there is a way to instruct the table to load some CSV data, that’s possible, but that’s a different issue than implementing the Data Source stuff…
I like the look of it. My only immediate complaint is that the sorting is lost when I reload the page.
Going by http://code.google.com/intl/de-DE/apis/visualization/documentation/queries.html your response handler gets a pre-parsed variant.
So you definitely can use only response types that are supported by google.visualization.Query. Which those are seems unfortunately undocumented, but I’d just expect only JSON will work…
@Mans: Indeed. I suspect it will be up to me to programatically fix that with JavaScript. I figure that either the page needs to plant a cookie to remember the current sort order, or perhaps I can refresh the page in place using XmlHttpRequest (I think that’s what xhr is for).
@Reimar: Confusing. I remember the documentation stating that all the visualization data sources must, at a minimum, support JSON. Looks like I’ll be toying with that soon.
I like it. It looks nice and by judging by the HTML source, it is pretty clean from the server side (even though it could be even simpler by defining a new javascript function).
My only suggestion would be to set “Tests Passed” as the default sorting, since it has already as a side effect sorting by build status.
Are you are planning to make it the main front page soon?
@Vitor: I would certainly like to see it on the front page soon. I like your suggestion about the sorting order. This is my very first foray into JavaScript programming and I’m hoping to get a few more features on the page first.