scraperwiki-archive / spreadsheet-tool

A simple full-screen spreadsheet of the data in a cobalt box

ScraperWiki Spreadsheet Tool

This takes the best bit of Alumina and makes it… bigger!

Install this into a box, or run it locally, to see your SQLite database, full screen, as a spreadsheet.

How to use

This tool expects to call the SQLite API endpoint of a ScraperWiki box. It thus needs the full URL (including publish_token if applicable) of the box containing your data, supplied as a URI-encoded JSON object in the location hash.

The best way of explaining how to create such a hash is probably via some javascript code:

var base_url = "http://myserver.com/spreadsheet-tool";
var settings = {
  "dataset_box_url": "http://box.scraperwiki.com/example-data/pUb1i5hT0k3n/"
}
var hash = encodeURIComponent(JSON.stringify(settings))
console.log('URL to visit: ' + base_url + '#' + hash);

Try copying and pasting it into your browser's Javascript console, or a node.js console, to see what the URL (with hash!) should look like.

spreadsheet-tool's Issues

Default column widths are insufficient

Problem

The contents of cells are often quite long, and the default column width means most of the stuff is hidden and the user has to resize the column to see more. This happens more often than not. It's a pain.

Background

Columns in SlickGrid have to be explicitly sized, with widths declared when the grid is initialised, or with the grid.setColumns() functions afterwards.

SlickGrid doesn't expand or contract column widths to fit their content. Confusingly the grid.autosizeColumns(); function and the forceFitColumns: true initialisation option expand (but not contract) columns to fit the available space in your grid container – not to fit the columns' contents.

SlickGrid doesn't do this, supposedly, because when your initialise your grid, you don't know how wide to make the columns, because you've only got one initial slice of your data (100 rows, or whatever). Eg: If it set the width to 80 characters based on that initial slice, and then you loaded more rows which were wider, people say that would be no good.

I think they're wrong. Taking a best-guess is better than relying on the default, or manually having to define widths for each column in a dataset. Even if that best-guess is based on only the first 100 rows in a table. Chances are those 100 rows are pretty typical across the whole dataset. And if they're not, boohoo, the user just has to widen the column to fit the newly-loaded data. It's still better than them almost always having to resize the column, because the default's so stupid.

Solution

On the initial render of a table, find the maximum length of each column across all the existing rows, and resize the columns accordingly, using grid.setColumns() (see example here)

Manual column resizing (via header) feels disconnected

Problem

When you resize a column (by dragging the handle in the column header) the width change isn't reflected until you release the mouse. This is crap. These days you expect immediate feedback, otherwise it feels broken.

Solution

According to this webpage, you can set the following initialisation option to turn on "synchronous" resizing:

syncColumnCellResize: true

Remember sort order and column sizes when I come back

I expect it to remember the sort order / column sizes when I come back.

I want it to actually save this in the view, not in my browser. Then I can have multiple different spreadsheets for example, and it will remember across devices.