Um projeto Django


Desenhando um projeto

Para efeito de nosso aprendizado vamos desenvolver um aplicativo para a tomada de anotações. Começaremos com uma tabela simples de notas, com os seguintes campos:

Notas
id titulo texto slug
0 Introdução ao Python Texto da nota sobre python introducao-ao-python
1 Django Texto da nota sobre django django
2 Python para Web Texto da nota sobre python para web python-para-web

Os valores na tabela são ilustrativos. O slug, como veremos, é um tipo de atalho representativo da nota, criado automaticamente e usado na url de acesso à informação. Depois introduziremos aperfeiçoamentos à essa estrutura de dados.

Criando o projeto do django

Uma vez instalados os módulos necessários, com o ambiente virtual ativado, usamos um comando para criar um projeto do django. No primeiro uso do django algum ajuste deve ser providenciado. De dentro do diretório onde será construído o aplicativo executamos, no prompt de comando:

(env) $ django-admin startproject app_notas


Esse comando cria uma estrutura básica de um site. Observe que, diferente de aplicativos em PHP e outros, o aplicativo django não fica no diretório raiz de um servidor web, o que é uma boa coisa considerados os riscos de segurança.

Esses arquivos são:

app_notas diretório raiz do projeto, pode ser renomeado. Nós o chamaremos de app_notas.
manage.py utilitário de comando de linha para interação com o projeto Django.
app_notas subdiretório, é o módulo Python do aplicativo. Esse nome será usado nas importações futuras.
app_notas/__init__.py arquivo vazio para marcar esse diretório como um módulo.
app_notas/settings.py Configurações para esse projeto.
app_notas/urls.py as declarações de URLs para o projeto.
app_notas/asgi.py ponto de entrada para ASGI web servers.
app_notas/wsgi.py ponto de entrada para WSGI web servers.

O arquivo __init__.py (que pode ser vazio) serve para marcar seu diretório como um módulo do python. Dentro desse módulo podem existir classes que podem ser importadas em outras partes do projeto.

Se você usar controle de versão coloque o diretório projeto_django sob o controle do git. Um arquivo README.md deve ser colocado no diretório raiz, com especificações sobre o projeto.

manage.py

Mais informações em: Django Docs: Manage.py

Dentro do arquivo manage.py é estabelecida uma variável global que indica onde estão, para esse projeto, as configurações.
A variável global DJANGO_SETTINGS_MODULE aponta para o arquivo settings.py, onde se encontram diversas variáveis de controle do sistema.
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'app_notas.settings')
Em settings.py existem diversas variáveis. Entre elas vamos listar apenas algumas:

# Caminho para projeto
BASE_DIR = Path(__file__).resolve().parent.parent

# Debug, booleano. True durante o desenvolvimento. Deve ser tornada False na produção
DEBUG = True

INSTALLED_APPS = [...]             # um dicionário com aplicatyivos instalados

ROOT_URLCONF = 'app_notas.urls'    # onde estão os encaminhamentos de URLs padrão

TEMPLATES = [ ... ]                # referências para os templates instalados

DATABASES                          # referência para o banco de dados usados. Por default SQLite

# varáveis de internationalização
LANGUAGE_CODE = 'pt-br'            # código de língua   (alterado para pt-br, português do Brasil)
TIME_ZONE = 'BRT'                  # faixa horária      (alterado para BRT, hora de Brasília)
USE_TZ = True                      # use time-zone

# onde estão arquivos estáticos (CSS, JavaScript, Images)
STATIC_URL = 'static/'

Feito isso temos um site (ou um aplicativo) montado e pronto para ser rodado. O Django fornece um servidor de desenvolvimento (que só pode ser executado se DEBUG = True).
Observação importante: Em nenhuma hipótese se deve rodar o servidor de desenvolvimento durante a produção, por motivo de segurança.

O servidor de desenvolvimento é iniciado com

$ python manage.py runserver
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

Observação: nessas notas vamos representar o prompt simplesmente por $, lembrando que estamos trabalhando em um ambiente virtual.

Se digitarmos na barra de endereço do browser a url http://127.0.0.1:8000/ poderemos ver a tela de boas vindas do django.

