Комментарии 5
Кажется в данном примере как раз данные разные, а отображение одно и то-же.
Под разными данными я понимаю содержимое, а не форму. Форма у данных одна и таже.
Посему: что мешает оставлять один и тот-же вид, а в котроллере отлавливать параметры сортировки?
Под разными данными я понимаю содержимое, а не форму. Форма у данных одна и таже.
Посему: что мешает оставлять один и тот-же вид, а в котроллере отлавливать параметры сортировки?
Да, нестыковочка) Там по сути и отображение и данные разные. Я немного неверно (неполно?) изложил свою мысль. Тут и шаблон разный и данные. Проблема в том, что если бы данные были одинаковыми, то смысла в нагромождении небыло бы... Да, с одной стороны правильный вынос функционала в отдельную функцию на будущее. Но это бессмысленно.
Суть в том, что в extra_view мы получаем одни и те же данные в плане их структуры, а вот отображаем в зависимости от потребностей пользователя.
Приведу для примера свой код, всё же.
Суть в том, что в extra_view мы получаем одни и те же данные в плане их структуры, а вот отображаем в зависимости от потребностей пользователя.
Приведу для примера свой код, всё же.
def video_list(request, object_set=Video.objects.all(), tpl_add={}):
"""
Все списки пропускать через эту херню, классический упрощённый, либо класический вид
и т.п. на основе request. Итого:
* Учитывает какой тип представления выбрал пользователь
* Учитывает сортировку, если указано
* Делает выборку по дате
"""
view_type = request.GET.get('view', 'classic')
time_type = request.GET.get('time', 'all')
show_type = request.GET.get('show', 'new')
object_set = object_set.order_by('-add_date')
object_set = add_time_filter(time_type, object_set)
return render_to_response('catalog/%s.html' % view_type,
RequestContext(request, {'videos': object_set,
'view_type': view_type,
'time_type': time_type,
'show_type': show_type,
'tpl_add': tpl_add}))
Я в последнее время частенько в качестве extra_view использую generic views - большая часть вьюх так или иначе к ним сводится.
P.S> Помните об эффективности и красоте кода, это крайне важно.
Как бы это доходчиво другим обьяснить?
Декомпозиция на функции это все-таки процедурное программирование. Не в смысле плохо, просто — по-другому.
Если рассматривать данный код в разрезе MVC, то функции из view.py, обрабатывающие
В качестве примера View в Django можно рассматривать django.forms.*.
Но, по большому счету, Django — не MVC фреймворк.
Если рассматривать данный код в разрезе MVC, то функции из view.py, обрабатывающие
request, и возвращающие HttpPresponse это экстеншены для Controller. А View размазано между логикой, формирующей dictionary в таком вот обработчике запроса, и рендером шаблона внутри render_to_response('template.html', dictionary). В качестве примера View в Django можно рассматривать django.forms.*.
Но, по большому счету, Django — не MVC фреймворк.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разные варианты отображения для одних и тех же данных