{"title":"Escrevendo seu primeiro app Django, parte 7","version":"2.1","locale":"pt-br","docname":"intro/tutorial07","url":"/pt-br/2.1/intro/tutorial07/","canonical":"https://djangodocs.dev/pt-br/2.1/intro/tutorial07/","summary":"Esse tutorial começa de onde o Tutorial 6 parou. Estamos continuando a aplicação Web para enquetes e focaremos na customização do site administrativo…","html":"

Escrevendo seu primeiro app Django, parte 7Link para este cabeçalho#

\n

Esse tutorial começa de onde o Tutorial 6 parou. Estamos continuando a aplicação Web para enquetes e focaremos na customização do site administrativo automaticamente gerado pelo Django que exploramos no Tutorial 2.

\n
\n

Personalize o formulário do site de administraçãoLink para este cabeçalho#

\n

Ao registrarmos o model de Question``através da linha ``admin.site.register(Question), o Django constrói um formulário padrão para representá-lo. Comumente, você desejará customizar a apresentação e o funcionamento dos formulários do admin do Django. Para isto, você precisará informar ao Django as opções que você quer utilizar ao registrar o seu modelo.

\n

Vamos ver como isto funciona reordenando os campos no formulário de edição. Substitua a linha àdmin.site.register(Question)` por:

\n
polls/admin.py
\n
Python
from django.contrib import admin\n\nfrom .models import Question\n\n\nclass QuestionAdmin(admin.ModelAdmin):\n    fields = ['pub_date', 'question_text']\n\nadmin.site.register(Question, QuestionAdmin)\n
\n

Você seguirá este padrão – crie uma classe do modelo admin, em seguida, passe-a como o segundo argumento para o admin.site.register() – todas as vezes que precisar alterar as opções administrativas para um modelo.

\n

Essa mudança específica no código acima faz com que a “Publication date” apareça antes do campo “Question”:

\n\"Fields\n

Isso não é impressionante com apenas dois campos, mas para formulários com dúzias deles, escolher uma ordem intuitiva é um detalhe importante para a usabilidade.

\n

E por falar em dúzias de campos, você pode querer dividir o formulário em grupos:

\n
polls/admin.py
\n
Python
from django.contrib import admin\n\nfrom .models import Question\n\n\nclass QuestionAdmin(admin.ModelAdmin):\n    fieldsets = [\n        (None,               {'fields': ['question_text']}),\n        ('Date information', {'fields': ['pub_date']}),\n    ]\n\nadmin.site.register(Question, QuestionAdmin)\n
\n

O primeiro elemento de cada tupla em fieldsets é o título do grupo. Aqui está como o nosso formulário se parece agora:

\n\"Form\n
\n\n
\n

Personalize a listagem da página de administraçãoLink para este cabeçalho#

\n

Agora que a página de administração de Pergunta está bonita, vamos fazer algumas melhorias à página “change list” – aquela que exibe todas as enquetes do sistema.

\n

Aqui é como ela está até agora:

\n\"Polls\n

Por padrão, o Django mostra o str() de cada objeto. Mas algumas vezes seria mais útil se pudéssemos mostrar campos individuais. Para fazer isso, use a opção list_display, que é uma tupla de nomes de campos a serem exibidos, como colunas, na lista de mudança dos objetos:

\n
polls/admin.py
\n
Python
class QuestionAdmin(admin.ModelAdmin):\n    # ...\n    list_display = ('question_text', 'pub_date')\n
\n

Apenas bom demais para mensurar, vamos também incluir o método was_published_recently() do Tutorial 2:

\n
polls/admin.py
\n
Python
class QuestionAdmin(admin.ModelAdmin):\n    # ...\n    list_display = ('question_text', 'pub_date', 'was_published_recently')\n
\n

Agora a página de edição de enquetes está assim:

\n\"Polls\n

Você pode clicar no cabeçalho da coluna para ordená-las por estes valores – exceto no caso do was_published_recently, porque a ordenação pelo resultado de um método arbitrário não é suportada. Também note que o cabeçalho da coluna\npara was_published_recently é, por padrão, o nome do método (com underscores substituídos por espaços), e que cada linha contem a representação da saída.

\n

Você pode melhorar isso adicionando ao método (em polls/models.py) alguns atributos, como segue:

\n
polls/models.py
\n
Python
class Question(models.Model):\n    # ...\n    def was_published_recently(self):\n        now = timezone.now()\n        return now - datetime.timedelta(days=1) <= self.pub_date <= now\n    was_published_recently.admin_order_field = 'pub_date'\n    was_published_recently.boolean = True\n    was_published_recently.short_description = 'Published recently?'\n
\n

Para obter mais informações sobre essas propriedades de método, veja :attr:`~django.contrib.admin.ModelAdmin.list_display.

\n

Edite o arquivo polls/admin.py de novo e adicione uma melhoria à página de lista de edição Question: Um filtro usando list_filter. Adicione a seguinte linha ao QuestionAdmin:

\n
Code
list_filter = ['pub_date']\n
\n

Isso adiciona uma barra lateral “Filter” que permite às pessoas filtrarem a lista de edição pelo campo pub_date:

\n\"Polls\n

O tipo do filtro apresentado depende do tipo do campo pelo qual você está filtrando. Por conta de pub_date ser uma instância da classe DateTimeField, o Django consegue deduzir que os filtros apropriados são: “Qualquer data”, “Hoje”, “Últimos 7 dias”, “Esse mês”, “Esse ano”.

\n

Isso está ficando bom. Vamos adicionar capacidade de pesquisa:

\n
Code
search_fields = ['question_text']\n
\n

Isso adiciona um campo de pesquisa ao topo da lista de edição. Quando alguém informa termos de pesquisa, o Django irá pesquisar o campo question_text. Você pode usar quantos campos quiser – entretanto, por ele usar uma consulta LIKE internamente, limitar o número de campos de pesquisa a um número razoável, será mais fácil para o seu banco de dados para fazer pesquisas.

\n

Agora é também uma boa hora para observar que a página de edição fornece uma paginação gratuitamente. O padrão é mostrar 100 itens por página. Paginação da página de edição, campos de pesquisa, filters, hierarquia por data, e ordenação por cabeçalho de\ncoluna todos trabalham em sincronia como deveriam.

\n
\n
\n

Personalize a aparência do site de administraçãoLink para este cabeçalho#

\n

Obviamente, ter “Django administration” no topo de cada página de administração é ridículo. Isso é só um texto de exemplo.

\n

É fácil de editar, no entanto, usando o sistema de templates do Django. A página de administração de Django é feita com o próprio Django e conseqüentemente sua interface usa\no sistema de templates nativo do Django.

\n
\n

Personalizando os templates do seu projetoLink para este cabeçalho#

\n

Criar um diretório templates no diretório do seu projeto (aquela que contém manage.py). Os modelos podem viver em qualquer lugar em seu sistema de arquivos que o Django possa acessar. (Django é executado como qualquer usuário que seu servidor é executado.) No entanto, manter seus templates dentro do projeto é uma boa convenção a seguir.

\n

Abra seu arquivo de configurações (mysite/settings.py, lembre-se) e adicione uma opção DIRS. na configuração TEMPLATES setting:

\n
mysite/settings.py
\n
Python
TEMPLATES = [\n    {\n        'BACKEND': 'django.template.backends.django.DjangoTemplates',\n        'DIRS': [os.path.join(BASE_DIR, 'templates')],\n        'APP_DIRS': True,\n        'OPTIONS': {\n            'context_processors': [\n                'django.template.context_processors.debug',\n                'django.template.context_processors.request',\n                'django.contrib.auth.context_processors.auth',\n                'django.contrib.messages.context_processors.messages',\n            ],\n        },\n    },\n]\n
\n

DIRS é uma lista de diretórios de arquivos que serão checados quando o Django carregar seus templates, ou seja, caminhos de busca.

\n\n

Agora crie um diretório chamado admin dentro de templates, e copie o template admin/base_site.html de dentro do diretório padrão do site de administração do Django (django/contrib/admin/templates) para dentro deste diretório.

\n\n

Então, apenas edite o arquivo e substitua {{ site_header|default:_('Django administration') }} (incluindo as chaves) com nome do seu próprio site como desejar. Você deve acabar com uma secção de código como:

\n
Django template
{% block branding %}\n<h1 id="site-name"><a href="{% url 'admin:index' %}">Polls Administration</a></h1>\n{% endblock %}\n
\n

Nós usamos esta abordagem para ensinar-lhe como substituir templates. Em um projeto real, você provavelmente usaria o atributo django.contrib.admin.AdminSite.site_header para fazer mais facilmente essa personalização em particular.

\n

Esse template contém uma série de textos como {% block branding %} e {{ tittle }}. As tags {% e {{ fazem pate da linguagem de templates do Django. Quando o Django renderiza o template “admin/base_site.html”, o seu conteúdo é processado por essa linguagem de templates para produzir a página HTML final, assim como vimos no Tutorial 3.

\n

Note que qualquer template padrão do sire de administração pode ser sobrescrito. Para sobrescrever um template, apenas faça a mesma coisa que você fez com base_site.html – copie ele do diretório padrão para o seu próprio diretório, e faça as mudanças.

\n
\n
\n

Personalizando templates da sua aplicaçãoLink para este cabeçalho#

\n

Leitores astutos irão se perguntar: Mas se DIRS estava vazio por padrão, como o Django pôde encontrar o diretório padrão dos templates do site de administração? A resposta é, Desde que APP_DIRS seja True, o Django irá automaticamente procurar por um subdiretório templates/ dentro de cada pacote de aplicação, para usar como fallback(Não esqueça que django.contrib.admin é uma aplicação)

\n

Nossa aplicação enquete não é muito complexa e não precisa de templates personalizados para o site de administração. Mas se ele crescer e ficar mais sofisticado e necessária a modificação dos templates padrão de administração do Django para algumas de suas funcionalidades, seria mais sensato modificar os templates da aplicação, e não os do projeto. Dessa forma, você poderia incluir a aplicação de enquete em qualquer novo projeto e ter a certeza que iria encontrar os modelos personalizados que você precisa.

\n

Veja a documentação de carga de template - para mais informação sobre como o Django acha seus templates.

\n
\n
\n
\n

Personalize a página inicial do site de administraçãoLink para este cabeçalho#

\n

De maneira similar, você pode querer personalizar a aparência da página inicial do site de administração do Django.

\n

Por padrão, ele exibe todas as aplicações em INSTALLED_APPS, que estão registrados na aplicação de administração, em ordem alfabética. E você pode querer fazer alterações significativas no layout. Além do que, a página inicial é provavelmente a página mais importante da página de administração, e deve ser fácil de usar.

\n

O template para personalizar é admin/index.html. (Faça o mesmo que admin/base_site.html na seção anterior – copie ele do diretório padrão para o seu diretório de template personalizado). Edite o arquivo e você verá que ele usa uma variável de template chamada app_list. Esta variável contém cada app instalada no Django. Ao invés de usar isto, você pode criar links hard-coded para páginas do admin específicas em qualquer forma que você achar melhor.

\n
\n
\n

E agora?Link para este cabeçalho#

\n

O tutorial dos iniciantes termina aqui. Entretanto, você pode querer verificar alguns indicadores em onde ir partindo daqui.

\n

Se você é familiar ao sistema de empacotamento Python e está interessado em como tornar a enquete em uma “app reusável”, veja Tutorial avançado: como escrever apps reusáveis.

\n
","rootId":"writing-your-first-django-app-part-7","toc":[{"title":"Personalize o formulário do site de administração","anchor":"customize-the-admin-form","children":[]},{"title":"Adicionando objetos relacionados","anchor":"adding-related-objects","children":[]},{"title":"Personalize a listagem da página de administração","anchor":"customize-the-admin-change-list","children":[]},{"title":"Personalize a aparência do site de administração","anchor":"customize-the-admin-look-and-feel","children":[{"title":"Personalizando os templates do seu projeto","anchor":"customizing-your-project-s-templates","children":[]},{"title":"Personalizando templates da sua aplicação","anchor":"customizing-your-application-s-templates","children":[]}]},{"title":"Personalize a página inicial do site de administração","anchor":"customize-the-admin-index-page","children":[]},{"title":"E agora?","anchor":"what-s-next","children":[]}],"breadcrumbs":[{"docname":"intro/index","title":"Introdução","url":"/pt-br/2.1/intro/"}],"prev":{"docname":"intro/tutorial06","title":"Escrevendo sua primeira aplicação Django, parte 6","url":"/pt-br/2.1/intro/tutorial06/"},"next":{"docname":"intro/reusable-apps","title":"Tutorial avançado: Como escrever aplicações reutilizáveis","url":"/pt-br/2.1/intro/reusable-apps/"},"formats":{"html":"/pt-br/2.1/intro/tutorial07/","markdown":"/pt-br/2.1/intro/tutorial07.md","json":"/pt-br/2.1/intro/tutorial07.json"},"source":"https://github.com/django/django/blob/stable/2.1.x/docs/intro/tutorial07.txt","official":"https://docs.djangoproject.com/pt-br/2.1/intro/tutorial07/","inVersions":["6.1","6.0","5.2","5.1","5.0","4.2","4.1","4.0","3.2","3.1","3.0","2.2","2.1","2.0","1.11","1.10","1.9"],"inLocales":["en","zh-hans","fr","ja","id","pt-br","ko","es","el","pl"]}