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

Какой самый удобный способ организовать все эти каталоги на машине разработки? Как вы их называете, и как вы подключаете и развертываете это на сервере?

• проекты (все проекты, над которыми вы работаете)
• исходные файлы (само приложение)
• рабочая копия репозитория (я использую git)
• виртуальная среда (я предпочитаю разместить ее рядом с проектом)
• статический корень (для скомпилированных статических файлов)
• медиа-корень (для загруженных медиафайлов)
• README
• ЛИЦЕНЗИИ
• документы
• эскизы
• (пример проекта, который использует приложение, предоставленное этим проектом)
• (в случае использования sqlite)
• все, что вам обычно нужно для успешной работы над проектом

Проблемы, которые я хочу решить:

4 ответов

Есть два типа Django-проектов, которые у меня есть в моем каталоге ~/projects/ , оба имеют немного другую структуру.:

• Автономные сайты
• Подключаемые приложения

Автономный веб-сайт

Чаще всего частные проекты, но не обязательно. Обычно это выглядит так:

~/projects/project_name/ docs/ # documentation scripts/ manage.py # installed to PATH via setup.py project_name/ # project dir (the one which django-admin.py creates) apps/ # project-specific applications accounts/ # most frequent app, with custom user model __init__.py ... settings/ # settings for different environments, see below __init__.py production.py development.py ... __init__.py # contains project version urls.py wsgi.py static/ # site-specific static files templates/ # site-specific templates tests/ # site-specific tests (mostly in-browser ones) tmp/ # excluded from git setup.py requirements.txt requirements_dev.txt pytest.ini ...

Настройки

Основные настройки - производственные. Другие файлы (например, staging.py , development.py) просто импортирует все из production.py и переопределяет только необходимые переменные.

Для каждой среды существуют отдельные файлы настроек, например. производство, развитие. Я некоторые проекты, которые я тестировал (для тестировщика), (как проверка перед окончательным развертыванием) и heroku (для развертывания в heroku).

Требования

Я скорее задаю требования в setup.py напрямую. Только те, которые необходимы для среда разработки/тестирования У меня есть requirements_dev.txt .

Некоторые службы (например, heroku) требуют наличия requirements.txt в корневом каталоге.

setup.py

Полезно при развертывании проекта с помощью setuptools . Он добавляет manage.py в PATH , поэтому я могу запустить manage.py напрямую (в любом месте).

Приложения для конкретных проектов

Я использовал эти приложения в каталоге project_name/apps/ и импортировал их используя относительный импорт.

Шаблоны/статические/локальные/тестовые файлы

Я помещал эти шаблоны и статические файлы в глобальные шаблоны/статический каталог, а не внутри каждого приложения. Эти файлы обычно редактируются людьми, которым не нужен код проекта структуры или питона вообще. Если вы являетесь разработчиком полного стека, работающим в одиночку или в небольшой команде вы можете создавать шаблоны для каждого приложения/статический каталог. Это действительно просто вопрос вкуса.

То же самое относится к языку, хотя иногда удобно создавать отдельный каталог локалей.

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

каталог Tmp

В корне проекта есть временная директория, исключенная из VCS. Он имел обыкновение хранить медиа/статические файлы и базу данных sqlite во время разработки. Все в tmp может быть удален в любое время без каких-либо проблем.

Virtualenv

Я предпочитаю virtualenvwrapper и поместить все venvs в каталог ~/.venvs но вы можете разместить его внутри tmp/ , чтобы сохранить его вместе.

Шаблон проекта

Я создал шаблон проекта для этой установки, django-start-template

Развертывание

Развертывание этого проекта выполняется следующим образом:

Source $VENV/bin/activate export DJANGO_SETTINGS_MODULE=project_name.settings.production git pull pip install -r requirements.txt # Update database, static files, locales manage.py syncdb --noinput manage.py migrate manage.py collectstatic --noinput manage.py makemessages -a manage.py compilemessages # restart wsgi touch project_name/wsgi.py

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

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

Эскизы и черновики

Черновик шаблонов, которые я размещаю внутри глобального каталога templates/ . Я думаю, можно создать папку sketches/ в корне проекта, но еще не использовали ее.

Подключаемое приложение

Эти приложения обычно готовятся к публикации как открытые. Я привел пример ниже django-forme

