class CountryTable(tables.ModelTable):\r
geo = tables.Column(data='city__geo')\r
\r
-Note that you don't need to define a relationship's fields as separate \r
+Note that you don't need to define a relationship's fields as separate\r
columns if you already have a column for the relationship itself, i.e.:\r
\r
class CountryTable(tables.ModelTable):\r
city = tables.Column()\r
- \r
+\r
for country in countries.rows:\r
print country.city.id\r
print country.city.geo\r
be able to do:\r
\r
{% load tables %}\r
- \r
-Note: The tag requires the current request to be available as ``request`` \r
+\r
+Note: The tag requires the current request to be available as ``request``\r
in the context (usually, this means activating the Django request context\r
processor).\r
\r
-\r
-TODO\r
-----\r
- - "data", if used to format for display, affect sorting; this stuff needs\r
- some serious redesign.\r
- - as_html methods are all empty right now\r
- - table.column[].values is a stub\r
- - filters\r
- - grouping\r
- - choices support for columns (internal column value will be looked up\r
- for output)\r
- - for columns that span model relationships, automatically generate\r
- select_related(); this is important, since right now such an e.g.\r
- order_by would cause rows to be dropped (inner join).\r
- - initialize auto-generated columns with the relevant properties of the\r
- model fields (verbose_name, editable=visible?, ...)\r
- - remove support for callable fields? this has become obsolete since we\r
- Column.data property; also, it's easy to make the call manually, or let\r
- the template engine handle it\r
- - tests could use some refactoring, they are currently all over the place\r
- - what happens if duplicate column names are used? we currently don't\r
- check for that at all\r
-\r
-Filters\r
-~~~~~~~\r
-\r
-Filtering is already easy (just use the normal queryset methods), but\r
-filter support in django-tables would want to hide the Django ORM syntax\r
-from the user.\r
-\r
- * For example, say a ``models.DateTimeField`` should be filtered\r
- by year: the user would only see ``date=2008`` rather than maybe\r
- ``published_at__year=2008``.\r
-\r
- * Say you want to filter out ``UserProfile`` rows that do not have\r
- an avatar image set. The user would only see ```no_avatar``, which\r
- in Django ORM syntax might map to\r
- ``Q(avatar__isnull=True) | Q(avatar='')``.\r
-\r
-Filters would probably always belong to a column, and be defined along\r
-side one.\r
-\r
- class BookTable(tables.ModelTable):\r
- date = tables.Column(filter='published_at__year')\r
-\r
-If a filter is needed that does not belong to a single colunn, a column\r
-would have to be defined for just that filter. A ``tables.Filter`` object\r
-could be provided that would basically be a column, but with default\r
-properties set so that the column functionality is disabled as far as\r
-possible (i.e. ``visible=False`` etc):\r
-\r
- class BookTable(tables.ModelTable):\r
- date = tables.Column(filter='published_at__year')\r
- has_cover = tables.Filter('cover__isnull', value=True)\r
-\r
-Or, if Filter() gets a lot of additional functionality like ``value``,\r
-we could generally make it available to all filters like so:\r
-\r
- class BookTable(tables.ModelTable):\r
- date = tables.Column(filter=tables.Filter('published_at__year', default=2008))\r
- has_cover = tables.Filter('cover__isnull', value=True)\r
-\r
-More complex filters should be supported to (e.g. combine multiple Q\r
-objects, support ``exclude`` as well as ``filter``). Allowing the user\r
-to somehow specify a callable probably is the easiest way to enable this.\r
-\r
-The filter querystring syntax, as exposed to the user, could look like this:\r
-\r
- /view/?filter=name:value\r
- /view/?filter=name\r
-\r
-It would also be cool if filters could be combined. However, in that case\r
-it would also make sense to make it possible to choose individual filters\r
-which cannot be combined with any others, or maybe even allow the user\r
-to specify complex dependencies. That may be pushing it though, and anyway\r
-won't make it into the first version.\r
-\r
- /view/?filter=name:value,foo:bar\r
-\r
-We need to think about how we make the functionality available to\r
-templates.\r
-\r
-Another feature that would be important is the ability to limit the valid\r
-values for a filter, e.g. in the date example only years from 2000 to 2008.\r
-\r
-Use django-filters:\r
- - would support html output\r
- - would not work at all with our planned QueryTable\r
- - conflicts somewhat in that it also allows ordering\r
- \r
-To autoamtically allow filtering a column with filter=True, we would need to\r
-have subclasses for each model class, even if it just redirects to use the \r
-correct filter class; \r
-\r
-If not using django-filter, we wouldn't have different filter types; filters \r
-would just hold the data, and each column would know how to apply it.\r
--- /dev/null
+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.
\ No newline at end of file
projects / django-tables2.git / commitdiff