livedev.org

ДА! Это наконец-то случилось! Иван может петь победоносную песню, он так долго боролся за решение этого вопроса!

By default, if an uploaded file is smaller than 2.5 megabytes, Django will hold the entire contents of the upload in memory. This means that saving the file involves only a read from memory and a write to disk and thus is very fast. However, if an uploaded file is too large, Django will write the uploaded file to a temporary file stored in your system’s temporary directory.

Полная дока по новому аплоаду — Django | File Uploads | Django Documentation.

Как я вчера обещал, начинаю активнее добавлять контент :-)

Третий выпуск «Линкотеки» посвящен картографии и Google maps в частности. К слову, тема вообще очень интересная и популярная. Я, честно говоря, недооценивал ее увлекательность и предлагаемые возможности, пока не столкнулся с ней в одном их своих новых проектов. В блогах все чаще можно услышать новомодную фразу гео-тегирование, а на разных социальных сервисах все чаще предлагают привязать какую-то виртуальную информацию к географическим координатам. Так что будте готовы наваять свой код, когда столкнетесь с необходимостью работать с гео-данными.

• Mapstraction — JavaScript библиотека для работы с многими картографическими сервисами через единый API.

• Modest Maps — Библиотека для работы с картографическими сервисами на ActionScript (v2 / v3) и Python.

• cfis — Блог Charlie Savage, разработчика GIS систем. Много информации общего характера для понимания тонкостей картографического софта, плюс примеры кода.

• Google maps. Snap to Polyline (example) — Пример JavaScript кода для привязки курсора к полигонам и полилиниям в Google maps.

• Google maps. Resizable Polygons (example) — Пример JavaScript кода для создания полигонов с возможностью ресайзинга в Google maps.

• Take Control of Your Maps — Отличный обзор картографического (GIS) софта для построения веб-приложений от «A List Apart».

• jMaps jQuery plugin — Плагин к jQuery для базовой работы с Google maps.

• GeoDjango — Отдельная ветка django, отлично заточенная на работу с гео-данными (GIS). Фич очень много, советую хотя бы ради интереса ознакомится. Главным я считаю полную интеграция с PostgreSQL PostGIS на уровне ORM.

• django-geo — В отличии от GeoDjango, облегченный вариант для интеграции гео-данных в ваш django-проект.

На этом, пожалуй остановлюсь. Если тема GIS и работы с гео-данными интересна, дайте знать. Если нет, то я не буду закидывать вас неинтересным контентом. Просто есть мысли в следующих постах привести некоторые куски кода по теме с объяснениями.

Сегодня важное событие у меня. Я наконец-то смог выродить подкаст о веб-разработке, который планировал оч давно записать. Даже не только планировал, но и пробывал. Итак, это моя третья попытка — более-менее удачная. Не могу сказать что я на 100% доволен результатом, но как говориться «первый блин можно и простить» :-)

Для меня намного важнее узнать ваше мнение, уважаемые читатели! На сколько вам был бы полезен вообще подкаст о веб-разработке. И о каких темах вы бы хотели услышать выпуски в будующем. Любые ваши комментарии (желательно конструктивные) будут мотивировать меня для дальнейшей записи. А так как я не диктор и не работал никогда на радио, дается мне сие записывание нелегко... Так что хотелось бы знать интересно ли будет что-то подобное для вас. Жду фидбека, а пока качайте 10 минутное mp3 весом в 14Мб :-)

Отдельный фид для подкаста скоро будет.

Update: сделал еще копию подкаста с битрейтом 128 на 10Мб

На днях нужно было за короткое время решить одну несложную и довольно типичную задачу на django — построение формы профайла пользователя. Я не стал искать в закладках ссылки на старые известные how-to от мэтров-джангистов :-), а попробовал посмотреть что же нового и интересного у нас имеется в последней версии django (trunk).

Итак, модель была приготовлена заранее, вопрос больше касался построения формы (через newforms) пользовательского профайла. Итак, модель.

class UserProfile(models.Model):
    user = models.ForeignKey(User, verbose_name=_('user'), unique=True, related_name="profile")
    country = models.ForeignKey(Country, verbose_name=_('country'), blank=True, null=True)
    city = models.CharField(verbose_name=_('city'), max_length=30, blank=True, null=True)
    post_zip = models.CharField(verbose_name=_('post zip'), max_length=10, blank=True)
    address = models.CharField(verbose_name=_('address'), max_length=250, blank=True)

Обратите внимание, что профайл ссылается на модель User с unique=True. Это в принципе самый простой и работающий вариант расширения модели пользователя в django. Можно смело использовать для объекта User метод profile.get(). Например:

from django.contrib.auth.models import User
u = User.objects.get(username='test')
profile = u.profile.get()

Теперь для моделей User и UserProfile необходимо построить единую форму. Для каждой отдельной модели сделать это не проблема. А вот сделать «два в одном» не так просто. Итак, по порядку:

