Главная / Библиотека / Фреймворки / Django / Ваше первое Django-приложение, часть 1

Ваше первое Django-приложение, часть 1

Django
В статье "Writing your first Django app, part 1" автор показывает на примере, как можно создать своё приложение с помощью Django для тех, кто это делает впервые.

Статья частично адаптирована для использования на виртуальном хостинге КОМТЕТ. Предполагается, что вы используете своё окружение virtualenv, либо предустановленную версию фреймворка.

Давайте созданию Django-проекта учиться на примере

В данном руководстве мы научим вас создавать небольшое приложение для опросов.

Оно будет состоять из двух частей:

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

Предположим, что Django у вас уже установлен. Определить установлен ли у вас Django, можно запустив интерпретатор Python и набрав команду import django. Если она выполнена успешно и без ошибок, то Django  у вас установлен.

Где можно получить помощь

Если у вас возникли проблемы с использованием данного руководства, то отправьте сообщение в django-users или зайдите по ссылке #django on irc.freenode.net чтобы пообщаться с другими пользователями Django и получить от них помощь.

 

Создание проекта Django

Если Вы пользуетесь Django впервые, то вам следует сначала настроить его. А именно, вам необходимо автоматически сгенерировать код, который создаст Django-project - набор настроек для данного экземпляра Django, в том числе базы данных конфигурации, спец-настройки Django и спец-настройки приложения.

Из командной строки, перейдите в каталог, где Вы хотите хранить код, и затем выполните команду django-admin.py startproject mysite. Это создаст каталог mysite в текущем каталоге.

Права доступа Mac OS X

Если Вы используете Mac OS X, то при попытке запустить django-admin.py startproject. Вы можете увидеть сообщение "Доступ запрещен". Это возникает из-за того, что на таких Unix-системах, как OS X, файл должен быть помечен как "исполняемый" прежде чем его можно будет запускать как программу. Чтобы сделать это, откройте Terminal.app и перейдите (используя cd command) в каталог, куда установлен django-admin.py и запустите команду chmod +x django-admin.py.

Примечание: Вам не следует называть проекты такими же именами, что и встроенные компоненты Python и Django. Это означает, что вам следует избегать использования таких имен, как djangotest (иначе они будут конфликтовать с самим Django) или (которое конфликтует со встроенным пакетом Python).
 

django-admin.py должен быть в вашем системном пути, если Вы устанавливали Django через python setup.py. Если он не находится в вашем пути, то Вы можете найти его в site-packages/django/bin, где `site-packages` - это каталог в который был инсталлирован Python. Советуем установить ссылку  на django-admin.py откуда-нибудь из вашего пути, например, /usr/local/bin.

Где должен находиться код?

Если Вы программируете на PHP, то вероятнее всего Вы расположили код под корневым каталогом для документов вашего Web-сервера (в таком месте, как /var/www). Используя Django, Вы не должны так делать. Это не очень удачная идея размещать Python-код внутри каталога для документов вашего Web-сервера, потому, что люди могут просмотреть ваш код через Web. Это не хорошо с точки зрения безопасности.

Размещайте ваш код куда-нибудь вне корневого каталога для документов, как например в /home/mycode.

Давайте посмотрим на то, что создал startproject:

mysite/
    __init__.py
    manage.py
    settings.py
    urls.py

Это файлы:

  • __init__.py- пустой файл, который говорит Python, что этот каталог предназначен для Python-пакета. (Если Вы новичок в Python, то Вы можете узнать больше информации пакетах в официальных документах Python).
  • manage.py - утилита командной строки, которая позволяет вам взаимодействовать с этим проектом Django различными способами. Вы можете прочесть более детальную информацию о manage.py в django-admin.py и manage.py.
  • settings.py - файл настроек и конфигурации для этого проекта Django. Посмотреть то, как работают настройки можно здесь: Django settings.
  • urls.py- файл с описанием URL для данного проекта Django; "содержание" вашего Django-сайта. Вы можете узнать больше о URL в URL dispatcher.

Сервер разработки

Давайте проверим, что это работает. Перейдите в каталог mysite если Вы уже это не сделали, и запустите команду python manage.py runserver. Вы увидите следующий вывод в командной строке:

Validating models...
0 errors found.

Django version 1.0, using settings 'mysite.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

Вы запустили сервер разработки Django, легкий Web-сервер, написанный на Python. Мы включили его в Django, для того, чтобы Вы могли разрабатывать программы быстрее, без необходимости настраивать production server - такой как, например, Apache - до тех пор, пока Вы не будите готовы к созданию (production).

