Because Django was developed in a fast-paced newsroom environment, it was\ndesigned to make common web development tasks fast and easy. Here’s an informal\noverview of how to write a database-driven web app with Django.
\nO objetivo deste documento é dar a você as especificações técnicas necessárias para entender como o Django funciona, mas este texto não pretende ser um tutorial ou uma referência – mas possuímos os dois! Quando você estiver pronto para iniciar um projeto, você pode iniciar com o tutorial ou mergulhar direto em uma documentação mais detalhada.
\nEmbora você possa usar o Django sem um banco de dados, ele vem com um mapeador objeto-relacional no qual você descreve o leiaute do seu banco de dados em código Python.
\nA sintaxe do modelo de dados oferece muitas formas ricas de representar seus modelos – portanto, está resolvendo muitos anos de problemas com esquemas de banco de dados. Aqui está um exemplo rápido:
\nmysite/news/models.pyfrom django.db import models\n\nclass Reporter(models.Model):\n full_name = models.CharField(max_length=70)\n\n def __str__(self):\n return self.full_name\n\nclass Article(models.Model):\n pub_date = models.DateField()\n headline = models.CharField(max_length=200)\n content = models.TextField()\n reporter = models.ForeignKey(Reporter, on_delete=models.CASCADE)\n\n def __str__(self):\n return self.headline\nA seguir, execute o utilitário de linha de comando do Django para criar as tabelas do banco de dados automaticamente:
\nLinux / macOS
$ python manage.py makemigrations\n$ python manage.py migrate\nWindows
...\\> py manage.py makemigrations\n...\\> py manage.py migrate\nO comando makemigrations procura por todos os seus modelos disponíveis e cria migrações para cada tabela que ainda não exista. migrate executa as migrações e cria as tabelas em seu banco de dados, bem como, opcionalmente, fornece um controle muito mais rico do seu esquema de dados.
Com isso, você tem uma API Python livre e rica para acessar seus dados. A API é criada em tempo de execução, nenhuma geração de código é necessária:
\n# Import the models we created from our "news" app\n>>> from news.models import Article, Reporter\n\n# No reporters are in the system yet.\n>>> Reporter.objects.all()\n<QuerySet []>\n\n# Create a new Reporter.\n>>> r = Reporter(full_name='John Smith')\n\n# Save the object into the database. You have to call save() explicitly.\n>>> r.save()\n\n# Now it has an ID.\n>>> r.id\n1\n\n# Now the new reporter is in the database.\n>>> Reporter.objects.all()\n<QuerySet [<Reporter: John Smith>]>\n\n# Fields are represented as attributes on the Python object.\n>>> r.full_name\n'John Smith'\n\n# Django provides a rich database lookup API.\n>>> Reporter.objects.get(id=1)\n<Reporter: John Smith>\n>>> Reporter.objects.get(full_name__startswith='John')\n<Reporter: John Smith>\n>>> Reporter.objects.get(full_name__contains='mith')\n<Reporter: John Smith>\n>>> Reporter.objects.get(id=2)\nTraceback (most recent call last):\n ...\nDoesNotExist: Reporter matching query does not exist.\n\n# Create an article.\n>>> from datetime import date\n>>> a = Article(pub_date=date.today(), headline='Django is cool',\n... content='Yeah.', reporter=r)\n>>> a.save()\n\n# Now the article is in the database.\n>>> Article.objects.all()\n<QuerySet [<Article: Django is cool>]>\n\n# Article objects get API access to related Reporter objects.\n>>> r = a.reporter\n>>> r.full_name\n'John Smith'\n\n# And vice versa: Reporter objects get API access to Article objects.\n>>> r.article_set.all()\n<QuerySet [<Article: Django is cool>]>\n\n# The API follows relationships as far as you need, performing efficient\n# JOINs for you behind the scenes.\n# This finds all articles by a reporter whose name starts with "John".\n>>> Article.objects.filter(reporter__full_name__startswith='John')\n<QuerySet [<Article: Django is cool>]>\n\n# Change an object by altering its attributes and calling save().\n>>> r.full_name = 'Billy Goat'\n>>> r.save()\n\n# Delete an object with delete().\n>>> r.delete()\nUma vez que seus modelos estejam definidos, Django pode automaticamente criar uma interface de administração profissional pronta para produção – um website que permite a usuários autenticados adicionarem, alterarem e removerem objetos. O único passo necessário é registrar seu modelo no site de administração:
\nmysite/news/models.pyfrom django.db import models\n\nclass Article(models.Model):\n pub_date = models.DateField()\n headline = models.CharField(max_length=200)\n content = models.TextField()\n reporter = models.ForeignKey(Reporter, on_delete=models.CASCADE)\nmysite/news/admin.pyfrom django.contrib import admin\n\nfrom . import models\n\nadmin.site.register(models.Article)\nA filosofia aqui é que seu site é editado por uma equipe, ou um cliente, ou talvez apenas por você – e você não quer ter que lidar com criação de interfaces apenas para gerenciar conteúdo.
\nUm fluxo de trabalho típico na criação de aplicações Django é criar os modelos e ter os sites de administração rodando o mais rápido possível, assim sua equipe (ou cliente) poderá começar a inserir os dados. Em seguida, desenvolve-se a forma com que os dados serão apresentados ao público.
\nA clean, elegant URL scheme is an important detail in a high-quality web\napplication. Django encourages beautiful URL design and doesn’t put any cruft\nin URLs, like .php or .asp.
Para projetar URLs para uma aplicação, você cria um módulo Python que chamamos de URLconf. Uma tabela de conteúdos para sua aplicação, contendo um mapeamento entre padrões de URL e funções Python. URLconfs também servem para desacoplar as URLs do código Python.
\nAqui está como um URLconf se aparentaria para o exemplo Reporter/Article acima:
mysite/news/urls.pyfrom django.urls import path\n\nfrom . import views\n\nurlpatterns = [\n path('articles/<int:year>/', views.year_archive),\n path('articles/<int:year>/<int:month>/', views.month_archive),\n path('articles/<int:year>/<int:month>/<int:pk>/', views.article_detail),\n]\nO código acima mapeia URLs, como simples expressões regulares, para a localização das funções Python de retorno (“views”). As strings dos caminhos usam tags (valores entre <>) de parâmetros para “capturar” valores das URLs. Quando um usuário requisita uma página, o Django percorre cada padrão, em ordem, e para no primeiro que casa com a URL requisitada. (Se nenhum deles combinar o Django executa uma view especial de exceção 404.) Isso é incrivelmente rápido, porque os caminhos são compilados em expressões regulares.
\nOnce one of the URL patterns matches, Django calls the given view, which is a\nPython function. Each view gets passed a request object – which contains\nrequest metadata – and the values captured in the pattern.
\nPor exemplo, se um usuário solicita a URL “/articles/2005/05/39323/”, Django chamaria a função news.views.article_detail(request, year=2005, month=5, pk=39323).
Cada view é responsável por fazer uma entre duas coisas: Devolver um objeto HttpResponse contendo o conteúdo para a página requisitada, ou levantar uma exceção como Http404. O resto é com você.
Geralmente, uma view recupera dados de acordo com os parâmetros, carrega um template e renderiza o template com os dados recuperados. Aqui está uma view para o year_archive do exemplo acima:
mysite/news/views.pyfrom django.shortcuts import render\n\nfrom .models import Article\n\ndef year_archive(request, year):\n a_list = Article.objects.filter(pub_date__year=year)\n context = {'year': year, 'article_list': a_list}\n return render(request, 'news/year_archive.html', context)\nEsse exemplo usa o sistema de template do Django, o qual possui diversos recursos poderosos mas prima por permanecer simples o\nsuficiente para que não-programadores possam usá-lo.
\nO código acima carrega o template news / year_archive.html.
O Django tem um caminho de pesquisa para templates, o qual permite a você minimizar a redundância entre templates. Nas configurações do Django, você especifica uma lista de diretórios para procurar por templates em DIRS. Se um template não existir no primeiro diretório, ele verifica o segundo e assim por diante.
Vamos dizer que o template news/article_detail.html foi encontrado. Aqui está como ele deve se parecer:
mysite/news/templates/news/year_archive.html{% extends "base.html" %}\n\n{% block title %}Articles for {{ year }}{% endblock %}\n\n{% block content %}\n<h1>Articles for {{ year }}</h1>\n\n{% for article in article_list %}\n <p>{{ article.headline }}</p>\n <p>By {{ article.reporter.full_name }}</p>\n <p>Published {{ article.pub_date|date:"F j, Y" }}</p>\n{% endfor %}\n{% endblock %}\nVariáveis são cercadas por chaves duplas. {{ article.headline }} que significa “retorne o valor do atributo headline do artigo”, mas pontos não são usados apenas para acessar atributos: eles também podem acessar chaves de dicionários, acesar índices e chamar funções.
Note que {{ article.pub_date|date:"F j, Y" }} usa um “pipe” no estilo Unix (o caractere “|”). Isso é chamado de filtro de template, e é uma forma de filtrar o valor de uma variável. Nesse caso, o filtro “date” formata um objeto Python datetime para um formato dado (como o encontrado na função date do PHP).
Você pode atrelar tantos filtros quanto você quiser. Você pode escrever filtros personalizados. Você pode escrever tags de template personalizadas, que irão executar código Python personalizado por baixo dos panos.
\nFinalmente, o Django usa o conceito de “herança de templates”: É isso que o {% extends "base.html" %} faz. Isso significa “primeiro carregue o template chamado ‘base’, o qual define uma série de blocos, e preencha os blocos com os seguintes blocos”. Resumindo, isso permite a você reduzir drasticamente a redundância em seus templates: cada template tem que definir apenas aquilo que é único para aquele template.
Aqui está como o template “base.html”, incluindo o uso de arquivos estáticos, deve se parecer:
\nmysite/templates/base.html{% load static %}\n<html>\n<head>\n <title>{% block title %}{% endblock %}</title>\n</head>\n<body>\n <img src="{% static 'images/sitelogo.png' %}" alt="Logo">\n {% block content %}{% endblock %}\n</body>\n</html>\nSimplificadamente, ele define a aparência do site (com o logo do site), e fornece “buracos” para templates filhos preencherem. Isso significar que um redesenho do site pode ser feito alterando um único arquivo - o template base.
\nIsto também permite criar múltiplas versões de um site, com diferentes templates bases, mas com reuso de templates filhos. Os criadores do Django usaram essa técnica para criar versões mobile do site surpreendentemente diferentes apenas criando um novo template base.
\nNote que você não tem que usar o sistema de templates do Django se você preferir outro. Enquanto o sistema de templates do Django é particularmente bem integrado com a camada de modelos do Django, nada força você a usá-lo. Da mesma maneira que, você não tem que usar a API de banco de dados do Django, também. Você pode usar outras camadas de abstração de banco de dados, você pode ler arquivos XML, você pode ler arquivos do disco, ou qualquer coisa que desejar. Cada parte do Django – modelos, visões e templates – é desacoplada da próxima.
\nEsta foi apenas uma breve visão geral da funcionalidade do Django. Algumas características mais úteis:
\nUm framework para caching que se integra com o memcached e outros backends.
Um framework de distribuição que permite você criar feeds RSS e Atom escrevendo uma pequena classe Python.
Recursos para gerar automaticamente um site de administração mais atrativo - essa visão gera mal arranhou a superfície.
The next steps are for you to download Django, read the tutorial and join the community. Thanks for your interest!
\n