1. Новенькое — широко используемые функции form_for_model и form_for_instance оказывается уже не актуальны. Они работают, но есть более новый и интересный метод получения формы для модели — ModelForm.

2. В отличии от форм полученных через form_for_model и form_for_instance, формы от ModelForm можно наследовать (а вот это очень интересно в нашем случае!!!).

Поэтому, как только эти два пункта появились в моей голове, я сразу же открыл Python-консоль и начал экспериментировать с кодом. Не уверен на 100%, что мое решение максимально красивое, но тем не менее оно вполне простое и аккуратное (особенно если учесть, что времени на «подумать» особо не было)...

Итак кусочек моего forms.py ниже.

from django.newforms.models import ModelForm
from django.contrib.auth.models import User
from django import newforms as forms

from profile.models import UserProfile

class ProfileForm(ModelForm):
    class Meta:
        model = UserProfile
        fields=('country', 'city', 'post_zip', 'address')

class ProfileFormFull(ProfileForm):
    def __init__(self, *args, **kwargs):
        super(ProfileFormFull, self).__init__(*args, **kwargs)
        self.fields['first_name'] = User._meta.get_field('first_name').formfield()
        self.fields['last_name'] = User._meta.get_field('last_name').formfield()

    def save_user_data(self):
        if self.instance:
            user = self.instance.user
            user.first_name = self.cleaned_data['first_name']
            user.last_name = self.cleaned_data['last_name']
            return user.save()
        else:
            raise instance.DoesNotExist

Теперь мои комментарии к коду (что я делаю):

• Создаю форму ProfileForm из моей модели UserProfile.
• Наследую от ProfileForm новую форму ProfileFormFull, которую буду расширять для возможности редактирования двух моделей (User и UserProfile) в одной форме.
• Суть расширения в добавлении двух полей из модели User (first_name и last_name) и метода save_user_data который эти поля сохраняет в модель User.
• Остальные поля из модели UserProfile обрабатываются автоматически созданным методом save.
• При сохранении формы нужно вызывать два метода — save и save_user_data. Я специально оставил эту возможность для моего случая. Но вы можете сделать сохранение save_user_data внутри save, расширив его.

Как выглядит код, который работает с этой формой:

@login_required
@render_to('profile/main.html')
def profile_save(request):
    if request.method == 'GET':
        return HttpResponseRedirect(reverse('profile.views.profile_page'))
    profile, created = UserProfile.objects.get_or_create(user=request.user)
    form = ProfileFormFull(data=request.POST, instance=profile)
    if form.is_valid():
        form.save()
        form.save_user_data()
        request.user.message_set.create(message="Your profile details saved.")
        return HttpResponseRedirect(reverse('profile.views.profile_page'))
    else:
        return {'profile': profile, 'profile_form': form, 'user': request.user}

На этом пожалуй откланиваюсь. Был бы очень рад любым конструктивным замечаниям и вопросам в комментариях. Хотелось бы унифицировать кусок кода с формой (forms.py) и может вынести в отдельный сниппет.

PS: обязательно почитайте документацию по ModelForm, интересно :-)

Наткнулся на интересную заметку. Как автоматизировать загрузку всех моделей из INSTALLED_APPS при запуске django python shell (manage.py shell).

from django.db.models.loading import get_models
for m in get_models():
    exec "from %s import %s" % (m.__module__, m.__name__)

Оказывается очень удобно! :-)

Оригинал — Peter Sheats’ Blog » Blog Archive » Autoloading Your Django Models

Решил сменить свою del.icio.us ленту в сайдбаре на более-менее регулярный постинг интересных ссылок.

А вот место в сайдбаре собираюсь заполнить блогроллом. Так что если хотите попасть в список — напишите мне на имейл или в комментарии свой сайт/блог. Добавляю на условии, что вы ставите на меня обратный линк.

Итак интересное, что я «нарыл» на просторах интернета за последние пару недель.

• StaticGenerator for Django — ссылка дня! очень полезный проект для django-разработчиков, может генерировать статический html вариант сайта из моделей, пользуясь методом get_absolute_url. Самое главное, что через сигналы он может автоматом обновлять html-страницы при изменении/добавлении объектов (т.е. буквально данных в базе).
• Evaluation of web based WYSIWYG-editors, test result 2007 — обзор онлайновых WYSIWYG редакторов (javascript и один на java), с него набрел на один интересный редактор (следующая ссылка).
• WYMeditor - web-based XHTML editor — простой интересный онлайн редактор, без возможности upload/insert images, но зато более семантичный и наглядный для тех, кто знает HTML.
• WYMstyle и css-boilerplate — css frameworks, хороши для веб проектов, когда у вас еще нет дизайна веб-сайта/веб-приложения, но вам нужно более-менее симпатично показать контент и функционал. Облегчают работу тем, кто не любит долгой возни с версткой.
• swfobject 2 — новая переработанная версия (на данный момент rc1) javascript библиотеки для включения в страницу flash/flex роликов или приложений. Кто еще не пробывал — советую, намного удобнее, чем писать кроссбраузерные теги и делать ручные проверки нужной версии flash. Еще можно почитать блог разработчиков — SWFFix Dev Blog.
• transdb — неплохая библиотека для локализации конента в django. Добавляет специальные многоязыковые текстовые поля в модель, что облегчает работу с базой и хорошо интегрируется с существующей системой i18n в django.
• PyAMF — Реализация на Python поддержки протокола обмена данными AMF (от Adobe) для клиент-серверного взаимодействия. Используется во flash и других проектах Adobe. Данные по этому протоколу передаются в бинарном виде, что более-продуктивно с точки зрения потребления траффика, автоматизирована сериализация/десериализация данных как на стороне сервера, так и клиента.

