Создание сайтов на 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.

Чтобы задействовать админку, мы добавляли её в 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 более широко. И первое, за что мы возьмемся, это за улучшение нашей модели.

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

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

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

Создание сайтов на Django, часть 2. MVT или MVC. Модели

В прошлой части мы запустили простой сайт на базе встроенных приложений. Однако Django можно расширять своими собственными приложениями. Более того, множество людей создают собcтвенные приложения, делают их более-менее универсальными и публикуют на специальных площадках. Примером такой площадки является сайт http://djangopackages.com.  Поэтому основным алгоритмом создания сайта на Django является:

  1. Найти необходимые приложения в сети;
  2. Доработать эти приложения, если они не достаточны;
  3. Создать свои приложения, если в сети ничего нет;
  4. Собрать все воедино.

Но мы начнем с конца. Будем учится собирать свои собственные приложения.

Для начала необходимо понять, что из себя представляет приложение. На самом деле оно может представлять все, что угодно, но в основном приложение содержит в себе какой-либо раздел сайта. Это может быть приложение вроде блога, новостей, каталога, опроса и т.п. Конечно, можно любой раздел можно разбить на несколько приложений, или наоборот несколько разделов объеденить в одном. Но чаще всего один раздел — одно приложение.

Приложение организуется по так называемому паттерну MVC. В Django этот паттерн называют MVT, но сути это не меняет. Что из себя представляет MVC: Модель (Model), Представление (View), Контроллер (Controller). Модель отвечает за работу с данными. Она взаимодействует с базой данных, проверяет данные на корректность, создает расчетные данные в случае необходимости. Представление отвечает за то, как эти данные будут выглядеть, придает им удобочитаемую форму. Контроллер является прослойкой между моделью, представлением и посетителем сайта. Когда посетитель сайта запрашивает страницу, этот запрос передается контроллеру. Он в свою очередь собирает все модели, которые могу пригодиться, и просит их предоставить данные. Потом контроллер выбирает представление, которое лучше всего отвечает запросу пользователя и передает ему данные. Сформированная страница (представление) передается как ответ на запрос.

В Django начинается небольшая путаница, поскольку в его терминах этот паттерн называется Model-View-Template (Модель-Представление-Шаблон). Однако View в Django скорее выполняет функцию контроллера, а Template — представления.

Хватит теории, перейдем к практике. Приложение flatpages выстроено по MVT. Моделью в этом случае является та самая таблица в базе данных, которая хранит содержание страниц. Контроллер был у нас один, он вызывался через middleware,  и по адресу определял, какую страницу нам отобразить. А вот шаблон-представление мы создали сами (defaulf.html, шаблон по умолчанию для flatpages, мы его могли переопределить для какой-нибудь из страниц, но не стали).

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

Создание сайтов на Django, часть 1

Я начинаю серию статей, посвященных разработке сайтов на Django. Вся информация, которая будет опубликована в этих статьях, собрана мной лично и на основе собственного опыта.

Для непосвященных, Django — это веб-фреймворк для создания сайтов, написанный на языке Python. Соответственно язык и является одним из основных его преимуществ, так как обеспечивает достаточно высокую производительность. На сегодняшний момент Django считается основным фреймворком Python для разработки веб-сайтов и веб-сервисов.

Для того, чтобы понимать все, что происходит в этой статье, необходимо знать основы ООП, более-менее знать Python и владеть основами работы с командной строкой (Windows или Linux, что больше нравится). В качестве дистрибутивов будут использованы Python 2.7, Django 1.5, и попеременно Ubuntu 13.10 и Windows 7. В целом информация будет применима для всех версий Django, начиная с 1.3.

Сначала нужно раздобыть дистрибутивы. Пользователи Linux могут их установить через менеджер пакетов (Django обычно называется python-django), пользователи Windows скачать Python отсюда и Django отсюда. При этом Python установится через инсталлер, а для Django придется использовать командную строку.
Распакуйте архив, перейдите в командной строке в папку с дистрибутивом и скомандуйте:

setup.py install

т.к. файлы с расширением *.py должны были зарегистрироваться при установке Python, Windows автоматически запустит найдет интерпретатор Python и запустит установку через него.

