Django Handledning
Komma igång med Django

Anmärkningar

versioner

Starta ett projekt

Django är en webbutvecklingsram baserad på Python. Django 1.11 (den senaste stabila versionen) kräver att Python 2.7 , 3.4 , 3.5 eller 3.6 ska installeras. Förutsatt att pip är tillgänglig är installationen så enkel som att köra följande kommando. Tänk på att utelämna versionen som visas nedan kommer att installera den senaste versionen av django:

$ pip install django

För att installera specifik version av django, låt oss anta att versionen är django 1.10.5 , kör följande kommando:

$ pip install django==1.10.5

Webbapplikationer byggda med Django måste ligga inom ett Django-projekt. Du kan använda django-admin kommandot för att starta ett nytt projekt i den aktuella katalogen:

$ django-admin startproject myproject

där myproject är ett namn som identifierar projektet unikt och kan bestå av siffror , bokstäver och understreck .

Detta skapar följande projektstruktur:

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

Starta utvecklingsservern för att köra applikationen

$ cd myproject
$ python manage.py runserver

Nu http://127.0.0.1:8000/ servern är igång besöker du http://127.0.0.1:8000/ med din webbläsare. Du ser följande sida:

Som standard startar runserver kommandot utvecklingsservern på den interna IP-adressen i port 8000 . Denna server startar om automatiskt när du gör ändringar i din kod. Men om du lägger till nya filer måste du starta om servern manuellt.

Om du vill ändra serverporten, skicka den som ett kommandoradsargument.

$ python manage.py runserver 8080

Om du vill ändra serverns IP, skicka den tillsammans med porten.

$ python manage.py runserver 0.0.0.0:8000

Observera att runserver endast är för felsökning och lokala tester. Specialiserade serverprogram (t.ex. Apache) bör alltid användas i produktionen.

Lägga till en Django-app

Ett Django-projekt innehåller vanligtvis flera apps . Detta är helt enkelt ett sätt att strukturera ditt projekt i mindre, underhållbara moduler. För att skapa en app, gå till din projektmapp (där manage.py är) och kör startapp kommandot (ändra myapp till vad du vill):

python manage.py startapp myapp

Detta genererar myapp- mappen och några nödvändiga filer för dig, som models.py och views.py .

För att göra Django medveten om myapp , lägg till den till dina settings.py :

# myproject/settings.py

# Application definition
INSTALLED_APPS = [
    ...
    'myapp',
]

Mappstrukturen för ett Django-projekt kan ändras för att passa dina önskemål. Ibland byts namn på projektmappen till /src att undvika att upprepa mappnamn. En typisk mappstruktur ser ut så här:

Django Concepts

django-admin är ett kommandoradsverktyg som skickas med Django. Det kommer med flera användbara kommandon för att komma igång med och hantera ett Django-projekt. Kommandot är detsamma som ./manage.py , med skillnaden att du inte behöver vara i projektkatalogen. DJANGO_SETTINGS_MODULE miljövariabeln måste ställas in.

Ett Django-projekt är en Python-kodbas som innehåller en Django-inställningsfil. Ett projekt kan skapas av Django-administratören via kommandot django-admin startproject NAME . Projektet har vanligtvis en fil som heter manage.py på toppnivå och en root-URL-fil som heter urls.py manage.py är en projektspecifik version av django-admin och låter dig köra hanteringskommandon för det projektet. För att till exempel köra ditt projekt lokalt använder du python manage.py runserver . Ett projekt består av Django-appar.

En Django-app är ett Python-paket som innehåller en models.py ( models.py standard) och andra filer som appspecifika webbadresser och vyer. En app kan skapas via kommandot django-admin startapp NAME (detta kommando bör köras inifrån din projektkatalog). För att en app ska ingå i ett projekt måste den inkluderas i INSTALLED_APPS listan i settings.py . Om du använde standardkonfigurationen kommer Django med flera appar med egna appar förinstallerade som kommer att hantera saker som autentisering för dig. Appar kan användas i flera Django-projekt.

Django ORM samlar alla databasmodeller definierade i models.py och skapar databastabeller baserade på dessa modellklasser. För att göra detta, först konfigurera din databas genom att ändra inställningen DATABASES i settings.py . Sedan, när du har definierat dina databasmodeller , kör python manage.py makemigrations följt av python manage.py migrate att skapa eller uppdatera databasens schema baserat på dina modeller.

Ett komplett hejsexempel.

Steg 1 Om du redan har Django installerat kan du hoppa över det här steget.

pip install Django

Steg 2 Skapa ett nytt projekt

django-admin startproject hello

Det skapar en mapp som heter hello som kommer att innehålla följande filer:

hello/
├── hello/
│   ├── __init__.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
└── manage.py

Steg 3 Inuti hello (mappen som innehåller __init.py__ ) skapa en fil som heter views.py :