~/projects/django-app/ docs/ app/ tests/ example_project/ LICENCE MANIFEST.in README.md setup.py pytest.ini tox.ini .travis.yml ...

Название каталогов понятно (надеюсь). Я помещал тестовые файлы вне каталога приложения, но это действительно неважно. Важно предоставить README и setup.py , поэтому пакет легко устанавливается через pip .

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

Проекты
У меня есть основная папка в моем личном каталоге, где я просматриваю все объекты, на которых я работаю.

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

Project_repository_folder/ .gitignore Makefile LICENSE.rst docs/ README.rst requirements.txt project_folder/ manage.py media/ app-1/ app-2/ ... app-n/ static/ templates/ project/ __init__.py settings/ __init__.py base.py dev.py local.py test.py production.py ulrs.py wsgi.py

Репозиторий
Git или Mercurial, по-видимому, являются самыми популярными системами управления версиями среди разработчиков Django. И самые популярные услуги хостинга для резервных копий GitHub и Bitbucket .

Виртуальная среда
Я использую virtualenv и virtualenvwrapper. После установки второго нужно настроить рабочий каталог. Mine находится в каталоге my/home/envs, так как это рекомендуется в руководстве по установке virtualenvwrapper. Но я не думаю, что самое главное, где оно размещено. Самое главное при работе с виртуальными средами - обновлять файл requirements.txt.

Pip freeze -l > requirements.txt

Статический корень
Папка проекта

Корень СМИ
Папка проекта

README
Корень репозитория

ЛИЦЕНЗИЯ
Корень репозитория

Документы
Корень репозитория. Эти пакеты python могут помочь вам упростить вашу документацию:

Эскизы

Примеры

База данных

Мне не нравится создавать новый каталог settings/ . Я просто добавляю файлы с именем settings_dev.py и settings_production.py , поэтому мне не нужно редактировать BASE_DIR . Приведенный ниже подход увеличивает структуру по умолчанию вместо изменения.

Mysite/ # Project conf/ locale/ en_US/ fr_FR/ it_IT/ mysite/ __init__.py settings.py settings_dev.py settings_production.py urls.py wsgi.py static/ admin/ css/ # Custom back end styles css/ # Project front end styles fonts/ images/ js/ sass/ staticfiles/ templates/ # Project templates includes/ footer.html header.html index.html myapp/ # Application core/ migrations/ __init__.py templates/ # Application templates myapp/ index.html static/ myapp/ js/ css/ images/ __init__.py admin.py apps.py forms.py models.py models_foo.py models_bar.py views.py templatetags/ # Application with custom context processors and template tags __init__.py context_processors.py templatetags/ __init__.py templatetag_extras.py gulpfile.js manage.py requirements.txt

pip install Django==2.1.7

Option 2: Get the release candidate for 2.2

pip install --pre django

Option 3: Get the latest development version

The latest and greatest Django version is the one that’s in our Git repository (our revision-control system). This is only for experienced users who want to try incoming changes and help identify bugs before an official release. Get it using this shell command, which requires Git :

git clone https://github.com/django/django.git

Additional information

For the impatient:

• Latest release:
  Checksums:
  Release notes:
• Preview release:
  Checksums:
  Release notes:

Which version is better?

We improve Django almost every day and are pretty good about keeping the code stable. Thus, using the latest development code is a safe and easy way to get access to new features as they’re added. If you choose to follow the development version, keep in mind that there will occasionally be backwards-incompatible changes. You’ll want to pay close attention to the commits by watching Django on GitHub or subscribing to django-updates .

If you’re just looking for a stable deployment target and don’t mind waiting for the next release, you’ll want to stick with the latest official release (which will always include detailed notes on any changes you’ll need to make while upgrading).

Previous releases

• Django 2.0.13:
  Checksums:
  Release notes:
• Django 1.11.20 (LTS):
  Checksums:
  Release notes:

Какая оптимальная структура для ваших Django приложений, настроек и других ассоциированных директорий?

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

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

Почему данная структура лучше