После того, как все дистрибутивы установлены, мы можем приступить к созданию нашего первого проекта на Django. Для этого существует специальная утилита django-admin.py. Для пользователей Linux она модет звучать как с расширением, так и без (зависит от дистрибутива) и скорее всего она уже зарегистрирована в PATH. Перейдите в
командной строке в каталог, где хотите создать проект и скомандуйте:

django-admin.py startproject mydjangosite

или какое-нибудь другое имя проекта, но помните, что имя должно соответствовать стандартам именования пакетов в Python, которые сходны со стандартами именования переменных.

Пользователей Windows ждет подвох, так как django-admin в PATH не зарегистрирован, и его придется запускать по полному пути. Если устанавливать все по стандартному, то он обычно располагается в папке C:\Python27\Scripts, поэтому скомандуйте:

C:\Python27\Scripts\django-admin.py startproject mydjangosite

Перейдите внутрь папки и ознакомьтесь с содержимым. Внутри неё должен лежать файл manage.py (который послужит нам заменой django-admin), и каталог с именем проекта. Будем называть текущую папку корневой и немного углубимся внутрь устройства этого фреймворка. Он состоит из ядра, вспомогательных библиотек и приложений (apps). При этом сам разработчик пишет преимущественно приложения. Все эти приложения по существу являются пакетами Python, имеют определенную структуру и обычно их размещают в корневой папке проекта (но необязательно). Сейчас у нас есть только одно приложение (скорее псевдо-приложение) — это непосредственно папка с проектом, в которой лежат файлы настроек. Лирическое отступление для обладателей Django 1.3: он каталог с проектом не создает, а помещает все настройки в корневой каталог.

Перейдем в каталог с настройками и увидим там 2 файла (вообще 3 и ещё __init__.py, но нам нужны будут 2) settings.py и urls.py. В settings.py хранятся все настройки. Откроем его (насчет открытия — можно открыть в “блокноте”, но это слишком. Для пользователей Linux рекомендую Geany или какой-нибудь другой текстовый редактор с подсветкой синтаксиса, у пользователей Windows в контекстном меню для файлов *.py должна была появится команда Open with IDLE — это специальный редактор для Python, нам его вполне хватит).

В файле мы увидим множество настроек по умолчанию (на самом деле настроек гораздо больше) но все сразу они пока что не нужны. Остановимся только на нескольких.
Сначала, для удобства, определим каталог, в котором располагается проект. Т. к. Django предпочитает работать с абсолютными путями, мы попытаемся этой “проблемы” избежать. Добавим в начало файла:

from os import path
PROJECT_DIR = path.abspath(path.dirname(__file__))

Далее создадим базу данных для нашего проекта. Django работает с множеством различных СУБД, но для простоты мы воспользуемся SQLite3. Найдем настройку DATABASES, подключим backend и пропишем путь к базе:

DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': path.join(PROJECT_DIR, 'db.sqlite'),

Обратите внимание на комментарий, что при использовании sqlite3 нет необходимости заполнять остальные поля. Поэтому мы их и не будем трогать.

Далее спустимся почти в самый низ файла и найдем настройку INSTALLED_APPS. Это как раз тот список приложений, которые подключены к проекту. Не стоит убирать ни одно из тех, что подлючены, но стоит подлючить новые. Для начала следует отметить, что вместе с Django поставляется ряд стандартных приложений, которые находятся в пакете django.contrib. В частности, там есть такой замечательный пакет, как django.contrib.admin, который любезно закомментирован в списке приложений (по-моему, в версии 1.6 уже нет). Он представляет из себя автоматическую админку сайта, которая очень сильно упрощает жизнь. И её надо раскомментировать.

Далее мы подключим еще одно приложение. Оно тоже штатное и называется django.contrib.flatpages. Оно служит для создания простых HTML-страниц, которые без обработки выводятся на сайт.

Итак, в конце переменной INSTALLED_APPS должны появиться два приложения:

INSTALLED_APPS = (
....
'django.contrib.admin',
'django.contrib.flatpages',
)

