Показаны сообщения с ярлыком django. Показать все сообщения
Показаны сообщения с ярлыком django. Показать все сообщения

воскресенье, 3 апреля 2011 г.

Затычки к django-multilingual-ng

Из всех "многоязычных" решений на Django самым внятным мне показался django-multilingual-ng, от авторов django CMS. Сама django CMS по смыслу не очень подошла для текущего проекта, поэтому было принято решение сделать своё решение, позаимствовав часть идей из django CMS.
То, что django-multilingual-ng написано под django CMS, к сожалению, дало неприятный косяк в том, что оно "из коробки" не другит с FeinCMS. Причём в тикете автор говорит - используйте лучше django CMS, что довольно странно, если мне нужен всего-лишь UI для редактирования mptt-деревьев.
Понадобилось тут ещё добавить некоторое удобство - чтоб в админке словарики (многоязычные) были по алфавиту отсортированы (в соответствии с текущим языком, конечно).
Поле ordering для ModelAdmin, естественно, не подходит, ибо переводы лежат в отдельной таблице и поля разные для разных языков получаются.
Поковырявшись в джанге получился вот примерно такой велосипедик:
class NameMultilingualAdmin(MultilingualModelAdmin):
    list_display = ('name',)

    @gll
    def get_changelist(self, request):
        field = 'name_%s' % GLL.language_code
        from django.contrib.admin.views.main import ChangeList
        
        class NameOrderedChangelist(ChangeList):
            def get_ordering(self):
                return (field, 'asc')

        return NameOrderedChangelist

воскресенье, 27 февраля 2011 г.

Unicode rulezz

Вроде всё-таки начал делать более-менее реальный проект на Django, поэтому появляются поводы писать сюда.
Потребовалась работа с файлами (плюс интеграция с tinyMCE), к сожалению, django-filebrowser тянет в зависимостях grappelli, который совсем вроде как не сдался (думаю admin_tools вполне хватит). Нашёлся форк с "отпиленными" grappelli и uploadify, но загвоздк оказалась в том что он хочет "буквы" в именах файлов, а русские буквы, конечно же, буквами не являются на его взгляд. Чтож, 5 минут и готов по-моему вполне рабочий форк.
Open source и github в частности, по-моему, довольно сильно меняют процесс разработки, причём в лучшую сторону. Обмен кодом/идеями - очень хорошая вещь.

среда, 25 августа 2010 г.

Об истории джанго

Для тех, кто не в курсе - откуда появился Django.

суббота, 17 апреля 2010 г.

По следам...

Вспомнил, что начинал читать Pro Django, и решил продолжить это дело. И почти сразу нашёл пояснение к предыдущей проблеме с переменными в блоках DTL: контекст, передаваемый в шаблоны организован в виде стэка.
Оказалось, что и в официальных джанговских доках это тоже описано.
P.S. В комментах и в своём блоге alerion дал решение в прошлый раз (но до его блога я не добрался, а приведённый вариант был не до конца понятен).

среда, 31 марта 2010 г.

Администрируемые настроечки и github

Понадобились тут для приложения настраиваемые настройки в админке (буквально потребовалось сделать редактируемыми адреса для отрпавки определённых формочек). Не желая изобретать свой велосипед, полез в гугл. Там обнаружил с ходу старенький django-dbsettings, который мне показался каким-то не кузявым: проект заброшен (хотя есть форки на github) да и с ходу не нашёл там группировки настроек (адреса и сабжи отличаются для разных форм). Следующим оказался совсем свежий django-appsettings. Вроде бы простое приложение, но я что-то 2 вечера разбирался в (ещё не очень знакомых мне) фокусах с метапрограммированием на python, которые там используются. Всему виной, по-моему, несколько противоречивое README к проекту. Ключевым вопросом стало то, что для подключения настроек для приложения необходимо, чтобы эти настройки были использованы в моделях приложения, т.е. в них должны присутствовать строки:

