Class-based Views или Представления, основанные на классах в Django, часть 3

В рассмотрении Class-based views остался последний вопрос. Последний по порядку, а не по значению.

Этот вопрос — микс-ины (Mixins). Понятие это не столько связано с Django, сколько с Python в целом. Но в class-based views это настолько часто употребляется, что микс-ины проще рассматривать на них.

Для начала немного теории. У нас есть такой принцип ООП, как наследование, и дочерний класс наследует от родительского все свойства и методы. Должен ли родительский класс быть один? Должен. Но не всегда. Ряд языков, в том числе и Python, позволяют делать наследование от нескольких родительских классов. Тогда в дочернем классе как бы смешиваются (mix) родительские. Хорошо ли это? Отчасти да, когда такое множественное наследование необходимо реализовать. Отчасти нет, потому что смешение двух сложных полноценных родительских классов может выдать совершенно неожиданный результат.

Однако, чтобы воспользоваться преимуществами, программистами был придуман принцип микс-инов. В этом принципе базовый родительский класс (который сложный полноценный) всегда один, а остальные должны быть всего лишь примесями (mixin — примесь). Отличительная особенность микс-ина в том, что он должен быть как можно проще, чтобы затрагивать только необходимый минимум функциональности, иначе он может повредить логику базового класса. В целях эксперимента, попробуйте выполнить следующий код:

Читать далее…


Class-based Views или Представления, основанные на классах в Django, часть 2

Продолжим рассмотрение Class-based views, начатое в прошлой статье. И для начала опять общая информация.

Dispatch

Не только общая, но одна из ключевых. Важной особенностью Class-based views является то, что они могут определять метод HTTP-запроса и изменять поведение в зависимости от метода. Нет, конечно, мы сами тоже можем определить метод, но в Class-based это заложено в основную функциональность.
Как же это работает? При срабатывании представления (вызов as_view()) сначала вызывается метод dispatch(), который определяет, какой метод HTTP-запроса был получен, проверяет его на разрешенность, находит правильный обработчик и уже потом вызывает его.
Разрешенные методы хранятся в свойстве http_method_names. Это список по умолчанию содержит следующие значения:

Читать далее…


024 — Rigit Body, Симуляция физики в Blender

Давно я не записывал скринкастов, пора прервать эту «традицию».

На днях собрал демо-сцену симуляции физики в Blender:

и решил поделится основными понятиями из подобной физики.

К вашему вниманию разбор основ Rigid body. Если будет интересно, то продолжу записывать. В ригеде есть ещё интересные вещи.


Class-based Views или Представления, основанные на классах в Django, часть 1

DjangoВо многих обучающих материалах, в том числе в официальном туториале, представления организуются в виде методов внутри модуля views. Это достаточно удобный, понятный способ. На первых порах. В дальнейшем, когда такое представление начинает обрастать сложными условиями (разбором параметров запроса, выбором правильного макета, правильным подбором запроса), его становится все сложнее воспринимать. Более того, зачастую для разных представлений необходимо прописывать одни и те же условия. Из-за этого код растет, а объединять код через другие функции бывает не всегда удобно и красиво.

Для упрощения подобной задачи используются представления, основанные на классах. Изначально они создавались для упрощения процесса разработки (когда можно было одной строчкой создать и представление, и макет отображения). Но, начиная с версии 1.5, такие представления стали основным механизмом разработки, достаточно удобным и вовсю используемым как внутри самого Django, так и в большинстве сторонних приложений.

Читать далее…


Создание сайтов на Django, часть 7. Совершенствуем шаблоны.

Django

В прошлой статье создали нормальные url для нашего блока и прописали для них view. Теперь остался последний штрих — шаблоны.

Django имеет достаточно интересную систему шаблонов, которая даже вынесена в отдельный проект — Jinja. Даже отказываясь от джанги, от её шаблонов так просто отказаться не получается.

В основе шаблонов Django находятся тэги, которые размещаются в HTML-страницах. Далее страница «скармливается» методу render() (который мы использовали при создании view), выполняются инструкции, написанные в тэгах и отрендеренная страница возвращается в качестве ответа.

Тег внутри шаблона заключается в последовательность из фигурной скобки и знача процента — {% … %}. Существует другой, частный, но очень часто используемый, вид тэга — тэг вывода {{ … }} — в этот тэг передается не инструкция, а переменная для вывода.

Тэги позволяют применять конструкции for и if:
{% for entry in entries %} … {% endfor %}
и
{% if entry.has_comments %} … {% endif %}
Обратите внимание, что, в отличии от Python, в шаблонах необходимо указывать закрывающие тэги.