1. Позволяет вам держать, пересобирать и переисопльзовать индивидальные Django приложения для использования в других проектах. Ведь не всегда создаваемое приложение делается реиспользуемым, но в будущем, может вырасти в такое. Построение проекта описываемым способом, позволяет писать реиспользуемые приложения сразу же, а не только, когда потребуется.
2. Поощряет разработку реиспользуемых приложений
3. Индивидуальных настройки для каждого окружения. Никаких больше “if DEBUG ==True” в едином монолитном файле настроек. Это позволяет легко видеть, какие настройки общие и что переопределяется на каждом окружении.
4. Индивидульный список pip зависимостей для каждого окружения.
5. Шаблоны проекта и статические файлы, если требуется, могут переопределять значения по умолчанию уровня приложений.
6. Небольшие более детальные тестовые файлы, которые легче для чтения и понимания.

Предположим, у вас есть 2 приложения blog и users и 2 окружения dev и prod , значит, ваш проект должен иметь следующий вид:

myproject/ manage.py myproject/ __init__.py urls.py wsgi.py settings/ __init__.py base.py dev.py prod.py blog/ __init__.py models.py managers.py views.py urls.py templates/ blog/ base.html list.html detail.html static/ … tests/ __init__.py test_models.py test_managers.py test_views.py users/ __init__.py models.py views.py urls.py templates/ users/ base.html list.html detail.html static/ … tests/ __init__.py test_models.py test_views.py static/ css/ … js/ … templates/ base.html index.html requirements/ base.txt dev.txt test.txt prod.txt

Продолжение этой статьи расскажет, как привести свой проект к такой структуре и почему она лучше.

Текущая структура по умолчанию

Мы начнем с создания нового проекта с именем foo , да, я знаю, что это очень креативное название. Мы предполагаем здесь, что дальше проект будет расположен на домене foo.com , но почему название проекта должно точно повторять домен, ведь проект всеравно будет жить и без всяких подобных требований.

Если вы запустите свой проект с помощью команды django-admin.py startproject foo , вы получите следующую структуру:

foo/ manage.py foo/ __init__.py settings.py urls.py wsgi.py

Эта схема очень хороша для старта. У нас есть корневая директория foo , которая содержит наш manage.py и директорию проекта foo/foo . Эту директорию можно добавить в свою систему контроля версия, например в git.

Вы можете подумать, что директория foo/foo начало проекта, где все кроме этого это Django приложения или вспомогательные файлы относящиеся к проекту.

Исправляем настройки

Наша первая миссия, это исправить ваш плохой файл настроек. Мы показали данную архитектуру нашим клиентам и были впечатлены, как мало людей знают, что такое можно реализовать. Я виню в этом тот факт, что каждый знает, что файл настроек это просто Python код, но они не думают о нем, как о Python коде.

И так, давайте исправим наши настройки. Для нашего проекта foo реализуем схему с 4 окружениями: dev, stage, jenkins, и production. Давайте дадим каждому окружения свой собственный файл. Процесс для этого следующий:

1. В foo/foo создадим директорию settings и пустой файл __init__.py внутри нее.
2. Перенесем foo/foo/settings.py в foo/foo/settings/base.py
3. Создадим индивидуальные файлы dev.py , stage.py , jenkins.py , и production.py в foo/foo/settings/ . Каждый из этих файлов должен содержать следующее

from base import *

Так, почему это важно? Для локальной разработки вам требуется DEBUG =True , но вы также, можете случайно выкатить это и в продакшен, поэтому просто откройте foo/foo/settings/production.py и после первой строки импорта вставьте DEBUG =False . Теперь, ваш продакшен сайт защищен от такой случайности.

Что еще вы можете настроить? Достаточно очевидно, что для каждого окружения вы захотите иметь различные базы данных, например на разных хостах. Для этого, просто внесите эти настройки в соответствубщие файлы настроек.

Использование этих настроек

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

export DJANGO_SETTINGS_MODULE = “foo.settings.jenkins”

И бум, вы теперь используете jenkins настройки.

Или вы можете предпочесть передачу настроек через коммандную строку:

./manage.py migrate -settings= foo.settings.production

Или используя gunicorn:

gunicorn -w 4 -b 127.0.0.1:8001 -settings= foo.settings.dev

Что еще должно быть настроено?

Другая часто используемая уловка с Django настройками, это изменить тип некоторых настроек с tuple на list. Для примера, INSTALLED_APPS изменить с:

INSTALLED_APPS = ( … )

INSTALLED_APPS = [ … ]

В foo/settings/base.py мы теперь можем проще добавлять и удалять приложения основываясь на конкретном файле настроек для текущего окружения. Для примера, возможно вам требуется модуль django-debug-toolbar установленным только в dev окружении.

