@@ -26,8 +26,8 @@ It's available in a few places, feedback is always welcome.
26
26
Tutorial
27
27
========
28
28
29
- Install the app via ``pip install django-tables2 ``, then add
30
- ``'django_tables2' `` to ``INSTALLED_APPS ``.
29
+ 1. ``pip install django-tables2 ``
30
+ 2. Add ``'django_tables2' `` to ``INSTALLED_APPS ``
31
31
32
32
Find some data that you'd like to render as a table. A QuerySet will work, but
33
33
ease of demonstration we'll use a list of dicts:
@@ -342,31 +342,24 @@ a hook that allows abitrary attributes to be added to the ``<table>`` tag.
342
342
--------------------------------
343
343
344
344
If you want to adjust the way table cells in a particular column are rendered,
345
- you can implement a ``render_FOO `` method. ``FOO `` is replaced with the
345
+ you can implement a ``render_FOO `` method. ``FOO `` should be the
346
346
:term: `name <column name> ` of the column.
347
347
348
348
This approach provides a lot of control, but is only suitable if you intend to
349
349
customise the rendering for a single table (otherwise you'll end up having to
350
350
copy & paste the method to every table you want to modify – which violates
351
351
DRY).
352
352
353
- For convenience, a bunch of commonly used/useful values are passed to
354
- ``render_FOO `` functions, when writing the signature, simply accept the
355
- arguments you're interested in, and the function will recieve them
353
+ Supported keyword arguments include: (only the arguments declared will be passed)
356
354
357
- .. note :: Due to the implementation, a "catch-extra" arguments (e.g. ``*args``
358
- or ``**kwargs ``) will not recieve any arguments. This is because
359
- ``inspect.getargsspec() `` is used to check what arguments a ``render_FOO ``
360
- method expect, and only to supply those.
355
+ - ``record `` -- the entire record for the row from the :term: `table data `
356
+ - ``value `` -- the value for the cell retrieved from the :term: `table data `
357
+ - ``column `` -- the :class: `.Column ` object
358
+ - ``bound_column `` -- the :class: `.BoundColumn ` object
359
+ - ``bound_row `` -- the :class: `.BoundRow ` object
360
+ - ``table `` -- alias for ``self ``
361
361
362
- :param value: the value for the cell retrieved from the :term: `table data `
363
- :param record: the entire record for the row from :term: `table data `
364
- :param column: the :class: `.Column ` object
365
- :param bound_column: the :class: `.BoundColumn ` object
366
- :param bound_row: the :class: `.BoundRow ` object
367
- :param table: alias for ``self ``
368
-
369
- .. code-block :: python
362
+ Example::
370
363
371
364
>>> import django_tables2 as tables
372
365
>>> class SimpleTable(tables.Table):
@@ -390,6 +383,15 @@ arguments you're interested in, and the function will recieve them
390
383
<10>
391
384
31
392
385
386
+ .. note ::
387
+
388
+ Due to the implementation of dynamic argument passing, any "catch-extra"
389
+ arguments (e.g. ``*args `` or ``**kwargs ``) will not recieve any arguments.
390
+ This is because `inspect.getargsspec() `__ is used to check what arguments a
391
+ ``render_FOO `` method expect, and only to supply those.
392
+
393
+ .. __ : http://docs.python.org/library/inspect.html#inspect.getargspec
394
+
393
395
394
396
.. _query-string-fields :
395
397
@@ -645,37 +647,37 @@ Class Based Generic Mixins
645
647
Django 1.3 introduced `class based views `__ as a mechanism to reduce the
646
648
repetition in view code. django-tables2 comes with a single class based view
647
649
mixin: ``SingleTableMixin ``. It makes it trivial to incorporate a table into a
648
- view/template, however it requires a few variables to be defined on the view:
650
+ view/template.
651
+
652
+ The following view parameters are supported:
649
653
650
654
- ``table_class `` –- the table class to use, e.g. ``SimpleTable ``
651
- - ``table_data `` (or ``get_table_data() ``) -- the data used to populate the
652
- table
653
- - ``context_table_name `` -- the name of template variable containing the table
654
- object
655
+ - ``table_data `` (or ``get_table_data() ``) -- the data used to populate the table
656
+ - ``context_table_name `` -- the name of template variable containing the table object
657
+ - ``table_pagination `` -- pagination options to pass to :class: `RequestConfig `
655
658
656
659
.. __ : https://docs.djangoproject.com/en/1.3/topics/class-based-views/
657
660
658
661
For example:
659
662
660
663
.. code-block :: python
661
664
662
- from django_tables2.views import SingleTableMixin
663
- from django.views.generic.list import ListView
665
+ from django_tables2 import SingleTableView
664
666
665
667
666
- class Simple (models .Model ):
668
+ class Person (models .Model ):
667
669
first_name = models.CharField(max_length = 200 )
668
670
last_name = models.CharField(max_length = 200 )
669
671
670
672
671
- class SimpleTable (tables .Table ):
672
- first_name = tables.Column()
673
- last_name = tables.Column()
673
+ class PersonTable (tables .Table ):
674
+ class Meta :
675
+ model = Simple
674
676
675
677
676
- class MyTableView ( SingleTableMixin , ListView ):
677
- model = Simple
678
- table_class = SimpleTable
678
+ class PersonList ( SingleTableView ):
679
+ model = Person
680
+ table_class = PersonTable
679
681
680
682
681
683
The template could then be as simple as:
@@ -691,11 +693,14 @@ when one isn't explicitly defined.
691
693
692
694
.. note ::
693
695
694
- If you want more than one table on a page, at the moment the simplest way
695
- to do it is to use ``SimpleTableMixin `` for one of the tables, and write
696
- the boilerplate for the other yourself in ``get_context_data() ``. Obviously
697
- this isn't particularly elegant, and as such will hopefully be resolved in
698
- the future.
696
+ If you need more than one table on a page, use ``SingleTableView `` and use
697
+ ``get_context_data() `` to initialise the other tables and add them to the
698
+ context.
699
+
700
+ .. note ::
701
+
702
+ You don't have to base your view on ``ListView ``, you're able to mix
703
+ ``SingleTableMixin `` directly.
699
704
700
705
701
706
Table Mixins
@@ -811,8 +816,8 @@ fixed in a similar way -- the :attr:`.Table.Meta.sequence` option::
811
816
API Reference
812
817
=============
813
818
814
- :class: `Accessor ` Objects:
815
- --------------------------
819
+ :class: `Accessor ` (` A `) Objects:
820
+ --------------------------------
816
821
817
822
.. autoclass :: django_tables2.utils.Accessor
818
823
@@ -1060,7 +1065,7 @@ API Reference
1060
1065
--------------------------
1061
1066
1062
1067
.. autoclass :: django_tables2.rows.BoundRows
1063
- :members: __iter__, __len__, count
1068
+ :members: __iter__, __len__
1064
1069
1065
1070
1066
1071
:class: `BoundRow ` Objects
@@ -1070,27 +1075,6 @@ API Reference
1070
1075
:members: __getitem__, __contains__, __iter__, record, table, items
1071
1076
1072
1077
1073
- :class: `AttributeDict ` Objects
1074
- ------------------------------
1075
-
1076
- .. autoclass :: django_tables2.utils.AttributeDict
1077
- :members:
1078
-
1079
-
1080
- :class: `OrderBy ` Objects
1081
- ------------------------
1082
-
1083
- .. autoclass :: django_tables2.utils.OrderBy
1084
- :members:
1085
-
1086
-
1087
- :class: `OrderByTuple ` Objects
1088
- -----------------------------
1089
-
1090
- .. autoclass :: django_tables2.utils.OrderByTuple
1091
- :members: __unicode__, __contains__, __getitem__, cmp, get
1092
-
1093
-
1094
1078
Upgrading from django-tables Version 1
1095
1079
======================================
1096
1080
@@ -1163,12 +1147,6 @@ Glossary
1163
1147
accessor
1164
1148
Refers to an :class: `~django_tables2.utils.Accessor ` object
1165
1149
1166
- bare orderby
1167
- The non-prefixed form of an :class: `~django_tables2.utils.OrderBy `
1168
- object. Typically the bare form is just the ascending form.
1169
-
1170
- Example: ``age `` is the bare form of ``-age ``
1171
-
1172
1150
column name
1173
1151
The name given to a column. In the follow example, the *column name * is
1174
1152
``age ``.
0 commit comments