Указание разных имен шаблонов в общих представлениях Django - PullRequest
2 голосов
/ 24 марта 2009

У меня есть код в моем urls.py для моих общих представлений;

infodict = {
'queryset': Post.objects.all(),
'date_field': 'date',
'template_name': 'index.html',
'template_object_name': 'latest_post_list',
}

urlpatterns += patterns('django.views.generic.date_based',
(r'^gindex/$', 'archive_index', infodict),
)

Таким образом, при переходе по адресу / gindex / будет использоваться универсальное представление с шаблоном index.html.

Но так как в этом urlpattern у меня будут более общие представления, как мне предоставить другое имя шаблона, используя тот же самый infodict? Я не хочу использовать много infodicts, и я не могу использовать имя шаблона по умолчанию.

Обратите внимание, что это также относится к имени объекта шаблона в infodict.

Спасибо за вашу помощь!

Редактировать : Это один из моих первых вопросов по stackoverflow, и я поражен подробными ответами! Я предпочитаю использовать конструктор dict, о котором я не знал. Я нахожу использование документации на Python немного сложнее, так как не могу найти то, что обычно ищу!

Еще раз спасибо за все ответы и разные подходы.

Ответы [ 4 ]

8 голосов
/ 24 марта 2009

Используйте конструктор dict ():

infodict = {
    'queryset': Post.objects.all(),
    'date_field': 'date',
    'template_name': 'index.html',
    'template_object_name': 'latest_post_list',
}

urlpatterns = patterns('django.views.generic.date_based',
    url(r'^gindex/$', 'archive_index', dict(infodict, template_name='gindex.html')),
    url(r'^hindex/$', 'archive_index', dict(infodict, template_name='hindex.html')),
)
1 голос
/ 24 марта 2009

Если вы хотите указывать разные имена шаблонов для разных представлений, то обычная практика заключается в передаче уникального словаря для каждого шаблона URL. Например:

urlpatterns = patterns('',
    url(r'^home/$', 'my.views.home', {'template_name': 'home.html'}, name='home'),
    url(r'^about/$', 'my.views.about', {'template_name': 'about.html'}, name='about'),
)

Этот тип паттерна распространен и приемлем.

0 голосов
/ 24 марта 2009

Вы можете определить функции представления-оболочки для параметризации общих представлений. В вашем urls.py добавьте шаблон

url(r'^/(?P<tmpl_name>\w+)/$', 'my.views.datebasedproxy')

в вашем views.py добавить функцию просмотра

def datebasedproxy(request, tmpl_name):
    return django.views.generic.date_based(request,otherparameters,
    template_name=tmpl_matrix[tmpl_name])

где tmpl_matrix - гипотетический список, который соответствует имени файла шаблона с параметром, а другие параметры - для других элементов словаря, необходимых для функции date_based

0 голосов
/ 24 марта 2009

Не так просто, но возможно полезно, если у вас есть множество различных шаблонов, соответствующих одному и тому же виду:

base_dict={
...
#defaults go here
}
def make_dict(template_name,template_object_name):
    base_dict.update({
        'template_name':template_name,
        'template_object_name':template_object_name,
    })
    return base_dict

urlpatterns += patterns('django.views.generic.date_based',
(r'^gindex/$', 'archive_index', make_dict('index1.html','latest_poll_list')),
(r'^hindex/$', 'archive_index', make_dict('index2.html','oldest_poll_list')),
)

Для многих похожих общих представлений это приведет к сжатию ваших кодовых вызовов за счет небольшой прозрачности. Если у вас много строк, настраивающих одни и те же параметры, это может быть проще всего прочитать.

Наконец, если все или большинство ваших представлений требуют некоторой, но не всей, одной и той же информации, никогда не забывайте, насколько полезен контекстный процессор . Для настройки требуется чуть больше работы, чем для вышеуказанных решений, но он расширяется гораздо лучше, поскольку он гарантирует, что (если вы не используете ярлык render_to_response без ключевого слова RequestContext) значения по умолчанию всегда будут доступны для вашего шаблона, независимо от того, ваш взгляд или изменение URL-адреса.

...