Этот трюк также часто используется с настройками TEMPLATE_DIRS и MIDDLEWARE_CLASSES .

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

PREREQ_APPS = [ ‘ django . contrib . auth ’ , ‘ django . contrib . contenttypes ’ , … ‘ debug_toolbar ’ , ‘ imagekit ’ , ‘ haystack ’ , ] PROJECT_APPS = [ ‘ homepage ’ , ‘ users ’ , ‘ blog ’ , ] INSTALLED_APPS = PREREQ_APPS + PROJECT_APPS

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

Исправляем зависимости

Большинство проектов содержат лишь один файл requirements.txt , который ставит зависимости примерно так:

pip install -r requirements.txt

Этого достаточно для маленьких проектов, но малоизвестная возможность requirements файлов это использование ключа -f для включения других файлов:

R base.txt pytest == 2.5.2 coverage == 3.7.1

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

Тестовые файлы

Почему мы разделяем тесты так сильно? Главная причина, если вы пишете достаточное количество тестов в одном файле tests.py для каждого приложения, то в конце концов он станет огромным и не поддерживаемым. Это плохо для читабельности, но также это простой факт, что вы тратите много времени на пролистывание текста.

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

Ссылки (URLs)

Для маленьких проектов заманчиво определять все ссылки в одном файле foo/urls.py для сохранения их в одном месте. Как бы то ни было, если ваша цель это ясность и реиспользование, вы должны определять ссылки в каждом приложении и загружать их в корневом файле. Вместо:

urlpatterns = patterns (‘’ , url (r ’ ^ $’ , HomePageView . as_view (), name = ‘ home ’ ), url (r ’ ^ blog / $’ , BlogList . as_view (), name = ‘ blog_list ’ ), url (r ’ ^ blog / (? P < pk > \d + ) / $’ , BlogDetail . as_view (), name = ‘ blog_detail ’ ), … url (r ’ ^ user / list / $’ , UserList . as_view (), name = ‘ user_list ’ ), url (r ’ ^ user / (? P < username > \w + ) / $’ , UserDetail . as_view (), name = ‘ user_detail ’ ), )

вы должны использовать:

urlpatterns = patterns (‘’ , url (r ’ ^ $’ , HomePageView . as_view (), name = ‘ home ’ ), url (r ’ ^ blog / ‘ , include (‘ blog . urls ’ )), url (r ’ ^ user / ‘ , include (‘ user . urls ’ )), )

Шаблоны и статические файлы

Использование templates/ и static/ директорий на каждое приложение дает способность к реиспользованию этого приложения в другом проекте как есть, без изменений.

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

Также, это дает нам возможность переопределить шаблоны на каждый проект базируясь на директории foo/templates/ . При добавлении шаблона templates/blog/detail.html мы перезаписываем или скрываем шаблон по умолчанию blog/templates/blog/detail.html .

Переиспользование Django приложений

Допустим, вы используете предлагаемую структуру проекта некоторое время, однажды, вы поймете, что ваш новый проект нуждается в блоге и один из ваших проектов прекрасно к этому подходит. Вы скопируете файлы в … НЕ ПРАВИЛЬНО! Теперь вы имеете две копии приложения. Исправления ошибок или новые функции в одном, будут вручную переноситься между проектами если предположить, что вы всегда помните про это.

Вместо этого, сделайте новый репозиторий для вашего блога и вставьте в него директорию foo/blog/ . И настройте, чтобы ваш существующий проект foo и новый проект, для установки блога через pip.

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

Дополнительные ресурсы

Наши друзья Дэнни и Аудрей из CartWheel Web напомнили нам про Cookie Cutter и специальный cookiecutter-django от Дэнни, мощная утилита для создания начального проекта, быстро и повторяемо.

Кроме того, если вы ищете все про Django уловки и рекомендации, вы не можете пройти мимо книги Two Scoops of Django: Best Practices For Django 1.6 которую мы рекомендуем всем нашим клиентам.

Обратная связь

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

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

Мы создадим веб-приложение, у которого будет панель администратора и возможность загружать загадки, а у пользователей, соответственно, возможность отвечать на них. Во время разработки будут использоваться Python 3.4.3 и Django 1.9.1.

Устанавливаем Django

