Django-tables2: Intuitive Möglichkeit zum dynamischen Hinzufügen von Spalten
Aufgrund der ganzen Metamagie verwende ich derzeit:
class StatsTable(tables.Table):
class Meta:
orderable = False
attrs = {'class': 'tablesorter'}
def __init__(self, form, request, *args, **kwargs):
rf_values = form.get_values()
rf_annotations = form.get_annotations()
rf_filter = form.get_filter()
rf_calculations = form.get_calculations()
data = list(
HourlyStat.objects.filter(**rf_filter).values(*rf_values).annotate(**rf_annotations).order_by('-clicks')
)
super(StatsTable, self).__init__(data, *args, **kwargs)
columns = rf_values + rf_annotations.keys() + rf_calculations
for col in columns:
self.base_columns[col] = tables.Column()
Das einzige Problem mit mir, es so zu verwenden, ist die Tatsache, dass ich nicht einfach super() als letztes aufrufen kann, es muss in der Mitte sein. Ich denke, das liegt daran, dass die Metaklasse nicht selbst nach base_columns sucht, sondern nur in geerbten Modellen. Dies scheint wirklich viel chaotischer zu sein als die self.fields auf Django-Formularen.
blite
Alle 3 Kommentare
Das ist komisch
Ich füge dynamische Spalten hinzu, indem ich sie einfach an self.base_columns anhänge:
self.base_columns['column_name'] = tables.Column()
Eine Sache, die ich ärgerlich fand, ist, dass ich dabei das Klassenattribut und nicht das Instanzattribut ändere, sodass jede Spalte, die ich zu einer Anfrage hinzufüge, bei jeder nachfolgenden Anfrage an die Tabelle angezeigt wird, die Lösung für echte dynamische Spalten, die ich gefunden habe war:
class ComponenteContableColumns(tables.Table):
"""Table that shows ComponentesContables as columns."""
a_static_columns = tables.Column()
def __init__(self, *args, **kwargs):
# Create a copy of base_columns to restore at the end.
self._bc = copy.deepcopy(self.base_columns)
# Your dynamic columns added here:
if today is 'monday':
self.base_columns['monday'] = tables.Column()
if today is 'tuesday':
self.base_columns['tuesday'] = tables.Column()
super().__init__(*args, **kwargs)
# restore original base_column to avoid permanent columns.
type(self).base_columns = self._bc
jmfederico
am 6. Juni 2015
Ich habe das gleiche Problem wie @jmfederico und musste seinen vorgeschlagenen Hack (Workaround)
Als Referenz hier ist meine Tabellenklasse
class ActivitySummaryTable(TableWithRawData):
activity = tables.Column(verbose_name=_('Activity'), orderable=False)
# the rest of the columns will be added based on the filter provided
def __init__(self, extra_cols, *args, **kwargs):
"""Pass in a list of tuples of extra columns to add in the format (colunm_name, column)"""
# Temporary hack taken from: https://github.com/bradleyayers/django-tables2/issues/70 to avoid the issue where
# we got the same columns from the previous instance added back
# Create a copy of base_columns to restore at the end.
_bc = copy.deepcopy(self.base_columns)
for col_name, col in extra_cols:
self.base_columns[col_name] = col
super(ActivitySummaryTable, self).__init__(*args, **kwargs)
# restore original base_column to avoid permanent columns.
type(self).base_columns = _bc
class Meta:
attrs = {'class': 'table'}
order_by = ('activity',)
Beispiel, in dem wir die Daten filtern und dann am Ende 2 vereinzelte Daten hinzugefügt werden
intiocean
am 19. Dez. 2016
in 817d711 mit dem Argument extra_columns behoben
jieter
am 24. Mai 2017
Verwandte Themen
applegrew
·
17Kommentare
mpasternak
·
9Kommentare
foldedpaper
·
6Kommentare
wtfrank
·
32Kommentare
brianmay
·
6Kommentare
Hilfreichster Kommentar
Das ist komisch
Ich füge dynamische Spalten hinzu, indem ich sie einfach an self.base_columns anhänge:
Eine Sache, die ich ärgerlich fand, ist, dass ich dabei das Klassenattribut und nicht das Instanzattribut ändere, sodass jede Spalte, die ich zu einer Anfrage hinzufüge, bei jeder nachfolgenden Anfrage an die Tabelle angezeigt wird, die Lösung für echte dynamische Spalten, die ich gefunden habe war: