Архив за [undefined]

Кто был самый говорун на django-users в январе?

Не поверите, но я! Сам совсем недавно заметил, что иду в лидерах. Как-то само получилось. Специально для количества не писал. Всегда вроде по делу и много раз слышал "спасибо за совет". Приятно:) djangp-users

На джанго-конференцию в Екатеринбург увы попасть так и не смогу. Очень жаль, было бы интересно пообщаться с прославленными джангистами. Но надеюсь хоть на Exception выберусь или на РИТ. Там я думаю тоже нашего брата много будет:)

Джанго люди

Совсем недавно открылся проект http://djangopeople.net - сообщество джанго разработчиков. За короткий срок там уже зарегистрировалось больше тысячи двухсот джангистов по всему миру.

Конечно не обошли вниманием этот сервис и наши, отечественные, джангисты. Наша страна находится в середине таблицы по количеству джангистов, ближе к верху. Это очень отрадный факт. А если учесть, что ещё не все, наверно, про этот сайт знают, то есть шанс и повыше подняться. Так что бегите быстрее регистрируйтесь и отмечайтесь на карте всемирной "джанго-революции"!:)

Из российских городов в лидерах, как не сложно догадаться, Москва, где уже на карте восемь отметок. И я там с удивлением обнаружил коллегу, который живет практически на соседней улице! Александр Солоков - мой сосед по славному району Отрадное! Очень забавно - "джангисты ходят среди нас":)

Так что вот так, тематическая социальная сеть разработчиков на джанго - очень хорошая и перспективная идея.

Джангисты всех стран объединяйтесь!

Конфигурационные данные в шаблонах

Часто нужно в шаблоне вывести какой-то конфигурационный параметр. Нет, не тот который в settings.py, а тот который хранится в базе. Ну например префикс заголовка страниц, содержимое мета-тега в head или ещё какую-то информацию. Эти все данные(пары имя-значение) можно либо хранить в простой модели или взять что-то стороннее посерьезней, например dbsettings.

Для примера я возьму простую модель:

class Entry( models.Model ):
   name = models.CharField( max_length = 50, unique = True )
   value = models.CharField( max_length = 150 )

Здесь и далее буду писать упрощенный код

Всё, данные есть где хранить, но их ещё и нужно удобно вывести в шаблон. Первое что приходит в голову для решения - сделать шаблонный тег. Да, и вправду просто и сердито:

@register.simple_tag
def get_conf( name ):
    return Entry.objects.get( name = name )

И использовать легко, примерно так:

<meta name="keywords" content="{% get_conf "meta_keywords" %}"/>

Но у этого способа по сути одно маленькое положительное качество - в этот тег можно передать переменную, а не жестко закодированную строку("hardcoded" - правильно перевел?:)) с названием. Но для таких данных это не особый плюс, поскольку они очень специфичны и полиморфность имени не особа важна. Ещё конечно нужно отметить доступность значения тега в любом шаблоне, нужно только подключить соответствующую библиотеку тегов, где он лежит. Но это плюс можно ...

Индексирование. Проблемы выбора

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

В некоторые СУБД встроены механизмы полнотекстового индексировании, в другие нет. Но хочется иметь механизм универсальный и не зависящий от бекэнда хранения данных, ведь в конце концов информации может и не в базе вовсе храниться.

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

Вторая проблема выбрать реализацию для питона/джанги. Для джанги есть несколько сторонних приложений, которые позволяют использовать индексирование. Перечислю те, которые мне попались во время тематического поиска:

Последнее(на которое обратил моё внимание Lorien это не джанго приложение по сути, а фреймворк для индексирования, которые включает в себя бэкэнды разных движков в том числе и нативный питоновский для индексирония. Как я понял в процессе изучения, он как-то связан с джанговским бранчем индексирования. Но реализация пока простовата и я бы не рекомендовал его использовать.

Бранч TextIndexingAbstractionLayer, который в последствии, я надеюсь, будет самый лучший ...

Чуть более быстрое удаление объектов в админке

И опят речь пойдет об оптимизации, но оптимизации не программной части сайта, а работы человека с сайтом. Вас никогда не напрягало то, что в штатной джанговской админке для того чтобы удалить объект, нужно выбрать его из списка, потом прокрутить страницу внизу и нажать на кнопку "Удалить"?

Меня вот это раздражало, пока мне не пришла в голову простая идея. Надо кнопку удаления сделать в list view в каждой строчке.

Решение ещё проще чем идея.:) Вот пример:

class Entry( models.Model ):
    value = models.IntegerField()

    #начинается самое интересное. внимание
    def remove(self):
        from django.core.urlresolvers import reverse
        return '<a href="%s" class="deletelink">Delete</a>'\
                   % reverse( "django.contrib.admin.views.main.delete_stage",
                                        args=(self.__class__._meta.app_label,
                                             self.__class__.__name__.lower(),
                                             self._get_pk_val(),) )
    remove.allow_tags = True
    #интересное почти кончилось

    class Admin:
        list_display = ( "value", "remove" )

Вот такой результат:

delete buttons

Просто, не правда ли? Немного расскажу про код на всякий случай. Вся соль в возможности указывать в list_display не только реальные поля, но и методы модели. Так же эти методы можно помечать атрибутом allow_tags чтобы возвращаемое значение не эскейпилось автоматически. Метод сам по себе тривиален - возвращает тег-ссылки на страницу удаления. Ссылка получается через реверс с нужными параметрами.

Нужно всего-лишь добавить такой метод в модель и ...