http://github.com/robhudson/django-debug-toolbar/tree/master

Древовидные данные

Итак, есть модель:

class Category(models.Model):
    master = models.ForeignKey('self',related_name='translations',null=True,blank=True)
    title = models.CharField(max_length=250)
    parent = models.ForeignKey('self',blank=True,null=True)
    description = models.TextField()
    cdate = models.DateTimeField(auto_now_add=True)
    mdate = models.DateTimeField(auto_now=True)
    language = models.CharField(max_length=2, choices=settings.LANGUAGES)
    def __unicode__(self):
        return self.title

Как видно, поле parent позволяет указать родителя и таким образом создать вложения неограниченной глубины.

Теперь возникает вопрос - как в шаблоне организовать рекурсивный вывод данных. Я пропущу все прелюдии и ошибочные пути, которыми я шел, такие как get_levels_count(), get_level_n(n) и т.п. В конечном итоге нужную функциональность удалось организовать при помощи шаблонных тегов.

Шаблонный тег для рекурсивного вывода данных

Начнем писать свой тег.

1. В папке своего приложения создаем папку templatetags, в ней создаем пустой файл __init__.py и файл category_tree.py. В последнем собственно и будет наш тег.

2. В файл category_tree.py вписываем следующее:

from django import template
from shop.products.models import Category

register = template.Library()

@register.inclusion_tag('products/templatetags/category_tree.html')
def category_tree(context,category):
    children = Category.objects.filter(parent=category)
    return {'category': category, 'children' : children,}

3. В шаблон products/templatetags/category_tree.html пишем следующее:

{% load category_tree %}
<li>{{ category.title }}
<ul>
    {% for child in children %}
	<li>{% category_tree child %}</li>
    {% endfor %}
</ul>
</li>

4. Ну и наконец, в главный шаблон, в котором нужно вывести дерево:

{% load category_tree %}
    <ul>
    {% for category in categories %}
	<li>{% category_tree category %}</li>
    {% endfor %}
    </ul>

Собственно, это все. Виват, django!

ImproperlyConfigured: Error while importing URLconf 'django.contrib.admin.urls': No module named urls

Немного погуглив, решение было найдено. Как оказалось позже, это только начало...

Причины

Итак, причина этой ошибки, как и многих других - в trunk наконец-то влили бранч newforms-admin. Кроме того, попутно поменяли кучу всего нужного и полезного. Итак, решаем наши проблемы.

Ошибка при доступе к админ-части.

Связана с изменением синтаксиса URLconf. Если раньше у вас в конфиге было что-то вроде

from django.conf.urls.defaults import *
urlpatterns = patterns('',
    (r'^admin/', include('django.contrib.admin.urls')),
)

то теперь нужно сделать так:

from django.conf.urls.defaults import *
from django.contrib import admin

admin.autodiscover()

urlpatterns = patterns('',
    (r'^admin/(.*)', admin.site.root),
)

Управление моделями

Казалось бы, все пучком, админка ожила, но... В новооживленной админке не оказалось моих моделей. Опять же, гугл... И тут я нашел бесценную страницу (ссылка ниже) на которой было описание всех моих мытарств. В общем, новое изменение - теперь вместо

class MyModel(models.Model):
    first_name = models.CharField(max_length=30)
    last_name = models.CharField(max_length=30)
    slug = models.CharField(max_length=60, prepopulate_from=('first_name', 'last_name'))

    class Admin:
        pass

все, кому не чуждо django, пишут так:

class MyModel(models.Model):
    first_name = models.CharField(max_length=30)
    last_name = models.CharField(max_length=30)
    slug = models.CharField(max_length=60)

from django.contrib import admin

admin.site.register(MyModel)

В общем, вот так вот. Django - очень динамичный фреймворк. Быстро развивается, в связи с чем и случаются иногда некоторые сюрпризы. Впрочем, аргументов в пользу django и тут хватает. trunk он на то и trunk чтобы менятся. Стабильные версии стабильны Ну и разработчики честно предупредили о том, что всем будут ласты т.к. джанго растет и развивается. И, наконец, главный плюс в данных обстоятельствах - тот самый супердокумент.

Компоненты:

• собственно, Django (svn trunk)
• библиотека python-openid (я взял версию 2.2.1)
• apache, vim, mod_python 3.3.1

Путем предварительного гугления было найдено такое решение: DjangoID. Теоретически, это уже готовая реализация сервера и клиента. Но, насколько я понял, проект заброшен. Во всяком случае последним коммитам около двух лет. И потом, я хотел бы попробовать максимально "с ноля", чтобы разобраться что, почем, где и зачем. Поэтому использовать DjangoID не будем, будем пробовать сами (настолько сами, насколько получится).

Подготовка

