[openspending-dev] Table widget for Search and Aggregates

Rufus Pollock rufus.pollock at okfn.org
Wed Feb 29 09:20:48 UTC 2012

On 20 February 2012 21:09, Friedrich Lindenberg
<friedrich.lindenberg at okfn.org> wrote:
> Hi all,

Sorry to not get to this earlier :-)

> I'm still undecided on which way to go with the new data tables in
> OpenSpending. To recap the scope, they are first going to be used for
> an embeddable search widget and then later also for displaying
> aggregates (i.e. replace datatables). There are a couple of options
> for this:
> 1) Use recline. Its nice because it already does a lot of what we need
> and since its developed "in-house" we can influence its further
> development to do more custom bits. But, to be honest, I'm also
> feature-creeped out by it: going through the list of things that it is
> supposed to do now or in the future, it's clear that we will have to
> hack it very seriously to keep it down to match its task. (And, to be

Is that really a true statement. Right now you can just grab model.js
plus view-grid.js [1] and you are go.

[1]: https://github.com/okfn/recline/blob/master/src/view-grid.js

> a bit brutal, that it will not be able to do all these things well
> with the resources we have and that it therefore will remain an
> experiment.) This is already becoming an issue in debates about it
> including multiple views or a generalized query format.

I think it is our currently our best bet and more advanced than any
other option. It is also pretty easy to add to.

> 2) Use slickgrid, jqgrid or datatables. To be honest, I'm not too
> excited about any of them - some (datatables) are trying to keep it
> simple and then only accept APIs in a very specific format, while
> others (slickgrid) are incredibly complex and try to boot what feels
> like a few copies of excel in your browser. I haven't seen a nice
> trade-off yet. On the other hand, you're likely to get mature code and
> lots of configuration options.

We've used slickgrid before and various other options. We specifically
thought about using Slickgrid for the grid component in Recline and
decided against, the primary reason being that Backbone already
provided you with a lot of the proper 'data-oriented' structure that
Slickgrid provides in a cleaner way.

> 3) Roll our own, probably a simplified/feature-limited fork of recline
> or the old spend-browser. Of course it's tempting but also probably a
> huge waste of resources. The argument here is that we don't want that

:-) -- it probably is though I very much understand of having complete control.

> much from it, but that those things are probably going to be fairly
> specific (around query state with facets and embeddability).

The issue always is that the dev curves for rolling one's own versus
using other stuff always are a mirror of each other:

a) Roll-your-own: easy at the start, and then progressively more costly
b) Re-use something else: more costly at the start but then relatively cheaper.

Where these intersect and b) becomes better than a) determines what
you should do. Given the innate tendency of coders to underestimate
the cost of a) and to prefer rolling their own my general rule is that
you should have *always* made one good faith attempt to build on an
existing library or solution before you roll your own.

> I honestly don't know where I stand on this, and I'd appreciate any
> input. @Rufus: I know you feel strongly about recline, but please put
> yourself in your OpenSpending shoes for this :)

Understood. I wrote the original table browser. Following my
injunction to reuse I used ajax-solr and the jquery tablesorter. I
think it worked OK though AJAX solr was probably overkill for what we
ended up doing.

The core of my view on this is that you probably do want a proper
internal structure and you probably want to use Backbone because it
gives you good structure while remaining lightweight. Once you are
doing that you are going to at least re-invent the model part of
Recline. Copying and pasting that is no big deal so that's definitely
an option (remember its the conceptual components that take most of
the time ;-) ). Following my point above I'd still definitely
recommend trying one good faith effort to re-use Recline -- even if
you decide against you'll have avoided the trap of underestimating a)
and you'll have a better sense of what you are doing.


More information about the openspending-dev mailing list