ну сейчас транк версия соответственно 20100130. а вот стабилные релизы это да… надо подумать. Думаю при возрасте 25 лет меня вряд ли назовёшь бетой… поэтому как минимум 1.х
да ничего для этого не делается… был один чел он сделал дифф который у него работает и сказал мол хотите юзайте, но всё это никак не входит в официальную джангу.
В теории да, обычно это реализуют через inclution tag, но он ведь не является у меня темплейт тэгом, поэтому зачем называть это template-tag если он таковым не является?
Генерики просто обрезают QS, они не помогают нарисовать сам пагинатор. В моём случае обрезает декоратор (обрезает причём встроенным в джанго Paginator, наверное им же пользуется и генерики), делает ещё пару нужных вещей такие как проверка что такая страница вообще существует, манипулирует данными из GET запроса, после этого передаёт все нужные данные в бекенд который занимается только тем как помочь НАРИСОВАТЬ пагинацию. Вот для этого и нужно это приложение, что бы можно было ещё и нарисовать пагинацию кроме того как обрезать qs.
Вот вариант digg пагинации стандартным способом, при этом у многих он не работает, довольно таки много кода и опять же подключать к конкретным вьюшкам не так просто, нужно менять urls.py, задавать настройки которые нельзя изменить на разных страницах, не сохраняются GET параметры и ещё много минусов. blog.localkinegrinds.com/2007/09/06/digg-style-pagination-in-django/
Не знаю в чём проблема у людей юзать render_to декоратор, по моему его и так около 80% рунетовских джангистов используют, byteflow его сильно популязировал.
Вообще попробуйте один раз подключить в своём сайте simplepagination и вы поймёте в чём его фишка… он чертовски прост.
Я попробую объяснить в двух словах как работает декоратор (как работает бэкенд я примерно объяснил в посте)
1. К нему попадет словарь который выходит из вьюшки, например это {'object_list': posts, 'something': 'anything'}
По дефолту ищется 'object_list', если передать в декоратор key=«another» то будет искать «another» и пытаться его делить на страницы, что в нашем случае выкинет эксепшн.
После этого создаётся стандартный джанговский объект Paginator, из которого достаются две вещи
а. Количество страниц
б. Все объекты которые должны быть на странице
Пункт «б» теперь подменяет наш object_list, в результате в шаблоне когда вы делаете {% for i in object_list %} вы итерируете уже по обрубленому списку.
На этом этапе все нужные данные о пагинации собраны и отдаются в бэкенд который возвращает словарь, его мы и вставляем в словарь который был во вьюшке. В резульате у нас вьюшка превращается в {'object_list': posts[only_pages:from_current_page], 'paginator': <dictionary_from_backend>}
Я как создатель аппы, не могу представить как первый пункт можно воплотить в жизнь. В принципе из всё что вы перечислили нужен только декоратор. Если у вас python 2.3 и нет поддержки декораторов то всё равно код либы не будет работать, там по моему пару вещей используются которые возможны только в 2.4 и выше.
Второй пункт более интересный, но опять же можно написать свой бэкенд, назвать его reversedigg и задать там любую логику, не обязательно хакать существующий.
Не буду вступать в ваш спор про MVC, но насчёт HttpRespnse хочу уточнить, что декоратор пагинации стоит под декоратором превращающий этот словарь в HttpResponse (render_to). Я декоратором render_to пользуюсь в любом случае, есть ли там пагинация или нет, с render_to_response нужно просто ещё всё время передавать ContextRequest(request) или что то типа этого, а это запаривает.
Это примерно так и работает, только вместо {% autopaginate something 10 %}, в шаблон попадает уже обрезаное количество something. А сколько показывать может быть указано в 4ёх местах.
1. settings.py проекта
2. переменная внутри класса бэкенда
3. параметер к декоратору
4. GET параметр
вместо {% paginate %} пишется
{% include paginator.template %}
Кстати вот то что получилось из того кода который я в посте дал, примерно пол часа ушло на всё про всё picbite.com/image/85193plfdy/ На сколько я смог протестировать это точная копия работы хабра пагинатора.
Не могу ничего по существу сказать, перечислю только достоинства simplepagination
1. Возможность использовать несколько видов пагинации в одном проекте (например список блогов выводится с пагинацией в стиле хабра, а список комментариев выводится в стиле digg)
2. Сохраняются все GET параметры (если у тебя урл выглядит example.com/?page=1&vasya=petya то ссылка на вторую страницу сохранит &vasya=petya)
3. Много всяких настроек, например разрешается менять количество отображаемых записей через GET параметры, по дефолту такие параметры принимаются в DEBUG моде.
Наверное ещё какие то есть вещи, я просто django-pagination толком не смотрел
На самом деле правильный путь выбрали для изучения языка… Тут и сами попрактикуетесь и люди заодно подскажут… лучше чем по книге просто тупой пример делать.
Заодно он может ставить дампы под вашем эккаунтом, автоматически распознаёт язык файла и может ещё чего умеет… щас уже не помню, писал пару месяцев назад…
Не знаю в чём проблема у людей юзать render_to декоратор, по моему его и так около 80% рунетовских джангистов используют, byteflow его сильно популязировал.
Вообще попробуйте один раз подключить в своём сайте simplepagination и вы поймёте в чём его фишка… он чертовски прост.
1. К нему попадет словарь который выходит из вьюшки, например это {'object_list': posts, 'something': 'anything'}
По дефолту ищется 'object_list', если передать в декоратор key=«another» то будет искать «another» и пытаться его делить на страницы, что в нашем случае выкинет эксепшн.
После этого создаётся стандартный джанговский объект Paginator, из которого достаются две вещи
а. Количество страниц
б. Все объекты которые должны быть на странице
Пункт «б» теперь подменяет наш object_list, в результате в шаблоне когда вы делаете {% for i in object_list %} вы итерируете уже по обрубленому списку.
На этом этапе все нужные данные о пагинации собраны и отдаются в бэкенд который возвращает словарь, его мы и вставляем в словарь который был во вьюшке. В резульате у нас вьюшка превращается в {'object_list': posts[only_pages:from_current_page], 'paginator': <dictionary_from_backend>}
Второй пункт более интересный, но опять же можно написать свой бэкенд, назвать его reversedigg и задать там любую логику, не обязательно хакать существующий.
1. settings.py проекта
2. переменная внутри класса бэкенда
3. параметер к декоратору
4. GET параметр
вместо {% paginate %} пишется
{% include paginator.template %}
В принципе в этом плане здесь то же самое.
1. Возможность использовать несколько видов пагинации в одном проекте (например список блогов выводится с пагинацией в стиле хабра, а список комментариев выводится в стиле digg)
2. Сохраняются все GET параметры (если у тебя урл выглядит example.com/?page=1&vasya=petya то ссылка на вторую страницу сохранит &vasya=petya)
3. Много всяких настроек, например разрешается менять количество отображаемых записей через GET параметры, по дефолту такие параметры принимаются в DEBUG моде.
Наверное ещё какие то есть вещи, я просто django-pagination толком не смотрел
Он может ставить как отдельные файлы, так и папки с файлами, создавать из них Bundle, при этом он архивирует файлы для экономии трафика.