Для тэга вывода используется второе понятие языка шаблонов — фильтр. Указывается он как вертикальная черта после переменной для вывода и служит как-бы инструкцией для обработки переменной перед выводом. Например, {{ entry.title|upper }} превратит все буквы заголовка записи в заглавные. Фильтров может быть несколько, тогда каждый из них отделяется вертикальной чертой. Выполняются фильтры слева направо.

Напоследок следует сказать, что Django позволяет создавать свои собственные тэги и множество приложений этим пользуется. Обычно модули с тэгами располагаются внутри каталога templatetags внутри приложения.

Читать далее…


Игра pyDarts

Сегодня наконец-то опубликовал первую законченную версию игры pyDarts.

Это небольшая игрушка, сделанная на Python и PyGame, которая представляет из себя реализацию так называемых «пьяных дротиков», когда дротик как бы гуляет в руке и им нужно попасть в цель.

Вот пара скриншотов:

pyDarts-1

pyDarts-2

Зависимости игры — Python 2.7 и PyGame 1.9.

Саму игру можно скачать с GitHub, а также принять участие в её совершенствовании, так как исходники открыты.


Создание сайтов на Django, часть 6. Совершенствуем views и urls.

Django

В прошлой статье мы довели до ума админку и на этом закончили причесывание части, отвечающей за модель.

На этот раз мы серьезно возьмемся за часть, которая представляет из себя контроллер. И начнем с URL’ов.

Что же с ними не так? Прежде всего, хорошим тоном будет разбить URL’ы по приложениям. Тогда их будет и проще воспринимать, и менять. Как же это делается в Django? Для начала откройте файл urls.py в каталоге проекта.
У нас там должны быть прописаны URL админки и два URL’а для блога. Обратите внимание на то, как прописана админка. При помощи метода include в одну строчку включены все шаблоны из модуля django.contrib.admin.site.urls. Теперь, когда пользователь запрашивает URL, начинающийся с admin/, Django отсекает admin/ из запрашиваемой строки, а остаток передает в подключенный через include модуль. Этим мы и воспользуемся. Удалим шаблоны для блога и вместо них пропишем следующую строку:

    url(r'^blog/', include('blog.urls')),

Обратите внимание на знак $. Его там не должно быть, так как URL на этом не заканчивается, в отличии от предыдущих шаблонов, где он обязательно должен был присутствовать. Также обратите внимание, что include принимает в качестве параметра не только модуль (который обязательно должен быть импортирован), но и строку, которая указывает на модуль.

Теперь, когда мы обратились к blog.urls, нам необходимо его создать. Создадим внутри нашего блога файл urls.py и заполним его следующим содержимым:

from django.conf.urls import patterns, url

urlpatterns = patterns('',

    url(r'^$', 'blog.views.index'),
    url(r'^details/(?P<id>\d+)/$', 'blog.views.details'),

)

Читать далее…


Создание сайтов на Django, часть 5. Совершенствуем админку.

DjangoВ прошлой статье мы собирали модель для нашего блога. Теперь нам предстоит сделать хорошую админку для этой модели.

Как уже говорилось ранее, админка по существу является отдельным приложением. Но она стала уже настолько привычной, что выглядит как неотъемлемая часть Django.

Чтобы задействовать админку, мы добавляли её в INSTALLED_APPS, добавляли URL’ы админки в urls.py и регистрировали созданные нами модели в админке в модуле models.py. В urls.py есть вызов одного метода, с которым мы сейчас проведем небольшой эксперемент. Закомментируйте следующую строчку:

admin.autodiscover()

сохраните файл, запустите сервер разработки и зайдите в админку. Сколько моделей вы там увидите? Правильно, всего лишь две, которые создали мы. Остальные модели (пользователи, сайты, простые страницы и т.д.) отображаться не будут. Почему так произошло? Метод autodiscover создан для того, чтобы выносить настройку админки в отдельный модуль — admin.py. И во всех остальных приложениях этот модуль существует. Отключив метод, мы отключили исполнение admin.py и все остальные модели не зарегистрировались. А вот созданные нами зарегистрировались, потому что мы их зарегистрировали в модуле models.py, который по умолчанию выполняется при запуске сервера Django. Поэтому они и не пропали.

Однако с точки зрения красоты структуры, следует все-таки вынести настройку админки в отдельный модуль. Не забыв снова подключить autodiscover, создадим внутри каталога blog файл с именем admin.py, и перенесем туда последние три строчки из models.py. Метод register в качестве первого параметра принимает модель, которую необходимо зарегистрировать. Если в models.py эти модели существовали, то в admin.py их необходимо импортировать. Поэтому добавим туда импорт моделей. В итоге содержимое модуля admin.py будет следующим.

from django.contrib import admin
from blog.models import Category, BlogEntry