from appsettings import app
settings = app.settings.your_app

которые и вызывают соответствующий autodiscover().
С учётом этого всё стало довольно прозрачно и ясно и группировки вроде на месте, только вот в интерфейсе администрирования их не было у Джареда. Пришлось "форкнуть" проект и реализовать то, что необходимо.
Поставил в итоге ещё один плюсик гиту и понравился github. Правда в последнем обнаружилось пару багов: с коммитом, начинающимся с # он по ходу дела не дружит (в итоге пришлось делать merge из коммандной строки), да ещё на 1-м из флэшевых графов мой Firefox просто "схлопнулся". А в целом очень удобно - возьму себе на вооружение.
P.S. Ещё для настроек есть какое-то решение от авторов Satchmo, но смотреть его как-то было уже лень, когда было получено практически рабочее решение.

вторник, 23 марта 2010 г.

Работать надо меньше...

Минут пятнадцать сидел и "тупил" по поводу того, почему Джанго не хочет переводить строчку, когда локализация к ней написана и скомпилирована. Оказалось, что надо было просто лишь перегрузить девсервер.
Кстати, по поводу локализации: в грядущей версии 1.2 появится новый флажок с говорящим за себя названием - USE_L10N.

суббота, 20 марта 2010 г.

Разделяй и не властвуй?

Эксперименты показывают (в исходники самой Джанго пока не залезал толком), что Django Template Language имеет один не совсем неочевидный ньюанс: переменные, которые устанавливаются с помощью templatetag'ов в блоках, не "шарятся" между разными блоками. В итоге получается, что их надо устанавливать переменные заново в каждом из блоков, т.е. получаем как минимум лишний вызов, и возможно ещё и совершенно лишний запрос к базе.
Можно, конечно, результаты запроса кэшировать, если есть необходимось, но всё равно дублирование остаётся. С другой стороны, безусловно, установка переменных из шаблона не есть правильный подход, всё должно быть установлено по возможности на уровне view или в middleware. Но вот данные нужны на уровне именно самого шаблона, view находятся, в ныеншнем случае, в django CMS, а шаблоны могут туда передаваться разные, данные же эти нужны лишь в одном из них.
Получается или я что-то реально недопонимаю или всё выглядит немного некрасиво.

четверг, 11 марта 2010 г.

Советская власть и русификация всей страны

Обнаружил тут вдруг, что, несмотря на довольно хорошую поддержку интернационализации в Джанго, с локализацией не всё так тривиально, как хотелось бы. По сути надо было решить очень простую задачу - выводить локализованные имена месяцев в архиве новостей (хотя кто знает, что там дальше понадобится ещё). Есть, конечно, datetime.strftime, только вот он пляшет от текущей локали, которая задаётся на весь процесс и не управляется Джанго. В итоге поставил BabelDjango и использовал format_date(date, 'LLLL') оттуда.

пятница, 19 февраля 2010 г.

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

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

понедельник, 15 февраля 2010 г.

И что они нашли в 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 ужасно хреново работает с угловыми скобками, сил нет.

суббота, 13 февраля 2010 г.

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

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

среда, 6 января 2010 г.

WSGI...

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

вторник, 5 января 2010 г.

Django-chunks вроде бы совсем мелочь-мелочью, но для вставки всякой ерунды а-ля баннеры очень даже удобно.

понедельник, 14 декабря 2009 г.

Толи лыжи не едут...

urls.py и именованные ссылки это вроде бы хорошо, но вот никак немогу понять: разве нельзя в этих самых ссылках GET параметры как-то "прикрутить"?
Писать в шаблоне {% url my_link %}?param={{ template_param }} и "вручную" разбирать потом на стороне view-хи как-то кажется несколько заморочным.
А параметры в урлах временные, поэтому логичней иметь их явными параметрами, ну и AdSense не срабатывает там где нужно (наверное каждый раз пересобирает статистику для таргетинга?).

понедельник, 16 ноября 2009 г.