hello/
├── hello/
│   ├── __init__.py
│   ├── settings.py
│   ├── urls.py
│   ├── views.py  <- here
│   └── wsgi.py
└── manage.py

och lägg i följande innehåll:

from django.http import HttpResponse

def hello(request):
    return HttpResponse('Hello, World')

Detta kallas en visningsfunktion.

Steg 4 Redigera hello/urls.py enligt följande:

from django.conf.urls import url
from django.contrib import admin
from hello import views

urlpatterns = [
    url(r'^admin/', admin.site.urls),
    url(r'^$', views.hello)
]

som länkar visningsfunktionen hello() till en URL.

Steg 5 Starta servern.

python manage.py runserver

Steg 6

Bläddra till http://localhost:8000/ i en webbläsare så ser du:

Hej världen

Virtuell miljö

Även om det inte är strikt krävs rekommenderas starkt att du startar ditt projekt i en "virtuell miljö." En virtuell miljö är en behållare (en katalog) som innehåller en specifik version av Python och en uppsättning moduler (beroenden) och som inte stör operativsystemets ursprungliga Python eller andra projekt på samma dator.

Genom att skapa en annan virtuell miljö för varje projekt du arbetar med, kan olika Django-projekt köras på olika versioner av Python, och kan upprätthålla sina egna beroenden utan risk för konflikter.

Python 3.3+

Python 3.3+ innehåller redan en standard- venv modul, som du vanligtvis kan kalla som pyvenv . I miljöer där pyvenv kommandot inte är tillgängligt kan du komma åt samma funktionalitet genom att direkt anropa modulen som python3 -m venv .

Så här skapar du den virtuella miljön:

$ pyvenv <env-folder>
# Or, if pyvenv is not available
$ python3 -m venv <env-folder>

Python 2

Om du använder Python 2 kan du först installera den som en separat modul från pip:

$ pip install virtualenv

Och skapa miljön med hjälp av kommandot virtualenv istället:

$ virtualenv <env-folder>

Aktivera (valfri version)

Den virtuella miljön är nu skapad. För att kunna använda den måste den aktiveras i terminalen du vill använda den.

För att "aktivera" den virtuella miljön (vilken Python-version som helst)

Linux som:

$ source <env-folder>/bin/activate

Windows som:

<env-folder>\Scripts\activate.bat

Detta ändrar din uppmaning för att indikera att den virtuella miljön är aktiv. (<env-folder>) $

Från och med nu kommer allt installerat med pip installeras i din virtuella env-mapp, inte hela systemet.

För att lämna den virtuella miljön ska du deactivate :

(<env-folder>) $ deactivate

Alternativt: använd virtualenvwrapper

Du kan också överväga att använda virtualenvwrapper som gör skapandet och aktiveringen av virtualenv mycket praktisk samt att separera den från din kod:

# Create a virtualenv
mkvirtualenv my_virtualenv

# Activate a virtualenv
workon my_virtualenv

# Deactivate the current virtualenv
deactivate

Alternativt: använd pyenv + pyenv-viritualenv

I miljöer där du behöver hantera flera Python-versioner kan du dra nytta av virtualenv tillsammans med pyenv-virtualenv:

# Create a virtualenv for specific Python version
pyenv virtualenv 2.7.10 my-virtual-env-2.7.10

# Create a vritualenv for active python verion
pyenv virtualenv venv34

# Activate, deactivate virtualenv
pyenv activate <name>
pyenv deactivate

När du använder virtualenvs är det ofta användbart att ställa in PYTHONPATH och DJANGO_SETTINGS_MODULE i postactivate skriptet .

#!/bin/sh
# This hook is sourced after this virtualenv is activated

# Set PYTHONPATH to isolate the virtualenv so that only modules installed
# in the virtualenv are available
export PYTHONPATH="/home/me/path/to/your/project_root:$VIRTUAL_ENV/lib/python3.4"

# Set DJANGO_SETTINGS_MODULE if you don't use the default `myproject.settings`
# or if you use `django-admin` rather than `manage.py`
export DJANGO_SETTINGS_MODULE="myproject.settings.dev"

Ställ in din projektväg

Det är ofta också bra att ställa in din projektväg i en speciell .project i din <env-folder> . När du gör detta, varje gång du aktiverar din virtuella miljö, kommer den att ändra den aktiva katalogen till den angivna sökvägen.

Skapa en ny fil som heter <env-folder>/.project . Filens innehåll ska ENDAST vara projektkatalogens sökväg.

/path/to/project/directory

Starta nu din virtuella miljö (antingen med hjälp av source <env-folder>/bin/activate eller workon my_virtualenv ) och din terminal kommer att byta kataloger till /path/to/project/directory .

Enkel fil Hello World Exempel

Detta exempel visar dig ett minimalt sätt att skapa en Hello World-sida i Django. Detta kommer att hjälpa dig att inse att django-admin startproject example skapar en massa mappar och filer och att du inte nödvändigtvis behöver den strukturen för att köra ditt projekt.