Делается это очень просто, в командной строке нужно написать: pip install Django==1.9.1 .

Создаем проект

Если вы правильно установили Django, то после запуска django-admin --version вы увидите текущую версию фреймворка. Теперь создадим проект. Это можно сделать следующим образом: django-admin startproject django_example .

Как только создание проекта будет завершено, взглянем на директорию нашего проекта:

• django_example/__init__.py - пустой файл, который говорит Python, что данная директория должна восприниматься в качестве пакета.
• django_example/settings.py содержит конфигурацию нашего проекта.
• django_example/urls.py - здесь объявляются URL.
• django_example/wsgi.py - с помощью него приложение может работать с веб-сервером по протоколу WSGI.
• manage.py позволяет взаимодействовать с проектом.

Теперь пришло время запустить наше приложение. Для этого в командной строке нужно написать python manage.py runserver . После этого в адресной строке браузера нужно написать: http://127.0.0.1:8000/ . Если вы увидели «You have unapplied migrations; your app may not work properly until they are applied.», то не волнуйтесь, мы вернемся к этому чуть позже.

Создаем приложение

Определим различие между проектом и приложением. Приложение - это программа, которая что-то делает, а проект - это группа приложений.

Итак, приступим к созданию приложения. Это делается следующим образом: python manage.py startapp riddles .
Как только приложение создано, давайте напишем простой вид, по правилам Django все виды должны храниться в файле views.py .

riddles/views.py

From django.http import HttpResponse def index(request): return HttpResponse("Hello, World!")

Теперь, чтобы привязать наш вид к URL, создадим файл urls.py .

riddles/urls.py

From django.conf.urls import url from . import views app_name = "riddles" urlpatterns = [ url(r"^$", views.index, name="index"), ]

В urls.py мы должны написать следующее:

django_example/urls.py

From django.conf.urls import include, url from django.contrib import admin urlpatterns = [ url(r"^riddles/", include("riddles.urls")), url(r"^admin/", admin.site.urls), ]

Теперь, если мы запустим наше приложение http://127.0.0.1:8000/riddles/ , мы увидим «Hello, World!».

Установка базы данных

По умолчанию в Django используется SQLite, если она вас не устраивает, то вы с нашей статьей, в которой мы рассказываем, как безболезненно перейти с SQLite на MySQL.

Теперь откроем django_example/settings.py и взглянем на переменную INSTALLED_APPS , она хранит все приложения, которые активны в текущем проекте. По умолчанию она содержит:

• django.contrib.admin - админка, скоро мы ей воспользуемся.
• django.contrib.auth - система аутентификации.
• django.contrib.contenttypes - фреймворк для content types.
• django.contrib.sessions - сессионный фреймворк.
• django.contrib.messages - фреймворк для отправки сообщений.
• django.contrib.staticfiles - фреймворк для работы со статичными файлами.

Некоторые из этих приложений используют базы данных, но они еще не установлены, поэтому мы и видели «You have unapplied migrations; your app may not work properly until they are applied.». Поправить это можно следующим образом: python manage.py migrate . Вы должны увидеть следующее:

Operations to perform: Apply all migrations: admin, sessions, auth, contenttypes Running migrations: Rendering model states... DONE Applying contenttypes.0001_initial... OK Applying auth.0001_initial... OK Applying admin.0001_initial... OK Applying admin.0002_logentry_remove_auto_add... OK Applying contenttypes.0002_remove_content_type_name... OK Applying auth.0002_alter_permission_name_max_length... OK Applying auth.0003_alter_user_email_max_length... OK Applying auth.0004_alter_user_username_opts... OK Applying auth.0005_alter_user_last_login_null... OK Applying auth.0006_require_contenttypes_0002... OK Applying auth.0007_alter_validators_add_error_messages... OK Applying sessions.0001_initial... OK

Теперь создадим нашу модель. Для начала создадим Riddle и Option . В Riddle будет содержаться загадка, в Option - один из возможных ответов на нее.

riddles/models.py

From django.db import models class Riddle(models.Model): riddle_text = models.CharField(max_length=255) pub_date = models.DateTimeField("date published") class Option(models.Model): riddle = models.ForeignKey(Riddle, on_delete=models.CASCADE) text = models.CharField(max_length=255) correct = models.BooleanField(default=False)

