Разбиение родовых представлений на основе даты в Django

Question

У меня довольно простой вопрос. Я хочу сделать некоторые основанные на дате общие представления на сайте Django, но я также хочу разбить их на страницы. Согласно документации, представление object_list имеет аргументы page и paginate_by, а представление archive_month - нет. Какой «правильный» способ сделать это?

Answer 1

Я создал тег шаблона, чтобы сделать нумерацию страниц на основе шаблонов для коллекций, переданных шаблонам, которые еще не были разбиты на страницы. Скопируйте следующий код в файл app/templatetags/pagify.py.

from django.template import Library, Node, Variable
from django.core.paginator import Paginator
import settings

register = Library()

class PagifyNode(Node):
    def __init__(self, items, page_size, varname):
        self.items = Variable(items)
        self.page_size = int(page_size)
        self.varname = varname

    def render(self, context):
        pages = Paginator(self.items.resolve(context), self.page_size)
        request = context['request']
        page_num = int(request.GET.get('page', 1))

        context[self.varname] = pages.page(page_num)
        return ''

@register.tag
def pagify(parser, token):
    """
    Usage:

    {% pagify items by page_size as varname %}
    """

    bits = token.contents.split()
    if len(bits) != 6:
        raise TemplateSyntaxError, 'pagify tag takes exactly 5 arguments'
    if bits[2] != 'by':
        raise TemplateSyntaxError, 'second argument to pagify tag must be "by"'
    if bits[4] != 'as':
        raise TemplateSyntaxError, 'fourth argument to pagify tag must be "as"'
    return PagifyNode(bits[1], bits[3], bits[5])

Чтобы использовать его в шаблонах (предположим, мы перешли в список без разбивки на страницы под названием items ):

{% load pagify %}

{% pagify items by 20 as page %}
{% for item in page %}
    {{ item }}
{% endfor %}

Аргумент page_size (20) также может быть переменной. Тег автоматически определяет page=5 переменные в строке запроса. И если вам когда-либо понадобится попасть на страницу-указатель, принадлежащую странице (например, для подсчета страниц), вы можете просто позвонить:

{{ page.paginator.num_pages }}

Answer 2

Общие виды на основе даты не имеют нумерации страниц. Кажется, вы не можете добавить нумерацию страниц через их обертывание, так как они возвращают результат визуализации.

Я бы просто написал свое собственное мнение в этом случае. Вы также можете проверить код универсальных представлений, но в большинстве случаев он, вероятно, не понадобится.

Так как ваш вопрос правильный, и смотрим на код; Интересно, почему они не развязали генерацию набора запросов как отдельные функции. Тогда вы можете просто использовать их и отображать, как хотите.

Answer 3

Существует также отличное дополнение django-pagination , которое полностью не зависит от базового представления.

Answer 4

Я работал над проблемой, подобной этой вчера, и лично я нашел для себя лучшее решение - использовать универсальное представление object_list для всех страниц на основе даты, но передать отфильтрованный набор запросов следующим образом:

import datetime, time

def post_archive_month(request, year, month, page=0, template_name='post_archive_month.html', **kwargs):
    # Convert date to numeric format
    date = datetime.date(*time.strptime('%s-%s' % (year, month), '%Y-%b')[:3])
    return list_detail.object_list(
      request,
      queryset = Post.objects.filter(publish__year=date.year, publish__date.month).order_by('-publish',),
      paginate_by = 5,
      page = page,
      template_name = template_name,
      **kwargs)

Где urls.py читает что-то вроде:

url(r'^blog/(?P<year>\d{4})/(?P<month>\w{3})/$',
    view=path.to.generic_view,
    name='archive_month'),

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

Answer 5

Общие представления на основе даты в Django не поддерживают разбиение на страницы. На этот счет есть открытый билет с 2006 . Если вы хотите, вы можете попробовать исправления кода, предоставленные для реализации этой функции. Я не уверен, почему патчи еще не были применены к базе кода.