О django CMS

Планировали тут для одного проекта поднять Drupal, потому как основная задача там - CMS. После чтения доков и исходников пришли к выводу, что даже руками на Джанго будет собрать сервер быстрее, плюс необходимые механизмы интеграции требуют достаточной гибкости. Готовые фичи "из коробки" - это, конечно, интересно, но хочется иметь возможность манёвра. Ну и примеры кода под друпал, в котором на прямую запросы к таблицам самого друпала делаются, как минимум, смутили. Хотя, безусловно, нехилое сообщество пользвателей и большое число инсталляций может является некоторым плюсом. Но по-моему гораздо удобнее пользоваться инструментом, для которого понимаешь, как он работает, и представляешь варианты того, что надо сделать для реализации нового функционала. Поэтому родилось по-моему логичное решение: в топку PHP.
Писать совсем с нуля CMS было бы несколько грустно, а для джанго они уже есть. Правда, не так чтоб их было огромное количество, да и по поводу распространённости/фичам ситуация не так чтоб совсем идеальная, но варианты имеются.
По следам статьи "Picking a Django powered CMS" в первую очередь взгляд упал на FeinCMS. Вещь в целом вроде неплохая, но всёже по принципу оно больше похоже на то, что называют (пхпшники в основном) CMF, т.е. компоненты надо ещё подгонять нужным образом, чтобы получить саму CMS. Плюс ещё вылез какое-то исключение при создании перевода страницы, причина которого сходу была неясна.
Это заставило всплыть в памяти мысли о django CMS. Поставил, настроил, "натянул" дизайн, посоздавал странички и контент для них и оно мне реально понравилось. Возможно пока я ещё не обнаружил проблемных мест, но на данный момент считаю django CMS довольно хорошим проектом, довольно гибким и удобным. Немного, правда, смущает число тикетов по системе, но реальных шоу-стопперов я не обнаружил.
Надеюсь, что за не очень большое время проект удастся довести до ума и заменить старую неуклюжую пхп-версию на джанговскую, которую можно будет легко и непринуждённо расширять и модифицировать, ну и, надеюсь, что django CMS в этом поможет.
P.S. Рекомендую ещё по этому поводу статью "Друпал или Джанго".

Очередная находка ньюба

Оказывается, что приложение Джанго не может совпадать по имени с именем проекта, причём проявилость это у меня довольно хитрым способом. Дело в том, что понадобилось мне забацать свой templatetag, создал приложение (с совпадающим именем), а Джанга ругается. Чуть потыркался, остановил девелоперский сервер, пытаюсь запустить runserver_plus из django-command-extensions, а оно мне отвечает: "Не, чувак, нет у тебя этих расширенных комманд, погляди в комманду хелп, убедись". Нормальный же runserver запускается и работает, только вот templatetag, конечно же не находит.
В целом, ещё один урок на тему, что с именами в Питоне надо быть чуть аккуратным.
P.S. И абсолютный импорт тут ничем не поможет.

И что они нашли в django-pagination?

Куча джангописателей (наприме, включая авторов Pinax) используют django-pagination, но по-моему товарищ Эрик выдаёт несколько кривой результат для большого числа страниц. Например страницы могут вылядеть следующим образом:
<<previous 1 2 ... 5 6 7 8 ... 20 21 next>>
Сразу обращает на себя асимметрия результата, плюс ещё в начале и в конце много страниц отображается.
По-моему гораздо симпатичней (и даже чуточку логичней) вариант
< Prev 1 ... 5 6 7 8 9 ... 21 Next >
вот отсюда.
P.S. А blogger ужасно хреново работает с угловыми скобками, сил нет.

Все аналогии ложны.

Размышляя над разницей между подходами и приёмами прниятыми на PHP и в python (в основном я рассматриваю Django, т.к. с другими фреймворками я не очень хорошо знаком), всё чаще в голову приходит аналогия с противопоставлением Windows и Linux. В PHP в основном всё уже готово "из коробки" и та же поддержка апачем особых плясок с конфигами не требует, тогда как с тем же Django приходится разобраться с процессом развёртывания, да и вариантов там сразу целая пачка (если не больше). Ну и самый большой аргумент, на мой взгляд, это модульность и гибкость, которая позволяет на линуксе, джанге достичь больших результатов, но в итоге требует больших усилий головного мозга (как говорят "если в линуксе можно настраивать программу, то вам, скорее всего, её придётся настраивать"). А модульность эта не может строиться без достаточной стройности идеологии и структуры системы (не могу не привести ссылку на свой прошлый пост про reusable apps).

Зависимости, зависимости...

У товарища тут вышла проблема с разворачиванием приложеньица на джанге. Вроде всё сделано нормально, но выдаёт, хоть ты тресни, ошибку импорта, аля "не могу импортировать 'test.settings'", но файл-то лежит рядом и из питона нормально импортируется. Битый час придумывал, откуда могут ноги у этой проблемы расти. Оказалось всё тривиально - в поставке питона идёт модуль test, поэтому возник конфликт пакетов.
Так что называйте папки (и пакеты) внятно!

Спасибо русским программистам!

Предыдущая война с mod_wsgi закончилась в итоге тем, что Apache был "спрятан" за проксирующий nginx, что решило проблему с "залипающими" запросами. Заодно и статике теперь должна оптимальней отдаваться.
Думал было использовать ещё Nginx upload module, написал даже нужный код (т.к. данные в итоге приходят немного иначе). Однако, по запарке забыл код обновить, а в результате обнаружилось, что оно и без этого замечательно работает. Поэтому оставил пока тот вариант "на всякий пожарный". Хотя толком не помешало бы тесты сделать, чтоб понять, даст ли оно какую-либо разницу.
В любом случае nginx рулит, спасибо Игорю Сысоеву.

WSGI...

Вот толи я неважный линуксовый админ, толи в связке CentOS+mod_wsgi что-то "нетак":
время от времени Apache "затыкается" и из внешних признаков обнаружились лишь записи с "Premature end of script headers:" для сайта на Django. Причём вчера такое поведение получилось повторить сделав touch одному из wsgi-скриптов, ошибки же повалились для другого сайта, откуда могут тут взяться "наведённые" проблемы совершенно непонятно.
Возможно, надо обновить mod_wsgi с 2.5 до 2.8, или вообще собрать по-нормальному другой сервер (и плюнуть на CentOS), но пока чуть поживём с непонятками.