Замечание: не используйте этот сервер в production-среде. Он предназначен только для использования при разработке. (Мы создаем Web-фреймворки, а не Web-серверы).

Теперь, чтобы зайти на сервер, наберите в вашем Web-браузере следующий адрес: http://127.0.0.1:8000/ Вы увидите страницу "Добро пожаловать в Django", в приятном светло-голубом цвете. Это работает!

Смена порта Django

По умолчанию, сервер разработки запускается командой runserver с внутреннего IP-адреса на порту 8000.

Если Вы хотите сменить порт сервера, то запустите команду с указанием другого порта, например, эта команда запустит сервер на порту 8080:

python manage.py runserver 8080

Если Вы хотите сменить IP-сервер, то используйте следующую команду:

python manage.py runserver 0.0.0.0:8000

Полную информацию по серверу разработки можно посмотреть в runserver reference.

Настройка базы данных Django

Редактируем файл settings.py. Это нормальный Python-модуль с переменными уровня модуля, представляющими настройки Django. Измените эти настройки так, чтобы они соответствовали параметрам вашего соединения с базой данных:

  • DATABASE_ENGINE - либо 'postgresql_psycopg2', 'mysql' или 'sqlite3'. Другие бэкэнды также доступны.

  • DATABASE_NAME - название вашей базы данных. Если Вы используете SQLite, то базой данных будет файл на вашем компьютере; в этом случае, укажите абсолютный путь до этого файла. Если данный файл не существует, то он будет автоматически создан при первой синхронизации базы данных (см. ниже).

    При определении пути, всегда используйте наклонную черту, даже на Windows (например: C:/homes/user/mysite/sqlite3.db).

  • DATABASE_USER - имя пользователя базы данных (не используется для SQLite).

  • DATABASE_PASSWORD - пароль базы данных (не используется для SQLite).

  • DATABASE_HOST -местоположение вашей базы данных. Оставьте эту строку пустой, если ваш сервер базы данных находится на этой же физической машине (не используется для SQLite).

Если Вы новичок в базах данных, то мы рекомендуем вам просто использовать SQLite (придав DATABASE_ENGINE значение 'sqlite3'). SQLite включен как часть Python 2.5 и более поздних версий, поэтому вам не надо будет устанавливать что-либо ещё.

Примечание: Если Вы используете PostgreSQL или MySQL, удостоверьтесь, что Вы создали базу данных. Это можно сделать с помощью команды "CREATE DATABASE database_name;" в рамках интерактивной оболочки вашей базы данных.

А если Вы используете SQLite, то вам не надо будет ничего создавать заранее - файл базы данных будет создан автоматически, когда в этом будет необходимость.

Пока Вы редактируете settings.py, обратите внимание на параметр INSTALLED_APPS в конце файла. Эта переменная содержит имена всех приложений Django, которые активированы в этом экземпляре Django. Приложения могут быть использованы в разных проектах, и Вы можете паковать и распределять их для использования другими людьми в их проектах.

По умолчанию, INSTALLED_APPS содержит следующие приложения, и все они идут с Django:

Для удобства, все эти приложения включены по умолчанию.

Каждое из этих приложений использует не менее одной таблицы баз данных, поэтому мы должны сначала создать таблицы в базе данных, и только после этого использовать их. Чтобы это сделать, выполните следующую команду:

python manage.py syncdb

Команда syncdb смотрит на настройки  INSTALLED_APPS и создает любые необходимые таблицы баз данных, опираясь на настройки баз данных в файле settings.py. Вы увидите подтверждение каждой созданной таблицы баз данных и получите вопрос о том, хотите ли Вы создать учётную запись суперпользователя для системы аутентификации. Сделайте это.

Если вам интересно, запустите клиент командной строки для вашей базы данных и наберите \dt (PostgreSQL), SHOW TABLES; (MySQL), или .schema (SQLite) чтобы отобразить созданные таблицы Django.

Для минималистов

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

 

Создание моделей

Теперь, когда ваш "проект" настроен, Вы готовы приступить к работе.

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

Проекты vs приложения

В чём разница между проектом и приложением? Приложение является Web-приложением, которое что-то создаёт, например, Web-блог системы, базы данных государственного реестра или простое приложение опроса. Проект же представляет собой набор из конфигурации и приложений для конкретного Web-сайта. Проект может состоять из нескольких приложений. Приложение может быть в нескольких проектах.

