Partilhar via


Etapa 4: Usar o modelo Projeto Web do Django completo

Etapa anterior: Fornecer arquivos estáticos, adicionar páginas e usar a herança do modelo

Agora que explorou as noções básicas do Django no Visual Studio, você compreende facilmente o aplicativo mais completo produzido pelo modelo "Projeto Web do Django".

Nesta etapa, você:

  • Criar um aplicativo Web do Django mais completo usando o modelo "Projeto Web do Django" e examinar a estrutura do projeto (etapa 4-1)
  • Entender os modos de exibição e os modelos de página criados pelo modelo de projeto, que consistem em três páginas que são herdadas a partir de um modelo de página de base e que emprega bibliotecas JavaScript estáticas como jQuery e Bootstrap (etapa 4-2)
  • Entender o roteamento de URL fornecido pelo modelo (etapa 4-3)

O modelo também fornece a autenticação básica, que é abordada na Etapa 5.

Etapa 4-1: Criar um projeto com base no modelo

  1. No Visual Studio, acesse o Gerenciador de Soluções, clique com o botão direito do mouse na solução LearningDjango criada anteriormente neste tutorial. Em seguida, selecione Adicionar>Novo Projeto. (Se você quiser usar uma nova solução, selecione Arquivo>Novo>Projeto).

  2. Na caixa de diálogo Novo Projeto, pesquise e selecione o modelo Projeto Web do Django. Chame o projeto de "DjangoWeb" e selecione Criar.

  3. Como o modelo inclui um arquivo requirements.txt, o Visual Studio solicita o local onde instalar as dependências. Quando solicitado, escolha a opção Instalar em um ambiente virtual e na caixa de diálogo Adicionar Ambiente Virtual selecione Criar para aceitar os padrões.

  4. Quando o Visual Studio concluir a configuração do ambiente virtual, siga as instruções exibidas no arquivo readme.html para criar um superusuário do Django (ou seja, um administrador). Clique com o botão direito do mouse no projeto do Visual Studio e selecione o comando Python>Criar Superusuário do Django e, em seguida, siga os prompts. Registre seu nome de usuário e a senha que você usa ao exercitar os recursos de autenticação do aplicativo.

  5. Defina o projeto DjangoWeb como o padrão para a solução do Visual Studio clicando com o botão direito do mouse no projeto em Gerenciador de Soluções e selecionando Definir como Projeto de Inicialização. O projeto de inicialização, mostrado em negrito, é executado quando você inicia o depurador.

    Solution Explorer showing the DjangoWeb project as the startup project.

  6. Selecione Depurar>Iniciar depuração (F5) ou use o botão Servidor Web na barra de ferramentas para executar o servidor.

    Run web server toolbar button in Visual Studio.

  7. O aplicativo criado pelo modelo tem três páginas, Página Inicial, Sobre e Contato. Você pode navegar entre as páginas usando a barra de navegação. Levar um minuto ou dois para examinar as diferentes partes do aplicativo. Para autenticar com o aplicativo por meio do comando Login, use as credenciais de superusuário criadas anteriormente.

    Full browser view of the Django Web Project app.

  8. O aplicativo criado pelo modelo "Projeto Web do Django" usa Bootstrap para layout responsivo que acomoda fatores forma móveis. Para ver essa capacidade de resposta, redimensione o navegador para uma exibição estreita para que o conteúdo seja renderizado verticalmente e a barra de navegação se transforme em um ícone de menu.

    Mobile (narrow) view of the Django Web Project app.

  9. Você pode deixar o aplicativo em execução para as seções a seguir.

    Caso deseje interromper o aplicativo e confirmar as alterações no controle do código-fonte, abra a página Alterações no Team Explorer, clique com o botão direito do mouse na pasta do ambiente virtual (provavelmente env) e selecione Ignorar estes itens locais.

Examine o que o modelo cria

No nível mais amplo, o modelo "Projeto Web do Django" cria a seguinte estrutura:

  • Arquivos na raiz do projeto:
    • manage.py: o utilitário administrativo do Django.
    • db.sqlite3: um banco de dados SQLite padrão.
    • requirements.txt: contém uma dependência do Django 1.x.
    • readme.html: um arquivo exibido no Visual Studio após a criação do projeto. Conforme observado na seção anterior, siga as instruções aqui para criar uma conta de superusuário (administrador) para o aplicativo.
  • A pasta app contém todos os arquivos do aplicativo, incluindo exibições, modelos, testes, formulários, modelos e arquivos estáticos (veja a etapa 4-2). Normalmente, você renomeia esta pasta para usar um nome de aplicativo mais diferenciado.
  • A pasta DjangoWeb (projeto do Django) contém os arquivos de projeto típicos do Django: __init__.py, settings.py, urls.py e wsgi.py. O arquivo settings.py já está configurado para o aplicativo e o arquivo de banco de dados usando o modelo de projeto. O arquivo urls.py também já está configurado com as rotas para todas as páginas do aplicativo, incluindo o formulário de entrada.

Pergunta: É possível compartilhar um ambiente virtual entre projetos do Visual Studio?

Resposta: Sim, no entanto, faça isso com a consciência de que projetos diferentes provavelmente usam pacotes diferentes ao longo do tempo. Portanto, um ambiente virtual compartilhado precisa conter todos os pacotes para todos os projetos que o usam.