На этом начальная подготовка файла settings.py закончена. Теперь необходимо подготовить файл url.py. В дальнейшем в этом файле будут прописываться все URL, точнее их шаблоны, которые будет понимать Django. И к URL’ам в свою очередь будут подвязываться процедуры формирования ответа.

Раскомментируем в нем строчки:

from django.contrib import admin
admin.autodiscover()

и самый последний URL:

url(r'^admin/', include(admin.site.urls)),

Этими действиями мы подключили админку.

Прописав приложения в settings.py, мы только прописали приложения. Теперь нужно создать базу данных для этих приложений. Для этого в командной строке из корневой папки выполняем следующую команду:

manage.py syncdb

или

python manage.py syncdb

для Linux. В строке начнут появлятся сообщения о созданных таблицах базы данных. Также синхронизация попросит создать администратора сайта, отвечаем yes и вводим данные администратора.

После того, как синхронизация закончится, можно запускать так называемый сервер разработки. Вместе с Python поставляется элементарный веб-сервер, который можно активировать через Django, автоматически подвязав к нему текущий проект. Скомандуйте:

manage.py runserver

и появится сообщение о запущенном сервере. Останосить сервер можно командой Ctrl+C. Теперь можно открывать браузер.

По умолчанию сервер стартует по адресу 127.0.0.1:8000, и так как мы ещё не создали главной станицы, то сразу введем http://127.0.0.1:8000/admin/. В окне входа нужно ввести те данные, которые мы вводили при создании администратора. Перед нами предстанет список приложений. Пока что нам интересно только одно приложение — Flatpages.

Перейдем по ссылке в список страниц, нажмем Add flat page в правом углу чтобы создать новую. И заполним её так, как показано на рисунке:

1-1

и сохраним.

В поле URL указывается адрес, по которому страница будет доступна. Но если мы сейчас введем адрес http://127.0.0.1:8000/home/, то сервер ответит что страница не найдена. Нам необходимо сделать ещё несколько действий, чтобы такие страницы стали доступны.

Для начала небходимо создать шаблон страницы. Для этого внутри каталога проекта (не корневого, а того, что с settings.py) нужно создать каталог templates, внутри flatpages, и внутри файл с именем default.html со следующим содержанием:

<html><head><title>{{ flatpage.title }}</title></head><body>{{ flatpage.content }}</body></html>

Мы создали каталог шаблонов по умолчанию, теперь необходимо указать его в settings.py. Найдем настройку TEMPLATE_DIRS и пропишем там путь до каталога, относительный, по аналогии с базой данных:

TEMPLATE_DIRS = (
path.join(PROJECT_DIR, 'templates'),
)

И добавим еще одну строчку. Чтобы Django отлавливал все URL, которые присутствуют во Flatpages, необходимо подключить промежуточный обработчик (Middleware). Для этого в настройку MIDDLEWARE_CLASSES добавим следующий обработчик:

MIDDLEWARE_CLASSES = (
....
'django.contrib.flatpages.middleware.FlatpageFallbackMiddleware',
)

Сохраним settings.py. Перезапустим сервер (для надежности, обычно он перезапускается сам, вы при этом снова увидите в командной строке сообщение о старте сервера).
И введем в браузер http://127.0.0.1:8000/home/. Должна отобразиться созданная нами страница.

Если не отобразилась, ещё раз перепроверьте все шаги, которые необходимо было сделать.

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

Исходники на GitHub.

Несколько новых работ в Blender

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

Halloween

halloween_small

Последняя работа, навеяна наступившим праздником.

Полная картинка, Исходники

Chess

chess_small

Замучал эти шахматы, саму модель нарисовал очень давно, но только недели две назад подобрал более-менее нормальную композицию для них. Сделано на движке Cycles.

Полная картинка, Исходники

Еще несколько штук…

PinArt (Pin screen, Экспресс-скульптор)

Очередная работа. Так и не знаю, как её будет правильнее назвать по-русски. Если кому-то интересно — пишите, сделаю урок, как создавать такое чудо.

А если ещё интереснее, то вот исходники.

Отслеживать

Get every new post delivered to your Inbox.