В данном руководстве мы создадим приложение-опрос в каталоге mysite. Это приложение будет зашито в проект - т. е., Python-код будет находиться в рамках приложения-опроса и будет ссылаться к mysite.polls. Позже мы обсудим отделение ваших приложений для распространения.

Чтобы создать своё приложение, удостоверьтесь, что Вы находитесь в каталоге  mysite и затем наберите следующую команду:

python manage.py startapp polls

В результате этого создастся каталог polls, который будет выглядеть вот так:

polls/
    __init__.py
    models.py
    tests.py
    views.py

В этой структуре каталогов будет находиться и приложение опроса.

Первым шагом в написании базы данных Web-приложения в Django является определение моделей - по существу, база данных с дополнительными метаданными.

Философия

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

В нашем простом приложении опроса, мы создадим две модели: сами вопросы и варианты ответов. Опрос содержит один вопрос и дату публикации. Выбираемый ответ состоит из двух полей: текст выбираемых ответов и количество голосов. Каждый выбираемый ответ относится к одному опросу.

Эта концепция представлена простыми  Python-классами. Измените файл polls/models.py таким образом:

from django.db import models

class Poll(models.Model):
    question = models.CharField(max_length=200)
    pub_date = models.DateTimeField('date published')

class Choice(models.Model):
    poll = models.ForeignKey(Poll)
    choice = models.CharField(max_length=200)
    votes = models.IntegerField()

Код очень прост. Каждая модель представлена классом, который наследует django.db.models.Model. Каждая модель имеет ряд переменных класса, каждая из которых представляет собой поле в базе данных в модели.

Каждое поле представлено образцом Field-класса, например, CharField для текстовых полей, а DateTimeField для даты и времени. По этим полям Django определяет, какие данные находятся в каждом поле.

Название каждого поля (например question или pub_date) - это название поля, в подходящем для машин формате. Вы будете использовать это значение в вашем Python-коде, и ваша база данных будет использовать его в качестве названия колонки.

Вы можете использовать первый позиционный аргумент для Поля, чтобы назначить ему "человеко-читаемое" имя. Это используется в паре с интроспективными частями Django, и продублировано в документации. Если это поле не заполнено, то Django будет использовать машино-читаемое название. В следующем примере, мы назначили только человеко-читаемое  название для Poll.pub_date. Для всех других полей в этой модели будут использованы машино-читаемые названия.

Некоторые Field-классы требуют элементы. CharField, например, требует чтобы Вы назначили ему параметр max_length. Это используется не только в схеме баз данных, но и при проверке, что мы скоро увидим.

И наконец, обратите внимание, что отношения определяются с помощью ForeignKey. Это говорит Django, что каждый вариант ответа связан с одним Опросом. Django поддерживает все общие отношения в базе данных: многие-к-одним, многие-к-многим и один-к-одним.

 

Активация моделей

Этот небольшой код предоставляет Django много информации. С его помощью, Django способен:

  • Создать структуру баз данных (инструкции CREATE TABLE) для данного приложения.
  • Создать Python API для баз данных с целью доступа к объектам Poll и Choice.

Но сначала мы должны сообщить нашему проекту, что приложение polls уже установлено.

Философия

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

Измените снова файл settings.py и измените настройки INSTALLED_APPS добавив строку 'mysite.polls'. Она будет выглядеть следующим образом:

INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'mysite.polls'
)

Теперь Django знает, что mysite включает приложение polls Давайте выполним другую команду:

python manage.py sql polls

Вы должны увидеть что-то вроде этого (SQL-инструкции CREATE TABLE для приложения polls):

BEGIN;
CREATE TABLE "polls_poll" (
    "id" serial NOT NULL PRIMARY KEY,
    "question" varchar(200) NOT NULL,
    "pub_date" timestamp with time zone NOT NULL
);
CREATE TABLE "polls_choice" (
    "id" serial NOT NULL PRIMARY KEY,
    "poll_id" integer NOT NULL REFERENCES "polls_poll" ("id"),
    "choice" varchar(200) NOT NULL,
    "votes" integer NOT NULL
);
COMMIT;

