Это , а не определяется методом get_object
[Django -doc] , но определяется реализацией get_context_data
метод [Django -док] из DetailView
[Django -док] . Действительно, для представлений, которые наследуются от SingleObjectMixin
[Django -doc] , , он реализован как [GitHub] :
def get_context_data(self, **kwargs):
"""Insert the single object into the context dict."""
context = {}
if self.object:
<b>context['object'] = self.object</b>
context_object_name = self.get_context_object_name(self.object)
if context_object_name:
context[context_object_name] = self.object
context.update(kwargs)
return super().get_context_data(**context)
Таким образом, он всегда будет устанавливать для объекта значение self.object
(если этот объект существует), а также, если существует context_object_name
, для этого имени также.
Вы можете немного обновить его, удалив его из словаря, например:
class ListDetailView(DetailView):
context_object_name = 'aaaa'
def get_context_data(self, *args, **kwargs):
context = super().get_context_data(*args, **kwargs)
<b>context.pop('object', None)</b>
return context
def get_object(self, queryset=None):
return List.objects.get(unique_list_id=self.kwargs['unique_list_id'])
При этом я не вижу никакой пользы от его удаления. Это относится к одному и тому же объекту. Запрос не выполняется дважды: это два имени в контексте, которые относятся к объекту. Это делает контекст более равномерным , так что базовый шаблон может работать и со значением object
.
Обратите внимание, что даже если вы удалите это, вы все равно сможете получить доступ к объекту через :
{{ <b>view.object</b>.list_name }}
Поскольку базовая c реализация get_context_name
добавит переменную view
в контекст, который ссылается на экземпляр, созданный из представления.