Без обиняков, кто такой Django универсальные представления?
Первые два абзаца этой страницы объясняют, что универсальные представления, как предполагается, делают мою жизнь легче, менее монотонной, и делают меня более привлекательным для женщин (я составил тот последний):
https://docs.djangoproject.com/en/1.4/topics/generic-views/
Я - все для улучшения моей жизни, но что на самом деле делают универсальные представления? Кажется, что много модных словечек бросается вокруг, которые путают больше, чем они объясняют.
Действительно ли универсальные представления подобны лесам в Ruby on Rails? Последний пункт маркированного списка во введении, кажется, указывает на это. Это - точный оператор?
3 ответа
Общие представления Django - это просто функции просмотра (обычные старые функции Python), которые делают вещи, которые очень распространены в веб-приложениях.
В зависимости от типа создаваемого приложения они могут избавить вас от написания множества очень простых представлений.
Например, общее представление direct_to_template просто отображает шаблон с RequestContext (что означает, что шаблон имеет доступ к информации по запросу, например, текущий пользователь и т. Д.).
В качестве простого примера вы можете перейти от написания таких вещей:
# urls.py
url('^some-url/$', some_view)
# views.py
def some_view(request):
return render_to_response('template_name.html', context_instance=RequestContext(request))
Просто к этому:
# urls.py
url('^some-url/$', direct_to_template, {'template': 'template_name.html'})
# views.py doesn't need any code for this view anymore
Существуют также более сложные общие представления для общих действий, таких как «отображение списка моделей» или «добавление модель в БД ».
Кроме того, поскольку общие представления - это просто функции, вы можете вызывать их в своих собственных функциях представления, чтобы выполнять «большую часть работы», когда вам нужно что-то, немного отличающееся от общих случаев.
Чтобы ответить на ваш второй вопрос: нет, общие представления не связаны с каркасом в RoR. Строительные леса, как видно из названия, сродни генерации кода. Общие представления - это нечто другое.
В основном я использую универсальное представление как более высокий уровень замены очень простых функций render_to_response . Вот как вы можете написать простое представление с помощью render_to_response :
def my_view(request):
return render_to_response('my_template.html')
Но это очень просто! Например, шаблон не будет иметь доступа к контексту запроса, если вы не передадите его явно.
Поэтому я предпочитаю использовать вместо этого общее представление:
def my_view(request):
return direct_to_template(request, template='my_template.html')
Теперь контекст запроса будет передан! И это только начало. Общие представления пригодятся, например, когда вы хотите отобразить списки или подробные представления. Они будут управлять запросами к базе данных и отправкой сообщений пользователю, среди прочего.
Таким образом, общие представления - это функции высокого уровня, которые помогают вам создавать отклик из представления.
Общие представления позволяют писать гораздо более короткий код.
Сравните:
from django.http import HttpResponse, HttpResponseRedirect, Http404
from django.shortcuts import render_to_response, get_object_or_404, redirect
from myapp.models import Context
def edit(request, item_id):
object = get_object_or_404(Context, pk=item_id)
if request.method == 'POST':
form = ContextForm(request.POST, instance=object)
if form.is_valid():
form.save()
return redirect('myapp-context-index')
else:
form = ContextForm(instance=object)
return render_to_response("myapp/context/edit.html", {'object': object, 'form': form})
с:
from django.core import urlresolvers
from django.views.generic.create_update import update_object
from myapp.models import Context
def edit(request, item_id):
return update_object(request,
object_id=item_id,
form_class=ContextForm,
template_name="myapp/context/edit.html",
post_save_redirect=urlresolvers.reverse("myapp-context-index")
)
Как и ваши обычные представления, это просто обычные функции. Если хотите, можно полностью настроить представление в URLconf, поскольку я нахожу это использование более понятным.
В качестве БОНУСа вы также получаете:
- Проверки аутентификации при входе (пройти
login_required = True) - Сообщение об успешном выполнении от
django.contrib.messages. - Меньше кода для проверки ошибок.
- По умолчанию
ModelForm, когда вы указываете параметрmodelвместоform_class.
имя_шаблона имеет значение по умолчанию «appname / model_form.html», но для меня это многовато.
Вот общий для них класс формы:
class ContextForm(forms.ModelForm):
"""The form for a context"""
class Meta:
model = Context
exclude = ('collection',)
def save(self, commit=True):
"""Overwritten save to force collection_id to a value"""
model = super(ContextForm, self).save(commit=False)
model.collection_id = 1
if commit:
model.save()
return model