Обратите внимание на следующее:

  • Точный вывод будет изменяться в зависимости от базы данных, которую Вы используете.
  • Имена таблиц генерируются автоматически, объединяя имя приложения (polls) и имя модели в нижнем регистре - poll и choice. (Вы можете их изменить).
  • Primary keys (IDs) добавляются автоматически. (Вы можете их также изменить).
  • соответствии с соглашением, Django добавляет "_id" к имени поля foreign key. (Да, и это тоже Вы можете изменить).
  • отношения задаются инструкцией REFERENCES.
  • зависимости от того, какая у вас база данных, автоматически используются такие типы полей, как auto_increment (MySQL), serial (PostgreSQL), или integer primary key (SQLite) Также происходит кватирование имен полей, например, использование одинарных, или двойных кавычек. Автор данного руководства использует PostgreSQL, поэтому примеры вывода написаны на синтаксисе PostgreSQL.
  • Команда sql фактически не выполняет SQL в вашей базе данных - она только печатает это на экран так, чтобы Вы могли видеть, какой по мнению Django требуется SQL. По вашему желанию Вы можете копировать и вставить этот SQL в вашу подсказку базы данных. Однако, как мы в ближайшее время увидим, Django предоставляет более простой способ передачи SQL в базу данных.

Если Вам интересно, то запустите следующие команды:

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

Теперь, запустите syncdb снова, чтобы создать эти таблицы моделей в своей базе данных:

python manage.py syncdb

Команда syncdb запускает sql из 'sqlall' в вашей базе данных для всех приложений в INSTALLED_APPS, который еще не существует в вашей базе данных. Это создаст все таблицы, начальные данные и индексы для любых приложений, которые Вы добавили к вашему проекту с последнего выполнения n syncdb. syncdb может быть вызван столько раз, сколько Вы хотите, и он будет создавать только те таблицы, которые ещё не существуют.

О том, что может выполнять утилита manage.py можно прочесть в django-admin.py documentation.

Игра с API

Теперь, давайте перейдём в интерактивную консоль Python и воспользуемся той свободой, которую даёт нам API Django. Чтобы вызвать консоль Python, используйте следующую команду:

python manage.py shell

Мы используем это вместо простого вызова "python", потому что manage.py устанавливает среду проекта для Вас. "Установка среды" - это:

  • Размещение mysite в sys.path. Для гибкости, некоторые части Django обращаются к проектам Python в "точечном стиле"  (например, 'mysite.polls.models'). IДля того чтобы это работало, пакет mysite должен находиться в sys.path.

    Один пример этого мы уже видели: Параметр INSTALLED_APPS является списком пакетов в "точечном стиле".

  • Установка переменной окружения DJANGO_SETTINGS_MODULE которая предоставляет Django путь к вашему файлу settings.py.

Обход manage.py

Если Вы не хотите использовать manage.py, то нет проблем. Просто удостоверьтесь, что mysite находится на корневом уровне на пути Python (т. е., import mysite работает) и установите переменную окружения DJANGO_SETTINGS_MODULE в mysite.settings.

Для более подробной информации смотри django-admin.py documentation.

Как только Вы будете в консоли, изучите database API:

>>> from mysite.polls.models import Poll, Choice # Import the model classes we just wrote.

# No polls are in the system yet.
>>> Poll.objects.all()
[]

# Create a new Poll.
>>> import datetime
>>> p = Poll(question="What's up?", pub_date=datetime.datetime.now())

# Save the object into the database. You have to call save() explicitly.
>>> p.save()

# Now it has an ID. Note that this might say "1L" instead of "1", depending
# on which database you're using. That's no biggie; it just means your
# database backend prefers to return integers as Python long integer
# objects.
>>> p.id
1

# Access database columns via Python attributes.
>>> p.question
"What's up?"
>>> p.pub_date
datetime.datetime(2007, 7, 15, 12, 00, 53)

# Change values by changing the attributes, then calling save().
>>> p.pub_date = datetime.datetime(2007, 4, 1, 0, 0)
>>> p.save()

# objects.all() displays all the polls in the database.
>>> Poll.objects.all()
[<Poll: Poll object>]

Подождите минуту. <Poll: Poll object> кажется выдает весьма бесполезное представление данного объекта. Давайте исправим это, отредактировав модель polls (в файле polls/models.py) и добавив метод __unicode__() и к Poll и к Choice:

class Poll(models.Model):
    # ...
    def __unicode__(self):
        return self.question

class Choice(models.Model):
    # ...
    def __unicode__(self):
        return self.choice

Если, вам кажется, что __unicode__() не работает.

Если Вы добавляете метод __unicode__() к своим моделям и не видите никакого изменения в том, как они представлены, то вероятнее всего Вы используете старую версию Django. (Данное руководство написано для последней версии Django). Если Вы используете последнюю версию Django (см. the installation docs), то у вас не должно быть никаких проблем.

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

