TODO

Document how the user can access the raw row data; and possible make this
easier by falling back to the raw data directly if a column is accessed
which doesn't exist.

There's no particular reason why this should be Django-specific. Now with
the base table better abstracted, we should be able to easily create a
SQLAlchemyTable or a StormTable.

If the table were passed a ``request`` object, it could generate columns
proper sort links without requiring the set_url_param tag. However, that
might introduce a Django dependency. Possibly rather than the request we
could expect a dict of query string values.

It would be cool if for non-model tables, a custom compare function could
be provided to modify the sort. This would require a minor refactor in
which we have multiple different table types subclass a base table, and
the subclass allowing it's columns to support additional kwargs.

"data", is used to format for display, affect sorting; this stuff needs
some serious redesign.

as_html methods are all empty right now

table.column[].values is a stub

Filters + grouping

Choices support for columns (internal column value will be looked up for
output

For columns that span model relationships, automatically generate
select_related(); this is important, since right now such an e.g.
order_by would cause rows to be dropped (inner join).

Initialize auto-generated columns with the relevant properties of the model
fields (verbose_name, editable=visible?, ...)

Remove support for callable fields? this has become obsolete since we
Column.data property; also, it's easy to make the call manually, or let
the template engine handle it.

Tests could use some refactoring, they are currently all over the place

What happens if duplicate column names are used? we currently don't check
for that at all.


Filters
~~~~~~~

Filtering is already easy (just use the normal queryset methods), but
filter support in django-tables would want to hide the Django ORM syntax
from the user.

    * For example, say a ``models.DateTimeField`` should be filtered
      by year: the user would only see ``date=2008`` rather than maybe
      ``published_at__year=2008``.

    * Say you want to filter out ``UserProfile`` rows that do not have
      an avatar image set. The user would only see ```no_avatar``, which
      in Django ORM syntax might map to
      ``Q(avatar__isnull=True) | Q(avatar='')``.

Filters would probably always belong to a column, and be defined along
side one.

    class BookTable(tables.ModelTable):
        date = tables.Column(filter='published_at__year')

If a filter is needed that does not belong to a single colunn, a column
would have to be defined for just that filter. A ``tables.Filter`` object
could be provided that would basically be a column, but with default
properties set so that the column functionality is disabled as far as
possible (i.e. ``visible=False`` etc):

    class BookTable(tables.ModelTable):
        date = tables.Column(filter='published_at__year')
        has_cover = tables.Filter('cover__isnull', value=True)

Or, if Filter() gets a lot of additional functionality like ``value``,
we could generally make it available to all filters like so:

    class BookTable(tables.ModelTable):
        date = tables.Column(filter=tables.Filter('published_at__year', default=2008))
        has_cover = tables.Filter('cover__isnull', value=True)

More complex filters should be supported to (e.g. combine multiple Q
objects, support ``exclude`` as well as ``filter``). Allowing the user
to somehow specify a callable probably is the easiest way to enable this.

The filter querystring syntax, as exposed to the user, could look like this:

    /view/?filter=name:value
    /view/?filter=name

It would also be cool if filters could be combined. However, in that case
it would also make sense to make it possible to choose individual filters
which cannot be combined with any others, or maybe even allow the user
to specify complex dependencies. That may be pushing it though, and anyway
won't make it into the first version.

    /view/?filter=name:value,foo:bar

We need to think about how we make the functionality available to
templates.

Another feature that would be important is the ability to limit the valid
values for a filter, e.g. in the date example only years from 2000 to 2008.

Use django-filters:
    - would support html output
    - would not work at all with our planned QueryTable
    - conflicts somewhat in that it also allows ordering

To autoamtically allow filtering a column with filter=True, we would need to
have subclasses for each model class, even if it just redirects to use the
correct filter class;

If not using django-filter, we wouldn't have different filter types; filters
would just hold the data, and each column would know how to apply it.