Думаю, базовое окружение у вас уже готово и настроено. Т.е. Django работает. Проект, в который я буду всю эту петрушку интегрировать, называется labs. Так что будьте внимательны при копипасте Установим библиотеку python-openid, которая будет реализовывать основной функционал сервера (ну и клиента в дальнейшем). Я выбрал самый простой путь:

easy_install -v python-openid

Библиотека установлена. Едем дальше. Качаем себе дистрибутив библиотеки (ссылка выше). Зачем? Там папка есть полезная, examples. Она нам пригодится. Распаковываем. Находим папку examples. В ней лежит djopenid. Нам туда. Оппа - да тут же полноценный Django-проект. Хмм. Интересно. Можно попробовать запустить. Но я не стал. Мне проект не нужен. Я хочу приложение. Отдельное такое себе openidserver, чтобы интегрировать его в свой проект. Вопрос о рациональности пока отложим - может быть и стоит сделать отдельный проект, но я хочу приложение. Значится, копируем папку server в свой проект. Я сразу переименовал эту папку в openidserver, для наглядности. Файлик util.py из корня демор-проекта копируем в openidserver - не люблю мусора в корне проекта. Ну и не забываем про папку templates. Из библиотеки копируем в свой склад шаблонов. Опять же, я перенес всю петрушку в templates/openidserver/. Итак, структура проекта выглядит следующим образом:

labs
    -openidserver

        --models.py, views.py, urls.py, util.py, tests.py, __init__.py
    -templates
        -openidserver
            --index.html, xrds.xml
            -core
                 --endpoint.html,idPage.html,index.html,trust.html

Начинаем настройки:

Первым делом добавлем новое приложение в setting.py:

INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'labs.openidserver',
)

В корневой файл urls.py добавляем информацию про новые адреса:

  ('^server/', include('labs.openidserver.urls')),

Отрываем файл openidserver/ursl.py и редактируем: 'djopenid.server.views' -> 'labs.openidserver.views'.

Следующий файл, который необходимо отредактировать: openidserver/views.py. В нем нужно поменять названия модулей, из которых импортируются функции:

Было:

from djopenid import util
from djopenid.util import getViewURL

Стало:

from labs.openidserver import util
from labs.openidserver.util import getViewURL

Так, теперь теоретически можно пробовать. Пробуем открыть адрес http://domainname.com/server ...

Оппа. Неприятнейшая ошибка:

TypeError at /server/

unsupported operand type(s) for +: 'NoneType' and 'str'

Смотрим на источник ошибки: labs/openidserver/util.py in getViewURL, line 90

Видим такую вот неприятную функцию в файле util.py:

88 def getViewURL(req, view_name_or_obj, args=None, kwargs=None):
89     relative_url = reverseURL(view_name_or_obj, args=args, kwargs=kwargs)
90     full_path = req.META.get('SCRIPT_NAME', '') + relative_url
91     return urljoin(getBaseURL(req), full_path)

Понимаем, что проблема в  META['SCRIPT_NAME']. Гуглим. Находим вот такой вот тикет. Еще гуглим. Изучаем, откуда ноги растут у этого бага. Скорее всего, окуда-то из mod_python. Огорчаемся. Мысленно взываем к Ивану и просим его рассказать как это пофиксить. А пока Иван молчит, делаем такой вот грязный хак:

88 def getViewURL(req, view_name_or_obj, args=None, kwargs=None):
89     relative_url = reverseURL(view_name_or_obj, args=args, kwargs=kwargs)
90     full_path = 'http://domainname.com' + relative_url
91 #    full_path = req.META.get('SCRIPT_NAME', '') + relative_url
92     return urljoin(getBaseURL(req), full_path)

ВНИМАНИЕ: прошу в этом месте критиков задержать дыхание и не писать что это уродство потому что... Я до конца со всей этой кухней еще не разобрался, поэтому пока не знаю где это вылезет и не придумал как обойти. Конструктив приветствуется.

Так, редактируем, сохраняем, пробуем еще раз. Снова ошибка, но в этот раз уже проще:

TemplateDoesNotExist at /server/

server/index.html

Вспоминаем, что поменяли название папки с шаблонами. Надо править пути. Благо, файл и строка известны. Правим. Не забываем, что в некоторых файлах шаблонов есть блоки  {% extends "..." %}. Их правим тоже. Прим.: ниже ссылка на архив с уже отредактированными файлами, если лениво руками править.

Итак, пробуем еще раз. Ухты! Работает:

http://domainname.com/server/user/

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

Вводим адрес своего сервера, http://domainname.com/server/user, нажимаем Check и... о чудо: Associate (DH-SHA1 session) - Success!

Значит, все-таки что-то там завелось   В следующей части будем персонализировать наше детище.

А пока, для тех, кому лень редактировать файлы и править пути к шаблонам, архив с кодом приложения для простого OpenID сервера.