Важно добавить метод __unicode__() к вашим моделям, не только для вашего собственного удобства при работе в интерактивной оболочке, но также, потому что представление объектов будет использовано в автоматически-генерируемых модулях административного интерфейса Django.

Почему __unicode__(), а не __str__()?

Если Вы знакомы с Python, то Вы, возможно, привыкли добавлять к вашим классам методы __str__(), а не __unicode__(). Мы используем здесь __unicode__() потому что модели Django по умолчанию работают с Unicode. Все данные, сохраненные в вашей базе данных, при получении конвертируются в Unicode.

Модели Django используют по умолчанию метод __str__() который вызывает __unicode__() и конвертирует результат в строку UTF-8. Это означает, что unicode(p) вернёт Unicode-строку, а str(p) вернёт нормальную строку с символами, закодированными как UTF-8.

Если всё это для вас непонятно, то просто не забывайте добавлять методы __unicode__() к вашим моделям. В любом случае всё должно работать.

Обратите внимание на следующие нормальные методы Python. Давайте добавим пользовательский метод, просто ради примера:

import datetime
# ...
class Poll(models.Model):
    # ...
    def was_published_today(self):
        return self.pub_date.date() == datetime.date.today()

Обратите внимание, что import datetime добавляется к стандартному модулю datetime.

Сохраните изменения, и снова запустите новую интерактивную консоль Python с помощью python manage.py shell:

>>> from mysite.polls.models import Poll, Choice

# Make sure our __unicode__() addition worked.
>>> Poll.objects.all()
[<Poll: What's up?>]

# Django provides a rich database lookup API that's entirely driven by
# keyword arguments.
>>> Poll.objects.filter(id=1)
[<Poll: What's up?>]
>>> Poll.objects.filter(question__startswith='What')
[<Poll: What's up?>]

# Get the poll whose year is 2007.
>>> Poll.objects.get(pub_date__year=2007)
<Poll: What's up?>

>>> Poll.objects.get(id=2)
Traceback (most recent call last):
    ...
DoesNotExist: Poll matching query does not exist.

# Lookup by a primary key is the most common case, so Django provides a
# shortcut for primary-key exact lookups.
# The following is identical to Poll.objects.get(id=1).
>>> Poll.objects.get(pk=1)
<Poll: What's up?>

# Make sure our custom method worked.
>>> p = Poll.objects.get(pk=1)
>>> p.was_published_today()
False

# Give the Poll a couple of Choices. The create call constructs a new
# choice object, does the INSERT statement, adds the choice to the set
# of available choices and returns the new Choice object. Django creates
# a set to hold the "other side" of a ForeignKey relation
# (e.g. a poll's choices) which can be accessed via the API.
>>> p = Poll.objects.get(pk=1)

# Display any choices from the related object set -- none so far.
>>> p.choice_set.all()
[]

# Create three choices.
>>> p.choice_set.create(choice='Not much', votes=0)
<Choice: Not much>
>>> p.choice_set.create(choice='The sky', votes=0)
<Choice: The sky>
>>> c = p.choice_set.create(choice='Just hacking again', votes=0)

# Choice objects have API access to their related Poll objects.
>>> c.poll
<Poll: What's up?>

# And vice versa: Poll objects get access to Choice objects.
>>> p.choice_set.all()
[<Choice: Not much>, <Choice: The sky>, <Choice: Just hacking again>]
>>> p.choice_set.count()
3

# The API automatically follows relationships as far as you need.
# Use double underscores to separate relationships.
# This works as many levels deep as you want; there's no limit.
# Find all Choices for any poll whose pub_date is in 2007.
>>> Choice.objects.filter(poll__pub_date__year=2007)
[<Choice: Not much>, <Choice: The sky>, <Choice: Just hacking again>]

# Let's delete one of the choices. Use delete() for that.
>>> c = p.choice_set.filter(choice__startswith='Just hacking')
>>> c.delete()

Более подробную информацию о моделях смотри здесь: Accessing related objects. Подробности работы с базами данных API можно найти здесь: Database API reference.

Примечание КОМТЕТ: для использования Django на хостинге КОМТЕТ рекомендуется ознакомиться со статьёй «Хостинг Django - способы установки».

 

Оригинал статьи на  www.docs.djangoproject.com

Перевод хостинг КОМТЕТ komtet.ru

Вам также может помочь