У меня точно такая же потребность; вот самый простой способ, которым я дошел до сих пор.
В списках администратора есть list_filter , с помощью которого вы можете, например, сделать это (при условии, что вы зарегистрируете классы администратора и т. Д.):
class AlbumAdmin(admin.ModelAdmin):
list_display = ('artist', 'albumName', 'year',)
list_filter = ('artist',)
Это добавит право столбец на вашем административном сайте со списком исполнителей, и если вы нажмете на него, список альбомов будет отфильтрован, чтобы показать только те, которые сделаны этим исполнителем.
Имея это, и вот хитрость, оказывается, что даже если вы не объявите «list_filter», Django все равно будет фильтровать вещи в соответствии с параметрами URL. Итак, я активировал фильтры, я нажал на одного из моих «исполнителей», чтобы список был отфильтрован, и я смог увидеть, как он форматирует URL, что-то вроде […] / admin / app_name / model_name /? ForeignKeyName__id__exact = XX
В вашем случае я думаю, что это будет выглядеть примерно так: […] / admin / music_library / album /? Artist__id__exact = XX
Попробуйте выполнить следующие действия, а затем удалите строку «list_filter» , и вы увидите, что URL все еще работает.
Итак, теперь мы знаем, что единственное, что нам нужно, это передать param artist __id__exact = XX, поэтому мы должны добавить для этого столбец с кнопкой.
class ArtistAdmin(admin.ModelAdmin):
list_display = ('artistName', 'genre', 'artists_list_field')
def artists_list_field(self, obj):
return mark_safe(u'Albums' % (
'music_library', 'album', obj.id))
С этим у вас все работает, но это не очень хорошая практика, потому что мы жестко программируем URL. Вместо «music_library» и «album» мы должны динамически передавать фактическое имя приложения и модели. Это то, что я сейчас исследую. Например, если другая модель находится в том же приложении (как в вашем случае), для имени приложения это выглядит так:
u'Albums' % (
obj._meta.app_label, 'album', obj.id)
Я надеюсь, что это полезно!
Скажем, у Вас есть таблица продуктов, которая похожа на это:
Products
----------
id
price
Products_Translations
----------------------
product_id
locale
name
description
Затем Вы просто присоединяетесь на product_id = product.id и где локаль ='en-US'
конечно, это оказывает влияние на производительность, так как Вам теперь нужно соединение для завоевывания репутацию и описание, но это позволяет любое количество локалей позже.
Я живо, что больше информации о том, что Вы делаете, было бы полезно. МОЖНО ЛИ дать некоторые образцы данных? И под чем Вы подразумеваете динамичный? То, что будет много данных, вставляемых со временем и много изменений в данных или что данные только должны быть доступными в течение маленького промежутка времени.
В целом необходимо, вероятно, смотреть на родителя с общими нелокализованными данными и дочернюю таблицу с локализованными данными и ключом языка. Если динамическим, Вы подразумеваете, что это часто изменяется, можно хотеть взглянуть на использование триггеров, и что-то как 'translationRequired' отмечает для маркировки вещей, которые нуждаются к переводу после того, как изменение внесено.
Можно ли описать природу 'динамических данных'?
Один способ реализовать это состоял бы в том, чтобы иметь 3 различных таблицы:
[1, English], [2, Spanish]
[1, 'Data1'], [2, 'Data2']
So: [Data_Language, Data_Definition, Language, Translation] [1, 1, 1, 'Red'] [2, 1, 2, 'Rojo'] [3, 2, 1, 'Green'] [4, 2, 2, 'Verde'] etc ...
Когда динамические данные вводятся, создают значение по умолчанию 'английский язык', записывают и затем переводят на Вашем досуге.