admin.site.register(Category)
admin.site.register(BlogEntry)

Теперь приступим непосредственно к улучшению админки. У метода register есть второй параметр — модель админки, класс, который описывает отображение и поведение модели в панели администратора. Если параметр не указывается, то по умолчанию подставляется класс django.contrib.admin.ModelAdmin. И чтобы получить более продвинутую админку, именно его мы и будем расширять.

Читать далее…


Создание сайтов на Django, часть 4. Совершенствуем модель.

DjangoВ прошлой части мы завершили первый этап создания своего собственного приложения для Django. На выходе мы получили простое приложения для ведения блога. При этом мы задействовали мизерную часть того, что на самом деле может Django.

Теперь мы начнем использовать Django более широко. И первое, за что мы возьмемся, это за улучшение нашей модели.

Вспомним, что мы раньше написали в модели:

class BlogEntry(models.Model):
    title = models.CharField(max_length=50)
    content = models.TextField()
    date = models.DateField()

У нашей модели всего три поля, что явно мало. Попробуем описать, какие именно поля нам понадобятся:

  • title — заголовок;
  • slug — сокращенный заголовок латиницей, который будет использоваться для создания человекопонятного URL;
  • tease — «дразнилка», вступление к статье, которое будет представляться в списке
  • статей;
  • body — непосредственно текст статьи;
  • draft — «черновик», признак того, что статья является черновой и её не нужно отображать;
  • created_at — дата создания статьи;
  • published_at — дата публикации статьи;
  • category — категория статьи.

Для создания полей разных типов у Django есть множество моделей полей, которые наследуются от модели django.db.models.Field. Любое поле заводится как свойство модели, и свойству присвается тот тип поля, который необходим. При этом в параметрах конструктора (в скобках) указываются дополнительные настройки и свойства этого поля. Подробно с типами полей можно ознакомится в руководстве https://docs.djangoproject.com/en/1.5/ref/models/fields/ (для версии 1.5, измените URL, если используете другую версию). Мы же остановимся на самых часто используемых.

Читать далее…


Создание сайтов на Django, часть 3. URL, View и Template

В прошлый раз мы рассмотрели паттерн MVC и познакомились, как реализовать первую букву из этого паттерна, а точнее модели, в Django. Теперь нам осталось создать представления для созданной нами модели и собрать это все через контроллер.
Начнем с обратного, сначала соберем контроллер.
Контроллер в Django состоит из двух составляющих — шаблона URL и обработчика View. Все шаблоны URL по идее должны находится в файле urls.py рядом с файлом настроек (обратите внимание на настройку ROOT_URLCONF в settings.py, которая в нашем случае равна ‘mydjangosite.urls’ — это и есть указатель на модуль, в котором описаны все URL сайта). В дальнейшем мы узнаем, что для удобства URLы хранят в папках приложений, а потом их подвязывают к главному файлу. Но для начала предположим, что URL хранятся только в этом файле. Откроем его.
Запомните синтексис описания шаблонов URL:

urlpatterns = patterns('', # База
    # Перечисление шаблонов URL,
)

его формат от приложения в приложению практичски не меняется. В начале перечисления нам любезно предоставили два примера описания шаблонов:

# Examples:
# url(r'^$', 'mydjangosite.views.home', name='home'),
# url(r'^mydjangosite/', include('mydjangosite.foo.urls')),

ими мы и воспользуемся. Добавим в конец перечисления следующие строки (да-да, сразу за раскомментированными URLами к админке):

url(r'^blog/$', 'blog.views.index'),
url(r'^blog/details/(?P<id>\d+)/$', 'blog.views.details'),

Для формирования каждого шаблона используется метод url модуля django.conf.urls, первым параметром которого передается сам шаблон ссылкы (в синтаксисе регулярных выражений), а вторым метод или полное имя метода (если нет желания делать импорт), который будет обрабатывать данный шаблон.
Для тех, кто не очень знаком с регулярными выражениями (советую все-таки познакомится — штука ОЧЕНЬ мощная), во второй строке шаблоном (?P\d+) мы объявили параметр с именем id и типом данных числовой переменной длины (d+). Этот параметр из шаблона будет передан в метод-обработчик.
Теперь мы должны создать два метода внутри модуля blog.views. Один будет называться index, обрабатывать случай, когда запрашивают полный список записей, и соответственно выводить этот список. Второй будет называться details, будет в качестве входного параметра получать id записи, и выводить эту запись.
Перейдем в папку нашего приложения и откроем файл views.py. Он пустой, но мы это исправим. Сначала опишем структуру модуля, добавив следующие строки:

def index(request):
    pass

def details(request, id):
    pass

Читать далее…


Отслеживать

Get every new post delivered to your Inbox.