Outros comandos ficam disponíveis com manage.py, entre eles:

runserver inicia o servidor de desenvolvimento.
startapp cria um app no Django.
shell inicia uma shell no interpretador com o projeto Django carregado.
dbshell inicia uma shell conectada ao banco de dados em uso, onde se pode rodar queries manualmente.
makemigrations generate alterações no banco de dados definidas pelos modelo.
migrate aplica as alterações geradas por makemigrations.
test roda testes automatizados.

Mais informações no site do Django: Admin e manage.py.

Criando Apps

No Django um projeto pode ter diversos Apps. Um app é um módulo contendo uma parte da funcionalidade do projeto. Por exemplo, nosso projeto de notas pode conter um app para a acesso e modificação das notas, um outro para registrar notas que são agendamentos e calendário, e ainda um terceiro para gerenciar a acesso de vários usuários cadastrados para uso do app.

Para criar um app usamos a comando de linha:

$ python manage.py startapp <nome_do_app>
# no nosso caso
$ python manage.py startapp notas

A seguinte estrutura de diretórios é gerada:

admin.py permite ajuste da página de administração, automaticamente crada pelo django.
apps.py configuração específica do app.
models.py deve conter os modelos geradores das tabelas do banco de dados.
tests.py armazena os testes para debugging.
views.py definição das visualizações.
migrations pasta que armazena as alterações em banco de dados, para sincronização.

O arquivo db.sqlite3, o arquivo do SQlite, é gerado e modificado com as migrações.

Como inserimos um novo app ao projeto, temos que informar isso no arquivo settings.py, na lista INSTALLED_APPS. Fazemos a seguinte modificação:
notas/settings.py

INSTALLED_APPS = [
    'django.contrib.admin',
    ... linhas omitidas
    'notas',
]

Inserimos a linha em negrito, com referência para o app notas. As demais linhas foram criadas pelo django.

Quando uma requisição é feita ao navegador, por meio de uma URL, o django passa essa requisição pelo arquivo urls.py. Se nenhuma das linhas de url forem satisfeitas uma mensagem de erro é emitida. O erro é bastante detalhado em modo de desenvolvimento, com DEBG = True, e exposto no navegador.

Vamos portanto criar uma url que pode ser reconhecida pelo aplicativo. Inicialmente vamos receber a url sem parâmetro e retornar uma página de Boas Vindas. Para isso inserimos no arquivo:
notas/urls.py

import notas.views
from django.contrib import admin
from django.urls import path

urlpatterns = [
    path('admin/', admin.site.urls),
    path('', notas.views.index),
]

A próxima etapa é a criação de uma view. Para isso editamos o arquivo notas.views e inserimos uma função denominada index. Vamos fazer isso em etapas, para compreender o funcionamento de views.
notas/views.py

from django.http import HttpResponse

def index(request):
    return HttpResponse("Meu primeiro site!")

Se você executar python manage.py runserver e abrir o navegador (em http://127.0.0.1:8000/) veremos, na página do navegador, a frase:

Tags html podem ser passadas, por exemplo para enviar esse texto como um título nível 1, como em return HttpResponse("<h1>Meu primeiro site!</h1>")

Alternativamente podemos retornar uma página pronta de html. Mudamos o conteúdo de views para:
notas/views.py

from django.shortcuts import render

def home(request):
    return render(request,'home.html')

Observação: Os objetos (no caso funções) HttpResponse e render são importadas de seus respectivos módulos de origem. No segundo caso a função render chama um “template” (um modelo de página html) passando para ele o conteúdo de render, como veremos.

Para criar o template vamos gerar nova pasta e um novo arquivo html: Arquivo home.html, lembrando que app_notas é a pasta raiz do projeto:
app_notas/templates/home.html

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
</head>
<body>
    <h1>Página inicial do aplicativo de Notas</h1>
    <p>Essas são as minhas notas.</p>
</body>
</html>    

Finalmente informamos em settings.py que usaremos um diretório em os.path.join(BASE_DIR,'templates'), lembrando que BASE_DIR é a pasta raiz do projeto. Não podemos esquecer de importar o módulo os.
app_notas/settings.py

import os

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        ': [os.path.join(BASE_DIR,'templates')],
        'APP_DIRS': True,
        ...
    },
]