Данная модель обеспечивает Django информацией, необходимой для создания схемы базы данных и database-access API для доступа к объектам. Теперь нам нужно привязать наше приложение к нашему проекту, делается это следующим образом:

django_example/settings.py

INSTALLED_APPS = [ "riddles.apps.RiddlesConfig", "django.contrib.admin", "django.contrib.auth", "django.contrib.contenttypes", "django.contrib.sessions", "django.contrib.messages", "django.contrib.staticfiles", ]

После этого нужно сделать миграцию: python manage.py makemigrations riddles . Вы должны увидеть следующее:

Migrations for "riddles": 0001_initial.py: - Create model Option - Create model Riddle - Add field riddle to option

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

Проверить, что сделает миграция, можно так: python manage.py sqlmigrate riddles 0001 (0001 - версия миграции, которую мы хотим проверить). На выходе мы получим:

BEGIN; -- -- Create model Option -- CREATE TABLE "riddles_option" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "text" varchar(255) NOT NULL, "correct" bool NOT NULL); -- -- Create model Riddle -- CREATE TABLE "riddles_riddle" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "riddle_text" varchar(255) NOT NULL, "pub_date" datetime NOT NULL); -- -- Add field riddle to option -- ALTER TABLE "riddles_option" RENAME TO "riddles_option__old"; CREATE TABLE "riddles_option" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "text" varchar(255) NOT NULL, "correct" bool NOT NULL, "riddle_id" integer NOT NULL REFERENCES "riddles_riddle" ("id")); INSERT INTO "riddles_option" ("riddle_id", "id", "text", "correct") SELECT NULL, "id", "text", "correct" FROM "riddles_option__old"; DROP TABLE "riddles_option__old"; CREATE INDEX "riddles_option_a7c97949" ON "riddles_option" ("riddle_id"); COMMIT;

Заметьте, что команда sqlmigrate нужна только для проверки, каждый раз ее запускать необязательно.

Теперь мы можем начать пользоваться панелью администратора. Но для этого нам нужен пользователь. Создать его можно следующим образом: python manage.py createsuperuser . После этого запускаем сервер, если он не запущен, и переходим на http://127.0.0.1:8000/admin/ . Вы увидите следующее:

Теперь дадим админу возможность изменять наши модели. Делается это так:

riddles/admin.py

From django.contrib import admin from .models import Option, Riddle admin.site.register(Riddle) admin.site.register(Option)

Вот что получится в итоге:

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

Главная страница

Что нам нужно для создания главной страницы?

• Templates: скелет нашей страницы.
• Views: функция на Python для отображения контента.

Начнем с шаблонов. Создадим папку templates внутри папки riddle , а в ней создадим index.html .

riddles/templates/index.html

Available Riddles

{% if message %}

{{ message }}

• {{ riddle.riddle_text }}
{% endfor %}

{% else %} {% endif %}

Теперь создадим макет для ответов:

{{ riddle.riddle_text }}

{% if error_message %}

{{ error_message }}

{% endif %}

{{ option.text }}
{% endfor %}

Здесь мы используем csrf_token , он нужен для защиты от межсайтовой подделки запроса , каждая внутренняя форма должна его использовать. Теперь напишем виды для рендеринга наших шаблонов:

riddles/views.py

From django.http.response import HttpResponse from django.shortcuts import get_object_or_404, render from .models import Riddle, Option def index(request): return render(request, "index.html", {"latest_riddles": Riddle.objects.order_by("-pub_date")[:5]}) def detail(request, riddle_id): return render(request, "answer.html", {"riddle": get_object_or_404(Riddle, pk=riddle_id)}) def answer(request, riddle_id): riddle = get_object_or_404(Riddle, pk=riddle_id) try: option = riddle.option_set.get(pk=request.POST["option"]) except (KeyError, Option.DoesNotExist): return render(request, "answer.html", {"riddle": riddle, "error_message": "Option does not exist"}) else: if option.correct: return render(request, "index.html", {"latest_riddles": Riddle.objects.order_by("-pub_date")[:5], "message": "Nice! Choose another one!"}) else: return render(request, "answer.html", {"riddle": riddle, "error_message": "Wrong Answer!"})

Давайте пройдемся по каждой функции отдельно:

