TODO

   1 Document how the user can access the raw row data; and possible make this
   2 easier by falling back to the raw data directly if a column is accessed
   3 which doesn't exist.
   4
   5 There's no particular reason why this should be Django-specific. Now with
   6 the base table better abstracted, we should be able to easily create a
   7 SQLAlchemyTable or a StormTable.
   8
   9 If the table were passed a ``request`` object, it could generate columns
  10 proper sort links without requiring the set_url_param tag. However, that
  11 might introduce a Django dependency. Possibly rather than the request we
  12 could expect a dict of query string values.
  13
  14 It would be cool if for non-model tables, a custom compare function could
  15 be provided to modify the sort. This would require a minor refactor in
  16 which we have multiple different table types subclass a base table, and
  17 the subclass allowing it's columns to support additional kwargs.
  18
  19 "data", is used to format for display, affect sorting; this stuff needs
  20 some serious redesign.
  21
  22 as_html methods are all empty right now
  23
  24 table.column[].values is a stub
  25
  26 Filters + grouping
  27
  28 Choices support for columns (internal column value will be looked up for
  29 output
  30
  31 For columns that span model relationships, automatically generate
  32 select_related(); this is important, since right now such an e.g.
  33 order_by would cause rows to be dropped (inner join).
  34
  35 Initialize auto-generated columns with the relevant properties of the model
  36 fields (verbose_name, editable=visible?, ...)
  37
  38 Remove support for callable fields? this has become obsolete since we
  39 Column.data property; also, it's easy to make the call manually, or let
  40 the template engine handle it.
  41
  42 Tests could use some refactoring, they are currently all over the place
  43
  44 What happens if duplicate column names are used? we currently don't check
  45 for that at all.
  46
  47
  48 Filters
  49 ~~~~~~~
  50
  51 Filtering is already easy (just use the normal queryset methods), but
  52 filter support in django-tables would want to hide the Django ORM syntax
  53 from the user.
  54
  55     * For example, say a ``models.DateTimeField`` should be filtered
  56       by year: the user would only see ``date=2008`` rather than maybe
  57       ``published_at__year=2008``.
  58
  59     * Say you want to filter out ``UserProfile`` rows that do not have
  60       an avatar image set. The user would only see ```no_avatar``, which
  61       in Django ORM syntax might map to
  62       ``Q(avatar__isnull=True) | Q(avatar='')``.
  63
  64 Filters would probably always belong to a column, and be defined along
  65 side one.
  66
  67     class BookTable(tables.ModelTable):
  68         date = tables.Column(filter='published_at__year')
  69
  70 If a filter is needed that does not belong to a single colunn, a column
  71 would have to be defined for just that filter. A ``tables.Filter`` object
  72 could be provided that would basically be a column, but with default
  73 properties set so that the column functionality is disabled as far as
  74 possible (i.e. ``visible=False`` etc):
  75
  76     class BookTable(tables.ModelTable):
  77         date = tables.Column(filter='published_at__year')
  78         has_cover = tables.Filter('cover__isnull', value=True)
  79
  80 Or, if Filter() gets a lot of additional functionality like ``value``,
  81 we could generally make it available to all filters like so:
  82
  83     class BookTable(tables.ModelTable):
  84         date = tables.Column(filter=tables.Filter('published_at__year', default=2008))
  85         has_cover = tables.Filter('cover__isnull', value=True)
  86
  87 More complex filters should be supported to (e.g. combine multiple Q
  88 objects, support ``exclude`` as well as ``filter``). Allowing the user
  89 to somehow specify a callable probably is the easiest way to enable this.
  90
  91 The filter querystring syntax, as exposed to the user, could look like this:
  92
  93     /view/?filter=name:value
  94     /view/?filter=name
  95
  96 It would also be cool if filters could be combined. However, in that case
  97 it would also make sense to make it possible to choose individual filters
  98 which cannot be combined with any others, or maybe even allow the user
  99 to specify complex dependencies. That may be pushing it though, and anyway
 100 won't make it into the first version.
 101
 102     /view/?filter=name:value,foo:bar
 103
 104 We need to think about how we make the functionality available to
 105 templates.
 106
 107 Another feature that would be important is the ability to limit the valid
 108 values for a filter, e.g. in the date example only years from 2000 to 2008.
 109
 110 Use django-filters:
 111     - would support html output
 112     - would not work at all with our planned QueryTable
 113     - conflicts somewhat in that it also allows ordering
 114
 115 To autoamtically allow filtering a column with filter=True, we would need to
 116 have subclasses for each model class, even if it just redirects to use the
 117 correct filter class;
 118
 119 If not using django-filter, we wouldn't have different filter types; filters
 120 would just hold the data, and each column would know how to apply it.