No entanto, para usar um ambiente virtual existente, siga estas etapas:

  1. Quando for solicitado a instalar dependências no Visual Studio, selecione a opção Eu os instalarei por conta própria opção.
  2. No Gerenciador de Soluções, clique com o botão direito do mouse no nó Ambientes do Python e escolha Adicionar Ambiente Virtual Existente.
  3. Navegue até e selecione a pasta que contém o ambiente virtual e selecione OK.

Etapa 4-2: Entender os modos de exibição e os modelos de página criados pelo modelo de projeto

Quando você executa o projeto, observe que o aplicativo contém três modos de exibição: Página inicial, Sobre e Contato. O código dessas exibições é encontrado no arquivo views.py. Cada função de exibição chama django.shortcuts.render com o caminho para um modelo e um objeto de dicionário simples. Por exemplo, a página Sobre é tratada pela função about:

def about(request):
    """Renders the about page."""
    assert isinstance(request, HttpRequest)
    return render(
        request,
        'app/about.html',
        {
            'title':'About',
            'message':'Your application description page.',
            'year':datetime.now().year,
        }
    )

Os modelos estão localizados na pasta templates/app do aplicativo (e, normalmente, você deseja renomear app como o nome do aplicativo real). O modelo base, layout.html, é o mais abrangente. O arquivo layout.html se refere a todos os arquivos estáticos necessários (JavaScript e CSS). O arquivo layout.html também define um bloco chamado "content" que outras páginas substituem e fornece outro bloco chamado "scripts". Os seguintes trechos anotados do arquivo layout.html mostram estas áreas específicas:

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8" />

    <!-- Define a viewport for Bootstrap's responsive rendering -->
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>{{ title }} - My Django Application</title>

    {% load staticfiles %}
    <link rel="stylesheet" type="text/css" href="{% static 'app/content/bootstrap.min.css' %}" />
    <link rel="stylesheet" type="text/css" href="{% static 'app/content/site.css' %}" />
    <script src="{% static 'app/scripts/modernizr-2.6.2.js' %}"></script>
</head>
<body>
    <!-- Navbar omitted -->

    <div class="container body-content">

<!-- "content" block that pages are expected to override -->
{% block content %}{% endblock %}
        <hr/>
        <footer>
            <p>&copy; {{ year }} - My Django Application</p>
        </footer>
    </div>

<!-- Additional scripts; use the "scripts" block to add page-specific scripts.  -->
    <script src="{% static 'app/scripts/jquery-1.10.2.js' %}"></script>
    <script src="{% static 'app/scripts/bootstrap.js' %}"></script>
    <script src="{% static 'app/scripts/respond.js' %}"></script>
{% block scripts %}{% endblock %}

</body>
</html>

Cada um dos modelos de página individual, about.html, contact.html e index.html, estende o modelo base layout.html. O arquivo de modelo about.html é o mais simples e mostra as marcas {% extends %} e {% block content %}:

{% extends "app/layout.html" %}

{% block content %}

<h2>{{ title }}.</h2>
<h3>{{ message }}</h3>

<p>Use this area to provide additional information.</p>

{% endblock %}

Os arquivos de modelo index.html e contact.html usam a mesma estrutura e fornecem mais conteúdo no bloco "conteúdo".

Na pasta templates/app, também se encontra uma quarta página login.html, junto com loginpartial.html, que é inserida em layout.html com {% include %}. Esses arquivos de modelo são discutidos na etapa 5 na autenticação.

Pergunta: {% block %} e {% endblock %} podem ser recuados no modelo de página do Django?

Resposta: Sim. Os modelos de página do Django funcionam bem se você recua as marcas de bloco, talvez para alinhá-las nos elementos pai apropriados. Para exibir claramente onde as marcas de bloco são colocadas, os modelos de página do Visual Studio não recuam as marcas de bloco.

Etapa 4-3: Entender o roteamento de URL criado pelo modelo

O arquivo urls.py do projeto do Django criado pelo modelo "Projeto Web do Django" contém o seguinte código:

from datetime import datetime
from django.urls import path
from django.contrib import admin
from django.contrib.auth.views import LoginView, LogoutView
from app import forms, views

urlpatterns = [
    path('', views.home, name='home'),
    path('contact/', views.contact, name='contact'),
    path('about/', views.about, name='about'),
    path('login/',
         LoginView.as_view
         (
             template_name='app/login.html',
             authentication_form=forms.BootstrapAuthenticationForm,
             extra_context=
             {
                 'title': 'Log in',
                 'year' : datetime.now().year,
             }
         ),
         name='login'),
    path('logout/', LogoutView.as_view(next_page='/'), name='logout'),
    path('admin/', admin.site.urls),
]

Os três primeiros padrões de URL são mapeados diretamente para as exibições home, contact e about no arquivo views.py do aplicativo. Os padrões ^login/$ e ^logout$, por outro lado, usam modos de exibição internos do Django em vez de exibições definidas pelo aplicativo. As chamadas para o método url também incluem dados adicionais para personalizar o modo de exibição. A Etapa 5 explora essas chamadas.

Pergunta: No projeto que criei, por que o padrão de URL "about" usa '^about' em vez de '^about$', como mostrado aqui?

Resposta: A falta do '$' à direita na expressão regular foi um erro simples em várias versões do modelo do projeto. O padrão de URL funciona perfeitamente para uma página chamada "sobre". No entanto, sem o '$' à direita, o padrão de URL também corresponde a URLs como "about=django," "about09876," "aboutoflaughter," e assim por diante. O '$' à direita é mostrado aqui para criar um padrão de URL que corresponde somente a "about".

Próximas etapas

Aprofunde-se um pouco mais