• index: Index использует функцию render . На вход она получает HttpRequest, местонахождение шаблона и его содержимое, а возвращает HttpResponse с окончательным html.
• detail: Detail делает практически то же самое, но только функция get_object_or_404 возвращает HttpResponse404, если нужный объект не был найден.
• answer: Answer ищет предоставленную загадку (и возвращает 404, если она не найдена) и проверяет правильность ответа.

Теперь добавим наши функции в urls.py:

riddles/urls.py

From django.conf.urls import url from . import views app_name = "riddles" urlpatterns = [ url(r"^$", views.index, name="index"), url(r"^(?P+)/$", views.detail, name="detail"), url(r"^(?P+)/answer/$", views.answer, name="answer") ]

Добавим немного стилей

Для начала создадим директорию static , а в ней создадим файл main.css .

riddles/static/main.css

Body{ margin:40px auto; max-width:650px; line-height:1.6; font-size:18px; color:#444; padding:0 10px; } h1,h2,h3{ line-height:1.2; text-align: center; } a { color: blue; } form { margin: 0 auto; padding: 1em; border: 1px solid #CCC; border-radius: 1em; } form div + div { margin-top: 1em; } label { display: inline-block; text-align: center; width: 40%; } input { font: 1em sans-serif; -moz-box-sizing: border-box; box-sizing: border-box; border: 1px solid #999; width: 50%; } input:focus { border-color: #000; } p, div.button { text-align: center; } p.error-message { color: lightcoral; }

Немного изменим наши шаблоны:

riddles/templates/index.html

{% load staticfiles %}

Available Riddles

{% if message %}

{{ message }}

{% endif %} {% if latest_riddles %}

{% for riddle in latest_riddles %}
• {{ riddle.riddle_text }}
{% endfor %}

{% else %}

No riddles are available right now.

{% endif %}

riddles/templates/answer.html

{% load staticfiles %}

{{ riddle.riddle_text }}

{% if error_message %}

{{ error_message }}

{% endif %}

{% csrf_token %} {% for option in riddle.option_set.all %} {{ option.text }}
{% endfor %}

Первая строка загружает статические файлы, потом мы используем {% static "#" %} , где # - путь к вашему файлу. Аналогичная процедура проводится и для JavaScript.

Теперь вы можете создавать свои собственные приложения на Django.

Django – это мощный фреймворк для создания приложений Python. Такой полнофункциональный фреймворк, как Django, значительно ускоряет процесс создания и развёртывания приложения, беря на себя общее структурирование кода; таким образом, разработчик может сосредоточиться на уникальности и контенте сайта.

В данном руководстве рассматриваются различные методы установки Django на сервер Ubuntu 14.04, а также начало работы с этим фреймворком.

Методы установки Django

Существует несколько различных методов установки Django, каждый из которых имеет свои преимущества в определённых ситуациях.

• Глобальная установка Django из пакета. Официальный репозиторий Ubuntu предоставляет пакеты Django, которые можно без труда установить при помощи менеджера пакетов apt. Этот метод очень прост, но не так гибок, как другие методы. Кроме того, репозиторий может содержать несколько устаревшую версию пакета Django.
• Глобальная установка Django при помощи pip. Инструмент pip – это менеджер пакетов Python. С его помощью можно выполнить общесистемную установку Django. Он, как правило, предоставляет последнюю доступную версию пакета. Однако глобальные (общесистемные) установки всегда менее гибки.
• Установка через pip в Virtualenv. Пакет virtualenv позволяет создавать автономные окружения для разных проектов. При помощи этой технологии можно установить Django в каталог проекта, при этом не повлияв на систему в целом. Это позволяет задавать индивидуальные настройки для каждого проекта. Виртуальное окружение (или среда) – гораздо более гибкий вариант установки пакета.
• Установка разрабатываемой версии через Git. Чтобы установить последнюю разрабатываемую версию вместо стабильного релиза, нужно получить код из репозитория git . Это предоставит новейшие функции и исправления программы; установить такую версию можно как глобально, так и локально. Но имейте в виду: разрабатываемые версии нестабильны.

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

Глобальная установка Django из пакета

Процесс установки Django из официального репозитория Ubuntu очень прост. Для начала нужно обновить список локальных пакетов при помощи apt, а затем установить пакет python-django.

sudo apt-get update
sudo apt-get install python-django

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

django-admin --version
1.6.1

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

Обратите внимание : Эта версия не является последней доступной версией Django.

Глобальная установка через pip

Чтобы глобально установить последнюю стабильную версию Django, используйте инструмент pip, менеджер пакетов Python. Чтобы установить pip, нужно сначала обновить список пакетов:

sudo apt-get update

Чтобы установить pip для Python 2, введите:

Чтобы установить pip для Python 3, используйте:

Теперь менеджер пакетов pip установлен, можно приступать к установке Django. Для Python 2 введите:

sudo pip install django

Для Python 3 наберите:

sudo pip3 install django

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

django-admin --version
1.7.5

Как видите, pip предоставляет более новый релиз Django, чем репозиторий Ubuntu.

Установка Django через pip в Virtualenv

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

Дл начала нужно установить менеджер pip из официального репозитория Ubuntu. Обновите список пакетов:

sudo apt-get update

Для Python 2:

sudo apt-get install python-pip

Для Python 3:

sudo apt-get install python3-pip

После установки pip его можно использовать для установки пакета virtualenv.

Для Python 2 введите:

sudo pip install virtualenv

Для Python 3:

sudo pip3 install virtualenv

Теперь можно создать индивидуальную виртуальную среду для любого проекта. Создайте каталог нового проекта и перейдите в него:

mkdir ~/newproject
cd ~/newproject

Создайте виртуальное окружение в каталоге проекта:

virtualenv newenv

Примечание : Замените условное название newenv своим названием.

Эта команда создаст автономную среду, установит Python и pip в изолированный каталог. Созданный каталог будет содержать файловую иерархию для установки пакетов.

Чтобы установить пакеты в изолированную среду, включите её:

source newenv/bin/activate

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

(newenv)username@hostname:~/newproject$.

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

pip install django

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

django-admin --version
1.7.5

Чтобы покинуть виртуальную среду, используйте команду:

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

cd ~/newproject
source newenv/bin/activate

Установка разрабатываемой версии Django из git

Чтобы установить разрабатываемую версию Django, загрузите её из репозитория git.

Для этого установите git при помощи стандартного менеджера пакетов apt. Обновите список пакетов:

sudo apt-get update

А затем установите git и менеджер пакетов pip, который понадобится позже для установки Django. Для Python 2 используйте:

sudo apt-get install git python-pip

Для Python 3:

sudo apt-get install git python3-pip

После установки git клонируйте репозиторий Django. Он содержит новейшие функции и исправления, но не является стабильным. Чтобы клонировать репозиторий в каталог django-dev в домашнем каталоге, введите:

git clone git://github.com/django/django ~/django-dev

После этого установите его при помощи pip. Используйте флаг -e для установки в режиме editable, поскольку это необходимо при установке через систему контроля версий. Для Python 2:

sudo pip install -e ~/django-dev

Для Python 3:

sudo pip3 install -e ~/django-dev

Введите следующую команду, чтобы убедиться, что установка прошла успешно:

django-admin --version
1.9.dev20150305171756

Примечание : Этот метод можно применить в виртуальной среде и таким образом изолировать нестабильную версию Django.

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

После установки Django ознакомьтесь с основами использования этого фреймворка.

Для создания проекта используется команда django-admin:

django-admin startproject projectname
cd projectname

Эта команда создаст каталог projectname в текущем каталоге и поместит в него скрипт управления и другой каталог по имени projectname с текущим кодом.

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

django-admin startproject projectname .

Чтобы сгенерировать базу данных в более новых версиях Django (по умолчанию используется SQLite), введите:

python manage.py migrate

Если команда migrate не работает, значит, текущая версия Django является более старой и не поддерживает её. В таком случае используйте:

python manage.py syncdb

При этом Django попросит создать учётную запись администратора; укажите имя пользователя, электронный адрес и пароль.

При использовании команды migrate нужно создать учётную запись администратора вручную. Для этого наберите:

python manage.py createsuperuser

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

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

python manage.py runserver 0.0.0.0:8000

В браузере посетите IP-адрес, задав порт:

server_ip_address:8000

Это откроет приветственную страницу Django.

server_ip_address:8000/admin

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

Ознакомившись со стандартным проектом, остановите сервер разработки, введя в терминал CTRL-C. Этот стандартный проект Django является структурной основой для разработки уникального сайта. Чтобы узнать, как создавать пользовательские приложения и настроить свой сайт, читайте документацию Django.

Итоги

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

Tags: ,