Django. get_success_url. Почему так, а не иначе?

Question

[Станислав Фатеев]

В ModelFormMixin, который используется BaseUpdateView, в методе get_success_url() есть url = self.object.get_absolute_url()
соответственно, нам не нужно задавать success_url = reverse_lazy('блаблабла') во вьюхе, а определить get_absolute_url() в модели.
В отличие от этого, DeletionMixin, который используется BaseDeleteView, так не делает, ему нужен именно success_url.
Почему так? Почему не сделать их одинаковыми? Мне пришлось переопределять get_success_url для моего DeleteView, что бы он делал так, как я хочу.
Или я как-то неправильно работаю с success_url во вьюхе? Мне надо вычислять url по ForeignKey, делаю примерно так:

model Child(models.Model):
    parent = models.ForeignKey(Parent)
    def get_absolute_url(self):
        return reverse('parent-detail', kwargs={'pk':str(self.parent.pk)})

Как можно тоже самое сделать в success_url? Я ведь не могу там написать self.parent.pk.

Answer 1

[Roman K]

Очевидно, потому что после того, как поработает DeleteView, объект удалится и нет смысла ему получать get_absolute_url удалённого объекта, да и получить его не получится.

P.S. Не знаю, какая у вас там структура, но зачем вы получаете URL родителя в ребёнке?

Comments

[Станислав Фатеев]

Нужно из CreateView ребенка перейти к DetailView родителя, и для этого я его вычисляю. А как иначе? Вот тоже думал что не получится получить get_absolute_url удаленного объекта, но у меня-то работает, значит он вычисляет его раньше чем удаляет?

[Roman K]

Станислав Фатеев: get_absolute_url должен возвращать URL именно этого объекта, а не какого-то там ещё. Чтобы из CreateView ребёнка перейти к DetailView родителя, вам нужно в CreateView переопределить get_success_url, но никак не ломать всю структуру и идеологию джанго.

[Станислав Фатеев]

Roman Kitaev: логично, спасибо

[Roman K]

Станислав Фатеев: Раз вы так мало знакомы с методом get_absolute_url, вы наверное, и reverse с {% url %} не пользуетесь? Настоятельно советую прочитать документацию на эту тему (вместо Wrong way использовать Right way!) и в get_absolute_url модели использовать reverse.

[Roman K]

Станислав Фатеев: Упс. Забыл поставить тег code.

<a href="/forum/threads">Wrong way</a>
<a href="{% url 'thread_list' %}">Right way</a>

[Станислав Фатеев]

Roman Kitaev: не, конечно урлы не хардкожу (хардкодю?) , просто не понимал истинного назначения get_absolute_url

[sim3x]

Станислав Фатеев: лучше понять раньше чем позже

джанго дает возможность реализовать стратегию
fat model - модель все сама умеет делать
thin view - вью просто вызивает методы модели
stupid template - темплейт только рендерит то что отдала вью

[Станислав Фатеев]

sim3x: читал про это в Two Scoops of Django, немного не понятны критерии когда view все еще thin, и когда он уже толстеет. Вот мне в последнем проекте я переопределяю у ListView get_queryset(), пишу в нем довольно сложную логику (надо хитро отфильтровать модели), это значит я на неправильном пути? А как тогда правильно? Копать в сторону кастомных менеджеров моделей?

[Roman K]

Станислав Фатеев: Да, тогда вьюха толстеет. Правильно - выделять нужные переменные из запроса во вьюхе и отдавать методу модели, а он уже должен отдать результат.

[Alexander]

Станислав Фатеев: Есть ещё миксы у Class Based Views

[sim3x]

Станислав Фатеев:

class MyObject(Model):
....

# ! порядок обьявления важен ! сначала дефолт менеджер
   objects = models.Manager() 
# если нужно кастомная фильрация, сортировка, запрос,..
   custom_list = MyCustomManager() 
   ...
# если нужно добавить калькулируемое свойство к одному своему обьекту
   def  myobject_custom_property(self): 
       return

Answer 2

[Vladimir Abramov]

Ну а что не понятного? После удаления тебе куда-то пользователя надо послать. В отсутствии модели куда именно можешь решить только ты.

Comments

[Станислав Фатеев]

Да это понятно, вопрос не в этом.