Home

The general idea of xfilter is to provide a subset of the crossfilter API, suitable for charting libraries like dc.js. But instead of running the queries in the browser, xfilter will dispatch them to a server such as a conventional database, Nanocubes, .

Currently an implementation for Nanocubes is included, as well as an example "fgb" (filter-groupby) database.

Since these queries will usually be asynchronous, xfilter requires you to "commit" each query. You can tie into dc.js' commitHandler so that the charts will wait to redraw until the results have been received.

Note that the interface provided for configuring dimensions and groups is similar but not the same as the crossfilter interface, and xfilter allows providers to customize these interfaces further. The objective is to provide objects with the same interface as crossfilter on the charting side, but configuration is necessarily going to be different.

This allows more specific kinds of queries, tuned to the efficiency of the server.

Example: crossfilter does not provide dimension.filterMultiple, because it would not be efficient given the crossfilter implementation. But xfilter does, because this is something that charts with categorical dimensions regularly enable.

On the other hand, xfilter does not provide dimension.filterFunction, because it is not possible in general to marshal a JavaScript function to another process. Although filterFunction is very general, it is problematic when implementing a query provider on a remote server.

Long story short, filters and groups should be defined in terms of primitives that are appropriate for the server. This is not a limitation because crossfilter is configured directly by the user and charting libraries like dc.js do not touch the configuration side of crossfilter.