Comments 17
Наверное я слишком заранее начал читать статью. У меня пока в административном интерфейсе нет собственных действий.
Хорошая, годная статья. Автор молодца
По поводу действий в админке — да, там не всё так прозрачно как кажется.
Например, не вы не хотите юзать сигналы (signals), т.к. в них проблемно узнать был изменён объект или он новый (pre_save и проверка по pk — малость хак). Поэтому вы решили просто переопределить методы ModelAdmin (например, save_model и delete_model), но какова же будет ваша радость, когда вы узнайте, что код в методе delete_model, который вы в него написали будет срабатывать только когда вы удаляйте объект с его страницы редактирования (внизу кнопочка), а вот если выбрать кучу записей в админке и выбрать действие для удаления — этот метод не отработает, т.к. там всё удаление идёт через queryset.delete().
Я был сильно удивлён и раздосадован, когда столкнулся с этим, так как большинство сигналов уже было переписано, поэтому пришлось создать небольшой пакет, который исправляет эту хренотень: django-custom_delete_selected.
Например, не вы не хотите юзать сигналы (signals), т.к. в них проблемно узнать был изменён объект или он новый (pre_save и проверка по pk — малость хак). Поэтому вы решили просто переопределить методы ModelAdmin (например, save_model и delete_model), но какова же будет ваша радость, когда вы узнайте, что код в методе delete_model, который вы в него написали будет срабатывать только когда вы удаляйте объект с его страницы редактирования (внизу кнопочка), а вот если выбрать кучу записей в админке и выбрать действие для удаления — этот метод не отработает, т.к. там всё удаление идёт через queryset.delete().
Я был сильно удивлён и раздосадован, когда столкнулся с этим, так как большинство сигналов уже было переписано, поэтому пришлось создать небольшой пакет, который исправляет эту хренотень: django-custom_delete_selected.
Да, а ещё, кстати, если вы добавляете в админку модель, таблица для которой находится в другой базе данных, то придётся писать так:
Ну, и вообще каждый раз, когда вы работаете с моделью через ORM, нужно указывать Model.objects.using('dbname'), а не просто Model.objects.
И это при том, что в большинстве (я полагаю) случаев та же самая модель никогда не используется с разными базами данных, то есть по логике название базы данных (по крайней мере, используемое по умолчанию) должно быть Meta-свойством модели, и указываться один раз при её определении.
class MultiDBModelAdmin(admin.ModelAdmin):
# A handy constant for the name of the alternate database.
using = 'other'
def save_model(self, request, obj, form, change):
# Tell Django to save objects to the 'other' database.
obj.save(using=self.using)
def delete_model(self, request, obj):
# Tell Django to delete objects from the 'other' database
obj.delete(using=self.using)
def queryset(self, request):
# Tell Django to look for objects on the 'other' database.
return super(MultiDBModelAdmin, self).queryset(request).using(self.using)
def formfield_for_foreignkey(self, db_field, request=None, **kwargs):
# Tell Django to populate ForeignKey widgets using a query
# on the 'other' database.
return super(MultiDBModelAdmin, self).formfield_for_foreignkey(db_field, request=request, using=self.using, **kwargs)
def formfield_for_manytomany(self, db_field, request=None, **kwargs):
# Tell Django to populate ManyToMany widgets using a query
# on the 'other' database.
return super(MultiDBModelAdmin, self).formfield_for_manytomany(db_field, request=request, using=self.using, **kwargs)
Ну, и вообще каждый раз, когда вы работаете с моделью через ORM, нужно указывать Model.objects.using('dbname'), а не просто Model.objects.
И это при том, что в большинстве (я полагаю) случаев та же самая модель никогда не используется с разными базами данных, то есть по логике название базы данных (по крайней мере, используемое по умолчанию) должно быть Meta-свойством модели, и указываться один раз при её определении.
В post_save передается флаг created, а в pre_save — флаг add. Оба они почти всегда могут точно сказать, что объект создается впервые.
флаг? add? вы что-то путайте
Полезная статья, добавил в закладки. Спасибо!
Formatters упоминается вскользь, так как логи построенны на стандартном Logging, какой смысл лишний раз разжевывать методики работы с ним?
стандартный jscatalog который идет с джангой — неудачное решение.
Я про views.javascript_catalog
Странно, а у меня нормально создается flatpage. Ну то есть выдается ошибка «Обязательное поле.» (django 1.4)
Правда оно у меня выдернуто из джанги и лежит как отдельное приложение, но там единственное изменение — это пара полей добавлено.
Правда оно у меня выдернуто из джанги и лежит как отдельное приложение, но там единственное изменение — это пара полей добавлено.
Ну про логи (пункт 2) — это вы зря. Джанга тут не причём, читайте просто питонскую документацию и все покровы спадут.
docs.python.org/howto/logging.html
docs.python.org/library/logging.html
docs.python.org/howto/logging.html
docs.python.org/library/logging.html
Вот по этому я и не использую Django. NIH он такой NIH…
Как пользовался Pylons так и буду дальше использовать. (или Tornado для чего то небольшого)
Как пользовался Pylons так и буду дальше использовать. (или Tornado для чего то небольшого)
Sign up to leave a comment.
Некоторые особенности Django, о которых хорошо знать заранее