Один из самых часто задаваемых вопросов на форумах по Джанге -- как на одной странице выводить информацию из разных информационных блоков (пример такой ветки или вот совсем свежий). Давайте попробуем разобраться в стандартных способах решения данной задачи. Я специально не хочу рассматривать тут какие-то сторонние решения просто из-за того, что их много и они не интересны с точки зрения изучения классических методик применения возможностей Джанги.
Основной проблемой с которой сталкиваются вопрошающие -- как получить все нужны данные в одной вьюхе и зачастую из разных приложений. Это усугубляется тем, что у большинства в подсознании сидит необходимость разделения приложений на максимально независимые компоненты. И это правильное желание. Другое дело, что не надо этим принципом злоупотреблять. Если всё-таки ваши приложения нуждаются друг в друге достаточно сильно, то нет ничего плохого в том чтобы иметь в них перекрестные импорты и заимствовать функционал (в том числе по получению данных) так или иначе. Другое дело что таком случае стоит подумать о том, что возможно они настолько жестко связаны, что должны быть единым целым, т.е. одним приложением по сути. Но и даже в этом случае имеет смысл как-то чуть-чуть отделить общие данные от локальных.
Обычно исходной целью стремления получить данные из разных приложений являются всякие виджеты, информеры и ...
django-couchdb это ДБ бекэнд для Джанги с поддержкой CouchDB, разработанный командой 42cc.
Начиная новый проект, я очень рассчитывал на это решение, но увы оно совсем не оправдало надежд. Основная цель была, используя CouchDB не отказываться от стандартной джанговской админки и попробовать её заставить работать при помощи это бекэнда. Любовь к админке обусловлена тем, что она уже написана и её не надо изобретать с квадратными колесами нам самим, то что наши контент-менеджеры уже отчасти привыкли к ней и не хочется сбивать им workflow.
Авторы django-couchdb не скрывают что эта их реализация больше академическая и какого-то реального юзкейса у них не было. Что и проявилось в итоге.
Сразу надо сказать, что на данный момент основная гитхабовская ветка не работает с текущей Джангой и свежим CouchDB. Это связано с тем, что в Джанге в последнее время серьезно переработали внутренний API бекэндов баз дынных, а новый CouchDB чуть более строг с структуре документов чем раньше.
Но ладно, завести этот бекэнд вполне можно, что силами Кости Меренкова мы и сделали. Как и предполагалось, заработал базовый ORM, админка, а следовательно и приложения из contrib.
Пожив какое-то время с таким решением, мы поняли, что во многих местах для нашей задачи оно избыточно, а в других просто неудобно ...
По большому счету кроме urllib2 больше ничего и не надо. Но если хочется каких-то более удобных оберток над CouchDB REST API то есть из чего выбрать. Мне на глаза попадались три различные реализации и в начале разработки проекта пришлось потратить время на то чтобы выбрать подходящую.
Сразу оговорюсь, что все они очень похожи и делают одинаковые вещи - оборачивают в объекты основные сущности, которые предоставляет API -- сервер, база, документ и вьюха. Все совместимы с последним релизом самого CouchDB -- 0.10.
Первая из библиотек -- couchdb-python. Самая старая из появившихся. Можно сказать референсная реализаци. Имеет все полезные абстракции и даже чуть боьлше. Это "больше" заключается в возможности задать схему документа в декларативном Django-like стиле и реализация питонячьего view-сервера. Первое нужно чтобы как-то структурировать документы и работу с ними, а второе для того чтобы использовать python как язык для map/reduce обработчиков вместо штатного JavaScript. Умеет работать как с simplejson так и с быстрой cjson библиотекой. Так же хочет чтобы балы httplib2.
Следующий кандидат это couchdbkit. Умеет практически всё тоже самое, но имеет чуть больше хелперов и экстеншенов с адаптерами к популярными библиотекам вроде Django. Тянет за собой в зависимостях restkit (как видно из названия -- REST-клиент библиотека от того же автора) и умную библиотеку ...
Вы когда-нибудь задумывались каким таким магическим образом джанговская админка сияет своим синим стилем в только что созданном проекте? Ведь одна из самых больших проблем у новичков в Джанге - это наладить отдачу статики в проекте, но её даже не надо настраивать чтобы правильно заработала админка!
Это потрясающий маркетинговый ход - встроить глубоко во внутрь фреймворка костыль лишь для того, чтобы у человека, первый раз читающего и делающего туториал (или просто первый проект), уже на втором шаге случился культурный шок от админки, а точнее от её полу-магического появления и внешнего вида.
Есть устоявшееся мнение, что у Джанги реальные проблемы с PR'ом и продвижением в массы. Что мол не кричат разработчики и члены сообщества, что вот она какая крутая и что всем надо ею пользоваться. Так у нас свой путь - не надо бить во все колокола, а лишь в нужных местах сгладить углы и сделать вхождение новых людей плавным и беззаботным. Благими намерениями - дорога в ад!
Проза в том, что медиа админки в runserver хендлится специальной WSGI мидлвариной. Причем даже в основном хендлере есть проверка на наличие в урле префикса медии админки и подавлении нотификации о запросе в консоле - чтобы не пугало неподготовленное сознание!:-)
Всё это чревато, т.к. кто-то всё таки в ...
Недавний релиз Джанги 1.1 принес с собой новую фичу - пространства имен урлов. Цель они призваны достичь благую, но увы их механизм пока не очень прозрачен и понятен при первом приближении. Давайте разбираться.
Всё это родилось из идеи иметь несколько админок в одном проекте. И после рефакторинга админки под новые формы это стало возможным. Так же нужно было решить как разделять их урлы и главное как их реверсить по имени. Понятно, что в общем случае имена паттернов урлов разных админок будут пересекаться и однозначно преобразовать имя в урл невозможно. Тогда придумали каждому объекту SiteAdmin давать имя и это имя становилось частью названия паттерна урлов соответствующей админки. Ещё особенностью являлось то, что админка это объект и её урлы скрыты в атрибуте urls, что немного ломало классический способ инклюда урлов Джанги.
Что же сделали? Добавили разделение имен урлов. Причем разделенние на 2 уровня - уровень приложения и уровень инстанса приложения. Так что за приложения и что за инстансы?
Допустим у вас есть приложение foo, в котором присутствует какое-то количество урлов. Раньше хорошей практикой считалось урлы называть с префиксом имени приложения, например foo_index (или ещё каким-то уникальным идентификатором, что делала раньше админка (именем)). Теперь же. использую пространства имен, можно ограничится только index и указать ...