Michael Wehner's Profile

Considering that Morris is Javascript (and thus doesn't generate graphs server-side), it seems disappointingly complicated to use in the sort of situations demonstrated in this episode.

Specifically, since the data to be graphed is already present in the markup, it would be nice if Morris could be instructed to create the chart directly from that tabular data as represented by the markup itself. This would reduce duplication by not having specific Rails code for generating Morris-specific data, as well as removing clutter from the rendered markup which can make it more cumbersome to do certain debugging tasks, and which is only useful to Javascript anyway (and not, e.g. screen readers).

The above could imply a situation in which all of the data is present in the markup--as opposed to say, the latest data only, with the chart perhaps a representation of a longer time-frame--but as it is, Morris still would need all of that data to be present in the markup anyway (albeit in a data attribute). This could be solved nicely via AJAX, and perhaps fetching sampled data (if the data set is large), but such a request could still respond with a document fragment containing tabular markup, and thus still removing any need for separate chart-rendering code (but possibly adding a small amount of complexity for specifying things like sample resolution). This would also be a reasonable approach when only the chart itself is meant to be shown.

It's (sadly) out of date, but there was a good Javascript library that could in fact take data directly from the markup, and used the canvas to render its output: Bluff, isn't visually polished enough by today's standards, but is a good example of such functionality in action, and really and truly is easy to use.