суббота, 10 октября 2009 г.

Красиво :)

Обновил django-debug-toolbar до версии 0.8 - вот это я понимаю красивый интерфейс :)

вторник, 8 сентября 2009 г.

Go shopping!!!

Поковырялся тут с пхпшным oscommerce, много плевался. Проект находится в "подвешенном" состоянии и, вместе с тем, много народу делает разные "доделки", местами противоречащие друг другу. В общем до модульности Django Apps далековато.
Ну, думаю, а гляну-ка Satchmo, вебшоп на Django. Но первые впечатления не очень обрадовали:
  1. Документация на сайте опирается на версию из HEAD репозитария, так что возникает вопрос со стабильностью.
  2. Установка тянет за собой кучу зависимостей, причём в рекомендациях easy_install и прямое создание ссылок в site-packages, а также выгрузка некоторых вещей также по HEAD из репозитариев (пусть и от участников проекта, насколько я понял)
  3. Урлы подключаются путём добавления магической строчки "from satchmo_store.urls import urlpatterns", т.е. ни о какой конфигурируемости речи не идёт.
  4. Многоязычность делается через какие-то "терни к звёздам", в файлах лежит папочка "ru" с переводом, но среди языков по "магическому" адресу /settings нет русского языка, а вот переключение на русский язык, несмотря на это работает. В переводах продуктов же список всех языков, доступных джанге.
В общем как-то всё грустно...

суббота, 22 августа 2009 г.

Толь лыжи не едут...

Понадобилось тут разобраться с интернационализацией в Django, в принципе, вроде всё понятно, но в одном месте вышел "затык". Создаю с помощи комманды файл django.po, компилирую в бинарный формат, запускаю сервер, а там ни намёка на перевод. Наверное не меньше получаса медитировал над документацией и гуглом. Оказалось, что создал я папку conf/locale, где ищется локализация самой джанги, а для других проектов нужна просто locale. Надо просто внимательней читать то, что пишут инструменты (в сообщении conf/locale была просто первой). Хотя такая неоднородность несколько контрастирует c остальными аспектами довольно последовательного Django.

среда, 15 июля 2009 г.

Дебажим джангу

Вроде начал толком писать приложение на Django и, естественно, понадобилось как-то отлаживать приложения. Довольно приятно был удивлён наличием удобных вещей по сравнению с PHP (или может я просто так плохо умею с ним обращаться?):
  1. bdp/ipdb позволяет ставить брейкпойнты в коде и делать пошаговую отладку, конечно, не Eclipse/Visual Studio, но вполне годно к использованию;
  2. django-debug-toolbar, о ней я уже писал, с тех пор там появилась ещё рубрика "сигналы";
  3. django-extensions в связке с werkzeug, про использование extensions для рисования диаграмм моделей я уже упоминал, но вот расширение страницы ошибки до того, что там становится доступна коммандная строка, меня сильно впечатлило.
Сухими словам или картинками объяснять получится не очень демоснтративно, поэтому рекомендую посмотреть неплохие касты от Eric Holscher тут и тут.
Оттуда же я узнал, что даже стандартная страница об ошибке Django информативнее, чем мне казалось (к примеру можно посмотреть участки кода и отправить стэктрейс на dpaste.com).
И ещё складывается такое впечатление, что на Django как-то больше думаешь о строении приложения с архитектурной точки зрения, т.е. как отдельные части взаимосвязаны и, возможно ли какое-нибудь переиспользование кода, а не с точки зрения "вот тут параметр А, надо отобразить табличку в Н строк". Хотя задачка не очень показательная, т.к. не из типовых для джанго, по-моему.

среда, 24 июня 2009 г.

Хороших книг должно быть много!

Джеймс Беннет выпустил второе издание своей книги "Practical Django Projects" (книга была дополнена и приведена к версии Django 1.1). Думаю, если не уйду из веба и таки начну толком переход наших проектов на Django, то надо будет купить электрическую версию.