Хотел поделиться списком django-проектов, которые могут быть очень полезны при старте любого нового проекта. Чтобы, как говориться, «не изобретать велосипед».

Из того, что пробывал лично я, советую:

• sorl-thumbnail – для генерации thumbnail картинок для ImageField, очень удобно, может делать crop, изменение качества для jpg, подробнее смотрите на сайте проекта (все параметры задаются прямо через темплейттаг, так что верстальщики не будут задалбывать каждый раз когда нужно поменять размер картинки на фронтенде);
• django-registration – для автоматизации регистрации юзеров (проверка имейла итд), скорее всего будете затачивать под себя, так что годиться но с напильником;
• django-tagging – неплохая реализация тегирования для джанги, но требует доработки в плане оптимизации запросов к базе;
• django-template-utils – можно выцепить полезный код или использовать «как есть» при работе с темплейтами, полезные темплейттаги;

Из того, что не пробывал, но советую пробывать читателям:

• django-voting – система рейтинга для контента (работает для юбой модели);
• django-evolution – новый проект для тракинга изменений схемы базы (моделей); сам не тестил, но отзывы хорошие;
• django-atompub – для генерации atom-фидов (feeds), намного гибче стандартного джанговского, очень хорошие отзывы;
• django-rest-interface – для создания ReST API, возможно для работы с ajax;
• typogrify – для обработки вводимого/выводимого текста (правильные кавычки, тире итд); актуально только для англоязычных проектов, наша типографика отличается (читайте Лебедева);
• django-localdates – для корректной локализации дат; интересно как работает с русскими датами, кто может протестировать?

Отдельно. Готовые к бою приложения:

• ByteFlow – блогодвижок, разработка моего товарища, оч советую (есть скрипт миграции с wordpress).
• feedjack – приложение, feed агрегатор на джанге. Полезно для коммунити-сайтов.
• webthumb-api – генерация превьюшек реальных сайтов (передаешь ссылку получаешь картинку).
• django-diario – блогодвижок, не смотрел код, кто пробывал или попробует – напишите комментарий о своем впечатлении.
• django-photologue – фотогалерея, тоже сам не пробывал, но судя по описанию довольно «продвинутое» приложение (кто попробывал – отпишитесь).
• snapboard – готовый движок форума, опять же не пробывал, если есть впечатления – напишите.

Вот по следам недавних дискуссий в django-users пишу заметку как создавать имейлы с аттачами и html-ом.

Есть патчи в тикете #1541 для интеграции в саму джангу или можно воспользоваться примерами кода отсюда и отсюда.

Обновился vim-овский файл синтаксиса для django. смотреть на vim.org

• новую систему комментариев {# greeting #}
• улучшили подсветку ошибок, например {{ variable %} будет подсвечено как ошибка

В связи с появлением в trunk-ветке django такой прикольной библиотеки, как newforms, пришлось на нескольких проектах переползать на trunk. При этом все остальные должны стандартно работать на версии 0.95

В системе стоит как раз 0.95 (в site-packages). Проекты работают все на связке mod_python + apache. При настройке mod_python для django-проекта используется директива PythonPath. С её помощью к путям поиска python-модулей добавляется директория с проектом. Поэтому достаточно положить дистрибутив django в ту же директорию где лежит проект.

А вот для отладки приложения приходится немного пошаманить. Я так и не разобрался в чем причина, но когда запускаешь python shell (python manage.py shell) в любом случае в списке директорий с модулями site-packages оказываются первее чем то, что добавляешь в PythonPath переменную окружения. В итоге получается что используется версия django, котрая стоит в site-packages (т.е. 0.95).

Решается всё довольно просто, но дошел я до этого не сразу, т.к. боролся чтоб всё было кошерно :-) (через python manage.py shell). Сначала грешил на ipython, но без него была та же петрушка. Наковырявшись вдоволь я сделал потом всё по быстрому и просто.

1. PYTHONPATH=’path_to_Django_project‘
2. DJANGO_SETTINGS_MODULE=my_project.settings

После этого в любой директории набераете python или ipython и делаете импорты из моделей и работаете с ними.