1. Skapa en fil som heter file.py

2. Kopiera och klistra in följande kod i den filen.

    import sys
    
    from django.conf import settings
    
    settings.configure(
        DEBUG=True,
        SECRET_KEY='thisisthesecretkey',
        ROOT_URLCONF=__name__,
        MIDDLEWARE_CLASSES=(
            'django.middleware.common.CommonMiddleware',
            'django.middleware.csrf.CsrfViewMiddleware',
            'django.middleware.clickjacking.XFrameOptionsMiddleware',
        ),
    )
    
    from django.conf.urls import url
    from django.http import HttpResponse
    
    # Your code goes below this line.
   
    def index(request):
        return HttpResponse('Hello, World!')
   
    urlpatterns = [
        url(r'^$', index),
    ]
   
    # Your code goes above this line
    
    if __name__ == "__main__":
        from django.core.management import execute_from_command_line
    
        execute_from_command_line(sys.argv)
   

3. Gå till terminalen och kör filen med det här kommandot python file.py runserver .

4. Öppna din webbläsare och gå till 127.0.0.1:8000 .

Distributionsvänligt projekt med Docker-stöd.

Standardmallen för Django-projekt är bra, men när du väl har kommit att distribuera din kod och till exempel devops lägger händerna på projektet blir saker röriga. Vad du kan göra är att separera din källkod från resten som krävs för att vara i ditt förvar.

Du kan hitta en användbar Django-projektmall på GitHub .

Projektstruktur

PROJECT_ROOT
├── devel.dockerfile
├── docker-compose.yml
├── nginx
│   └── project_name.conf
├── README.md
├── setup.py
└── src
    ├── manage.py
    └── project_name
        ├── __init__.py
        └── service
            ├── __init__.py
            ├── settings
            │   ├── common.py
            │   ├── development.py
            │   ├── __init__.py
            │   └── staging.py
            ├── urls.py
            └── wsgi.py

Jag vill hålla service katalog som heter service för varje projekt tack vare att jag kan använda samma Dockerfile i alla mina projekt. Uppdelningen av krav och inställningar är redan väl dokumenterad här:
Använda flera kravfiler
Använda flera inställningar

Dockerfile

Med antagandet att endast utvecklare använder Docker (inte alla dev-uppgifter litar på det idag). Detta kan vara en dev-miljö devel.dockerfile :

FROM python:2.7
ENV PYTHONUNBUFFERED 1

RUN mkdir /run/service
ADD . /run/service
WORKDIR /run/service

RUN pip install -U pip
RUN pip install -I -e .[develop] --process-dependency-links

WORKDIR /run/service/src
ENTRYPOINT ["python", "manage.py"]
CMD ["runserver", "0.0.0.0:8000"]

Att lägga till endast krav kommer att utnyttja Docker-cache när du bygger - du behöver bara bygga om efter kravändring.

Komponera

Docker-komposition är praktiskt - särskilt när du har flera tjänster att köra lokalt. docker-compose.yml :

version: '2'
services:
  web:
    build:
      context: .
      dockerfile: devel.dockerfile
    volumes:
      - "./src/{{ project_name }}:/run/service/src/{{ project_name }}"
      - "./media:/run/service/media"
    ports:
      - "8000:8000"
    depends_on:
      - db
  db:
    image: mysql:5.6
    environment:
      - MYSQL_ROOT_PASSWORD=root
      - MYSQL_DATABASE={{ project_name }}
  nginx:
    image: nginx
    ports:
      - "80:80"
    volumes:
      - "./nginx:/etc/nginx/conf.d"
      - "./media:/var/media"
    depends_on:
      - web

Nginx

Din utvecklingsmiljö bör vara så nära prod-miljön som möjligt så jag gillar att använda Nginx från början. Här är ett exempel på en nginx-konfigurationsfil:

server {
    listen   80;
    client_max_body_size 4G;
    keepalive_timeout 5;

    location /media/ {
        autoindex on;
        alias /var/media/;
    }

    location / {
        proxy_pass_header Server;
        proxy_set_header Host $http_host;
        proxy_redirect off;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Scheme $scheme;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Ssl on;
        proxy_connect_timeout 600;
        proxy_read_timeout 600;
        proxy_pass http://web:8000/;
    }
}

Användande

$ cd PROJECT_ROOT
$ docker-compose build web  # build the image - first-time and after requirements change
$ docker-compose up  # to run the project
$ docker-compose run --rm --service-ports --no-deps  # to run the project - and be able to use PDB
$ docker-compose run --rm --no-deps <management_command>  # to use other than runserver commands, like makemigrations
$ docker exec -ti web bash  # For accessing django container shell, using it you will be inside /run/service directory, where you can run ./manage shell, or other stuff
$ docker-compose start  # Starting docker containers
$ docker-compose stop  # Stopping docker containers