Agora, quando executamos o servidor e abrimos a página no navegador veremos, devidamente renderizado:


Observação: No arquivo settings.py temos a variável TEMPLATES que é uma lista de dicionários. Nela estão definidas DIRS e APP_DIRS. DIRS define uma lista de diretórios onde o código deve procurar por arquivos de template, em ordem de prioridade. APP_DIRS é booleana. Se True o código deve procurar por templates dentro dos diretórios de aplicativos instalados.

Vimos, até agora, que aplicativos são usados para adicionar recursos ao projeto. O aplicativo é conectado ao projeto com a adição de sua classe de configuração à lista INSTALLED_APPS do arquivo settings.py. O reconhecimento das URLs recebidas pela navegador é feito no arquivo urls.py, que associa a requisição à visualização em views.py que retorna um conteúdo para um template.

Templates

Um template é um arquivo de texto com conteúdo em html e marcação adicional de tags do django que permitem a inserção dinâmica de conteúdo no template. Essas tags podem conter variáveis e determinar fluxo de código, bem similar à própria sintaxe do python. Por exemplo, suponha que enviamos para um template (já veremos como fazer isso) uma lista (ou qualquer objeto iterável) em um variável notas = ["nota1", "nota2","nota3"]. O seguinte template seria traduzido e enviado para o navegador na forma mostrada à direita:

  <ul>
  {% for nota in notas %}
    <li>{{ nota }}</li>
  {%endfor%}
  </ul>  
<ul>
<li>nota1</li>
<li>nota2</li>
<li>nota3</li>
</ul>
Todas as tags, classes e ids html podem ser formatados com CSS, da maneira usual. Observe que estamos chamando de tags dois objetos diferentes: tags html são as usuais p, h1, ul, .... Tags do django são marcações para inserir conteúdos em templates.

Tags do django são adicionadas com a sintaxe: {% tag %} enquanto variáveis são avaliadas e expostas para o código html com {{ variavel }}. Exemplos disso são:{% for %} conteúdo {% endfor %}. Objetos podem ter seus atributos consultados com a notação de ponto, {{ objeto.atributo }}. Filtros podem ser usados para modificar valores de variáveis, usando-se uma barra vertical (|). Por ex.: {{ nota|truncatechars:5 }} trunca a string em 5 caracteres.

Herança de templates

Supondo que a maior parte (ou todas) das páginas de nosso site têm a mesma estrutura, o que costuma ocorrer, podemos criar um template base importado e extendido pelas páginas.

No diretório do aplicativo templates criamos o arquivo base.html:
template/base.html

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Notas</title>
</head>
<body>
  <ul class="menu">
    <li><a href="{% url 'index' %}">Home</a></li>
  </ul>
  {% block title %}
  {% endblock %}
  {% block content %}
    Esse é meu site de Notas
  {% endblock %}
</body>
</htmlglt;

O arquivo home.html fica modificado assim:
template/home.html

{% extends "base.html" %}
{% block title %}
  <h1>Aplicativo de Notas</h1>
{% endblock %}

{% block content %}
  <h1>Página inicial</h1>
  <p>Essas são as minhas notas.</p>
{% endblock %}

Esse arquivo home.html herda a estrutura de base.html, substituindo nele o conteúdo dos blocos de mesmo nome. Um bloco pode ser omitido no arquivo filho e, nesse caso o conteúdo original de base.html é exibido.

Antes de executar esse site vamos fazer mais algumas alterações: o arquivo urls.py fica da seguinte forma:
app_notas/urls.py

    
from django.contrib import admin
from django.urls import path, include

urlpatterns = [
    ...
    path('', include('notas.urls')),
]

Após importar include, indicamos que o padrão de url vazio (ou outro que não for casado com as urls atuais) será redirecionado para notas.urls que criaremos a seguir. Na pasta do aplicativo gravamos urls.py:
notas/urls.py

from django.urls import path
from . import views

urlpatterns = [
    path('', views.index, name='index'),
]

Esse arquivo importa views que está na mesma pasta (.) e remete chamadas para views.index. Quando executamos python manage.py runserver e abrimos o navegador vemos a página:

O link <a href="{% url 'index' %}">Home</a> no topo do arquivo base.html será exibido em todas as páginas que herdam esse código. Ele contém um referência ativada pela função url do django, com o parâmetro index. Esta é uma forma de evitar que façamos referências com urls fixas nas páginas do aplicativo.

Arquivos Estáticos e CSS


Claro que páginas html sem nenhuma formatação não satisfazem a demanda de nenhum usuário moderno. Para que as páginas html tenham acesso aos arquivos de formatação CSS precisamos indicar para o django onde encontrar esses arquivos, além imagens e outros arquivos estáticos.

Vamos começar criando os diretórios static e static/css dentro do diretório raiz do projeto. Dentro criamos o arquivo estilo.css (usando aqui apenas algumas poucas configurações, apenas para demonstrar o funcionamento).
static/css/estilo.css

body { width:80%; margin: 5% 10%; }
h1 { color:navy; }    
.menu { list-style:none; padding-left:0; }
.menu > li { display:inline-block; }
.menu > li > a { text-decoration:none; color:#000; margin:00.3em; }
.menu > li > a.active { padding-bottom:0.3em; border-bottom:2px solid #528DEA; }

Temos que informar ao django onde estão os arquivos estáticos, modificando settings.py:
app_notas/settings.py

STATIC_URL='/static/'

STATICFILES_DIRS = [os.path.join(BASE_DIR,'static'),]

INSTALLED_APPS = [
    ...
    'django.contrib.staticfiles',
    'notas',
]

Lembrando que já temos, como mostrado acima, o dicionário
INSTALLED_APPS = [ …, ‘django.contrib.staticfiles’,…]
com a indicação para acessar arquivos estáticos. Toda essa configuração só deve ser usada com projetos na fase de desenvolvimento. Veremos depois qual deverá ser o ajuste na produção.

No template base.html fazemos as alterações (apenas as modificações são mostradas):
templates/base.html

<!DOCTYPE html>
{% load static %}
<html lang="en">
<head>
    <meta charset="UTF-8">
    <link rel="stylesheet" href="{% static'css/estilo.css' %}">
    ...
</head>
...

A tag {% load %} torna disponíveis tags e filtros para esse template. Aqui usamos staticpara dar acesso à URL do arquivo CSS. Alteramos agora
app_notas/notas/views.py

from django.shortcuts import render

def index(request):
    contexto = {'secao':'home', 'mensagem':'Vou colocar outro link aqui!'}
    return render(request,'home.html', contexto)

O dicionário contexto contém variáveis que podem ser usadas dentro de home.html. O nome da variável é passado como string. Alteramos o template base para receber essas variáveis:
templates/base.html

<body>
  <ul class="menu">
    <li><a class="{% if secao=='home' %} active {% endif %}
    "href=" {% url 'index' %}">Início</a></li>
    <li>{{ mensagem }}</li>
  </ul>
  {% block title %}

Esse código faz o seguinte: se secao == 'home' o primeiro ítem da lista terá classe active com formatação definida no arquivo CSS. A variável mensagem = 'Vou colocar...' foi usada para demonstração e se torna o segundo ítem da lista. O conteúdo da variável mensagem é servido para o html com a sintaxe {{ mensagem }}. O resultado será uma exibição formatada na navegador.

Se o link sublinhado for clicado a mesma página será carregada. Claro que o link pode se referir a qualquer outra página.

Você pode ver o que foi carregado olhando page source (CTRL-U, no firefox). Nessa página um clique em estilo.css deverá exibir os estilos.

Pode ocorrer que você faça alterações no arquivo css e elas não se reflitam na renderização do navegador, mesmo após um recarregamento. Isso provavelmente ocorre porque o navegador coloca em cache parte das informações recebidas pelo servidor. Isso pode ser resolvido forçando o navegador a ver o arquivo de estilo como um novo arquivo. Para isso colocamos um parâmetro após o nome do estilo:
<link rel="stylesheet" href="{% static 'css/estilo.css' %}?v=1">.

Modelos

Até agora não mencionamos como o django lida com o gerenciamento dos dados a serem servidos nos aplicativos. Essa é a parte de construção, gerenciamento e leitura em bancos de dados. Continuaremos com nosso banco de dados do SQlite, que não exige uma instalação específica de servidor de dados.

Modelos estão definidos no django em django.db.models. Para usá-los criamos subclasses desse classe. Editamos o arquivo de modelos:
notas/model.py

from django.db import models

class Nota(models.Model):
    titulo = models.CharField(default='', max_length=150)
    texto = models.TextField(default='', blank=True)
    slug = models.SlugField(default='', blank=True, max_length=255)

    def __str__(self):
        return self.titulo

O django tem código pré-definido para transformar essas definições em modificações no banco de dados. Isso é feito com os comandos manage.py makemigrations e manage.py migrate, que já utilizaremos. Quase sempre cada modelo representa uma tabela no BD. No nosso caso definimos um campo titulo, de texto com comprimento máximo de 150 caracteres, e um campo texto, de texto sem comprimento definido e que pode ser gravada vazia. O campo slug será destinados a armazenar partes das URLs de acesso a cada nota. Todos eles tem uma string vazia como valor default e pode conter apenas caracteres, números, hífens e sublinhados.

O método __str__ define o que será usado como representação da classe. Por exemplo print(Nota) imprimirá o título da nota. Ids são definidos automaticamente.

Vamos primeiro registrar esse modelo para ser usado com o app admin.py, pre-definido pelo django e ainda não usado por nós.

notas/admin.py
notas/admin.py

from django.contrib import admin
from blog.models import Nota

admin.site.register(Nota)

Feito isso podemos aplicar as alterações no bando de dados.

$ python manage.py makemigrations
$ python manage.py migrate
$ python manage.py createsuperuser
# caso se necessite trocar a senha usamos:
$ python manage.py changepassword <nome_do_usuário>

O comando makemigrations interpreta as modificações feitas em código e as armazena na pasta notas/migrations. Elas serão usadas mais tarde para aplicar as mesmas modificações na fase de produção. Quando usamos o comando migrate as alterações são aplicadas no SQlite. Se o arquivo app_notas/db.sqlite3 for inspecionado (por exemplo com o DB Browser for SQLite) veremos que estão armazenadas as estrutura da tabela notas, como mostra a figura.

Com createsuperuser se abre um diálogo para inserirmos nome, email e password de um superuser que gerenciará o admin, com todas as permissões, por default.

Se você carregar o servidor com python manage.py runserver e abrir a navegador em http://127.0.0.1:8000/admin/ verá uma página de administração do site, com possibilidade de gerenciar grupos e usuários, tudo predefinido pelo django. Além disso temos acesso para operações de CRUD da tabela Notas.

Nesse ponto, como um exercício, abra o gerenciador e faça inserções de notas no aplicativo. Observe que alguma validação é feita, por exemplo impedindo que gravemos uma nota sem título.

Link para Admin

Para acessar a página do admin sem necessitar escrever uma url completa para isso vamos alterar o arquivo base.hmtl e inserir nele esse link.
app_notas/templates/base.hmtl

<body>
  <ul class="menu">
    <li><a class="{% if secao == 'home' %} active {% endif %}"
    href=" {% url 'index' %}">Início</a></li>
    <li><a href="/admin/">Admin</a></li>
  </ul>
  ...

Exibimos aqui apenas a lista não ordenada que representa o nosso menu. Agora basta clicar no link Admin no cabeçalho para acessar o gerenciador.

Exibindo dados

Se você entrou dados no banco de dados usando a página de admin agora você pode exibí-las em seu site. Para isso modificamos views.py.
app_notas/notas/views.py

from django.shortcuts import render
from .models import Nota

def index(request):
    notas = Nota.objects.all()
    contexto = {'secao':'home', 'mensagem':'Item de Menu', 'notas': notas,}
    return render(request, 'home.html', contexto)

O método Nota.objects.all() faz o acesso ao banco de dados e retorna uma QuerySet com todos os campos nele registrados. Esse código é internamente transformados em consultas sql que são submetidas ao banco de dados. Outros tipos de consulta são possíveis, com filtros e ordenamentos. O resultado da consulta, armazenado em notas, é passado em contexto para o template.

Prosseguindo, home.html deve ser modificado para receber e exibir as notas passadas em contexto.
app_notas/templates/home.html

{% extends "base.html" %}
{% block title %}
  <h1>Aplicativo de Notas</h1>
{% endblock %}

{% block content %}
  <h1>Página inicial</h1>
  <p>Essas são as minhas notas.</p>
  <ul>
  {%for nota in notas %}
    <li>{{ nota.pk }}: {{ nota }}</li>
  {%endfor%}
  </ul>
{% endblock %}

Observe que {{ nota }} exibirá a representação default do objeto, que é seu título. {{ nota.pk }} é o id (uma primary key, que poderá ser usada para identificar uma nota individual.

O navegador agora exibe, além do cabeçalho anterior, a lista contendo ids e títulos de notas (que digitei na página do admin):

Exibindo dados do Banco de Dados

Um passo adicional para melhorar nosso aplicativo consiste em exibir detalhes de uma nota selecionada pelo usuário. Para fazer isso vamos começar alterando notas/models.py.
app_notas/notas/models.py

from django.db import models
from django.urls import reverse
from django.utils.text import slugify

class Nota(models.Model):
    titulo = models.CharField(default='', max_length=150)
    texto = models.TextField(default='', blank=True)
    slug = models.SlugField(default='', blank=True, max_length=255)
    
    def __str__(self):
        return self.titulo

    def save(self,*args,**kwargs):
        self.slug = slugify(self.title)
        super().save(*args,**kwargs)
        
    def get_absolute_url(self):
        return reverse('blog:detail', args=[str(self.slug)])

Nas partes inseridas (em negrito) sobreescrevemos o método save para executar código customizado antes que o objeto seja armazenado em banco de dados. O método super().save() se refere ao método de gravação definido na classe mãe.

A função slugify converte strings para uma forma de slug. Por exemplo: A string “Um Curso sobre Django” será transformado em “um-curso-sobre-django” e esse slug será usado nas URLs.

O método get_absolute_url() retorna a URL padrão para um objeto, usando reverse que considera a view usada e a slug.

Antes de executar o código de acesso ao detalhe das notas verifique se todas as slugs estão preenchidas, usando a página de Admin.

Vamos criar duas entradas de URLs em urls.py, para encontrar uma nota através de sua slug ou por meio de seu id (aqui chamado de pk, ou primary key).
notas/urls.py

from django.urls import path
from . import views

urlpatterns = [
    path('', views.index, name='index'),
    path('index', views.index, name='index2'),
    path('slug/<slug:slug>/', views.detalhe, name='detalhe'),
    path('nota/<int:pk>/', views.detalhePK, name='detalhe2'),
]

Agora, se digitarmos http://127.0.0.1:8000/slug/django/ o slug (a palavra django, nesse caso) será capturado e enviado para a views.detalheSLUG. Digitando, por ex., http://127.0.0.1:8000/nota/1/, o pk=1 será enviando para views.detalhePK. Precisamos criar então essas views:
app_notas/notas/views.py

from django.shortcuts import render, get_object_or_404
from .models import Nota

def index(request):
    notas = Nota.objects.all()
    contexto = {'secao':'home', 'mensagem':'Item de Menu', 'notas': notas,}
    return render(request, 'home.html', contexto )

def detalheSLUG(request, slug):
    nota = get_object_or_404(Nota, slug=slug)
    contexto = {'secao':'detalhe', "nota": nota,}
    return render(request, "detalhe.html", contexto)

def detalhePK(request, pk):
    nota = get_object_or_404(Nota, pk=pk)
    contexto = {'secao':'detalhe', "nota": nota,}
    return render(request, "detalhe.html", contexto)    

O método get_object_or_404() é um atalho que executa as operações de get(), fazendo a busca e retornando o objeto procurado ou levantando uma exceção Http404 se o objeto não existir.

Finalmente gravamos template detalhe.html que receberá e exibirá esses dados:
app_notas/templates/detalhe.html

{% extends "base.html" %}
{% block title %}
  <h1>Aplicativo de Notas: Detalhes</h1>
{% endblock %}

{% block content %}
  <h1>Detalhe de uma nota</h1>
  <h2>Nota: {{ nota.titulo }}</h2>
  <p>{{ nota.texto }}</p>
  <p><small>Id: {{ nota.pk }} Slug: {{ nota.slug }}</small></p>
{% endblock %}

Agora, digitando http://127.0.0.1:8000/django/ na barra de endereços do navegador temos:

Digitando http://127.0.0.1:8000/nota/1/ temos:

Essas exibições no navegador assumem que existem notas com os títulos, ids e slugs mostrados, além do texto da nota. Observe que as tags html não estão renderizadas como tal, ou seja, as quebras de linhas são representados como <br>, e não como quebras de fato. Isso ocorre porque o django faz escape de tags, por motivo de segurança. Para que tags sejam passadas e exibidas podemos inserir o filtro {{ variavel|safe }}.

Modifique detalhe.hmtl (exibindo somente o bloco de conteúdo):
app_notas/templates/detalhe.html

{% block content %}
  <h1>Detalhe de uma nota</h1>
  <h2>Nota: {{ nota.titulo }}</h2>
  <p>{{ nota.texto|safe }}</p>
  <p><small>Id: {{ nota.pk }} Slug: {{ nota.slug }}</small></p>
{% endblock %}

Agora visitando a url http://127.0.0.1:8000/nota/1/ veremos:

Claro que não se pode esperar que usuários conheçam as slugs ou ids de uma nota. Esse dado deve ser obtido dentro do próprio aplicativo. Vamos fazer isso alterando home.html. Abaixo está exibido apenas o código dentro de block content:
app_notas/templates/home.html

{% block content %}
  <h1>Página inicial</h1>
  <p>Essas são as minhas notas (clique para visualizar).</p>
  <ul>
  {%for nota in notas %}
    <li><a href="/nota/{{ nota.pk }}/">{{ nota }}</a></li>
  {%endfor%}
  </ul>
{% endblock %}

Aqui foi feita a alteração, na listagem das notas apresentadas: ao invés de apenas listar os ids ele é usado para construir a url href="/nota/{{ nota.pk }}/.
Por motivo didático construimos duas views para receber slugs ou ids. Poderíamos ter construido uma única view que separe parâmetros inteiros (pk) de strings (slugs).

Se uma URL for inserida em busca de um id ou slug não existente uma tela de erros aparece, indicando onde está o erro. Podemos, e devemos, capturar esse erro indicando ao usuário que a busca não foi bem sucedida. Para isso alteramos o arquivo
app_notas/notas/views.py

def detalheSLUG (request, slug):
    try:
        nota = get_object_or_404(Nota, slug=slug)
        contexto = {'secao':'detalhe', 'nota': nota,}
    except:
        contexto = {'secao':'erro', 'nota': 'Nota não encontrada!',}
    return render(request, "detalhe.html", contexto)

def detalhePK (request, pk):
    try:
        nota = get_object_or_404(Nota, pk=pk)
        contexto = {'secao':'detalhe', "nota": nota,}
    except:
        contexto = {'secao':'erro', 'nota': 'Nota não encontrada!',}
    return render(request, "detalhe.html", contexto)    

O template recebe as variáveis de contexto, com um teste para a variável seção:
app_notas/templates/home.html

{% block content %}
  {% if secao == "erro" %}
    <h1>Nenhuma nota foi encontrada!</h1>
    <h2>Nota: {{ nota }}</h2>
  {% else %}
    <h1>Detalhe de uma nota</h1>
    <h2>Nota: {{ nota.titulo }}</h2>
    <p>{{ nota.texto|safe }}</p>
    <p><small>Id: {{ nota.pk }} Slug: {{ nota.slug }}</small></p>
  {% endif %}
{% endblock %}

Agora, se um slug não existente for digitado, a mensagem é exibida:

Observe que os espaços em torno do comparador “==” devem ser mantidos em {% if secao == "erro" %}, ou um erro será lançado.

Artigos Django

1- Django, Websites com Python
2- Django, um Projeto (esse artigo)
3- Django, incrementando o Projeto

Bibliografia

Consulte a bibliografia no artigo inicial.

Leave a Reply

Your email address will not be published. Required fields are marked *