..
.. META INFORMATION OF TRANSLATION
..
.. $TranslationStatus: Done, waiting for revision $
.. $OriginalRevision: 11332 $
.. $TranslationAuthors: Robson Mendonça $
..
.. INFO OF THIS FILE (DO NOT EDIT! UPDATED BY SUBVERSION)
..
.. $HeadURL$
.. $LastChangedRevision$
.. $LastChangedBy$
.. $LastChangedDate$
..
================
Escrevendo Views
================
Uma função view, ou somente *view*, é simplesmente uma função Python que recebe
uma requisição Web e retorna uma resposta Web. Esta resposta pode ser um
conteúdo HTML de uma página, ou um redirecionamento, ou um erro 404, ou um
documento XML, ou uma imagem . . . ou qualquer coisa, na verdade. O view em si
contém qualquer lógica arbitrária que é necessária para retornar uma resposta.
Este código pode ficar em qualquer lugar que você quiser, ao longo do seu Python
path. Não há outro requerimento -- sem "mágica", por assim dizer.
Por uma questão de colocar o código "em qualquer lugar", vamos criar um arquivo
chamado ``views.py`` no diretório ``mysite``, que você criou no capítulo
anterior.
Um view simples
===============
Aqui há um view que retorna a data atual, como um documento HTML:
.. code-block:: python
from django.http import HttpResponse
import datetime
def current_datetime(request):
now = datetime.datetime.now()
html = "
It is now %s." % now
return HttpResponse(html)
Vamos passo-a-passo através deste código, uma linha por vez:
* Primeiro, nós importamos a classe ``HttpResponse``, que reside o módulo
``django.http``, também a biblioteca ``datetime`` do Python.
* Depois, nós definimos uma função chamada ``current_datetime``. Esta é a
função view. Cada função view recebe um objeto ``HttpRequest`` como seu
primeiro parâmetro, que é tipicamente nomeado como ``request``.
Note que o nome da função view não importa; ele não tem de ser nomeada de
uma certa forma para ser reconhecida pelo Django. Nós estamos chamando-a
de ``current_datetime`` aqui, porque este nome indica claramente o que ela
faz.
* O view retorna um objeto ``HttpResponse`` que contém a resposta gerada.
Cada função view é responsável por retornar um objeto ``HttpResponse``.
(Há exceções, mas serão abordadas mais tarde.)
.. admonition:: Django's Time Zone
O Django inclui uma configuração de ``TIME_ZONE`` que por padrão é
``America/Chicago``. Este provavelmente não é onde você mora, então você
pode mudá-lo no seu arquivo ``settings.py``.
Mapeando URLs para Views
========================
Então, para recapitular, esta função view retorna uma página HTML, que inclui a
data e hora atual. Para mostrar este view numa URL em particular, você precisará
criar uma no *URLconf*; veja :doc:`/topics/http/urls` para instruções.
Retornando erros
================
Retornar códigos de erro HTTP no Django é muito fácil. Existem subclasses do
:class:`~django.http.HttpResponse` para um número de códigos de status comuns do
HTTP além do 200 (que significa *"OK"*). Você pode encontrar a lista completa de
subclasses disponíveis na documentação de :ref:`requisição/resposta
`. Somente retorne um instância de uma destas
subclasses ao invés de uma classe normal :class:`~django.http.HttpResponse` a
fim de mostrar um erro. Por exemplo::
def my_view(request):
# ...
if foo:
return HttpResponseNotFound('Page not found
')
else:
return HttpResponse('Page was found
')
Não existe uma subclasse especializada para cada código resposta HTTP possível,
uma vez que muitos deles não serão comuns. Porém, como documentado na
documentação do :class:`~django.http.HttpResponse`, você também pode passar o
código de status HTTP dentro de um construtor do
:class:`~django.http.HttpResponse` para criar uma classe de retorno para
qualquer código de status que você quiser. Por exemplo::
def my_view(request):
# ...
# Retorna um código de resposta "created" (201).
return HttpResponse(status=201)
Como erros 404 são de longe os erros HTTP mais comuns, existe uma forma mais
fácil de manipular estes erros.
A exceção Http404
-----------------
Quando você retorna um erro como ``HttpResponseNotFound``, você é responável por
definir o HTML da página de erro resultante::
return HttpResponseNotFound('Page not found
')
Por convenção, e porque é uma boa idéia ter uma página de erro 404 consistente
para todo site, o Django provê uma exceção ``Http404``. Se você lançar um
``Http404`` em qualquer ponto de sua função view, o Django a pegará e retornará
a página de erro padão para sua aplicação, junto com o código de erro HTTP 404.
Example usage::
from django.http import Http404
def detail(request, poll_id):
try:
p = Poll.objects.get(pk=poll_id)
except Poll.DoesNotExist:
raise Http404
return render_to_response('polls/detail.html', {'poll': p})
A fim de usar a exceção ``Http404`` para sua satisfação, você deve criar um
template que será mostrado quando um erro 404 é gerado. Este template deve ser
chamado ``404.html`` e localizado no nível mais alto de sua árvore de templates.
Customizando erros de views
===========================
O view 404 (page not found)
---------------------------
Quando você gera uma exceção ``Http404``, o Django carrega um view especial
devotado a manipular erros 404. Por padrão, ele é o view
``django.views.defaults.page_not_found``, que carrega e renderiza o template
``404.html``.
Isto significa que você precisa definir um template ``404.html`` na raiz do seu
diretório de templates. Este template será usado para todos os erros 404.
Esta view ``page_not_found`` deve bastar para 99% das aplicações Web, mas se
você precisa sobrescrevê-lo, você pode especificar ``handler404`` no seu
URLconf, desta forma::
handler404 = 'mysite.views.my_custom_404_view'
Por trás das cenas, o Django obriga o view 404 a procurar por ``handler404``.
Por padrão, os URLconfs contém as seguinte linha::
from django.conf.urls.defaults import *
Que se preocupa com a configuração do ``handler404`` no módulo atual. Como você
pode ver em ``django/conf/urls/defaults.py``, ``handler404`` é setado para
``'django.views.defaults.page_not_found'`` por padrão.
Three things to note about 404 views:
* O view 404 é também chamado se o Django não encontrar uma combinação
depois de checar todas as expressões regulares no URLconf.
* Se você não definir se próprio view 404 -- e simplesmente usar o padrão,
o que é recomendado -- você ainda tem uma obrigação: você deve criar um
template ``404.html`` na raiz do seu diretório de templates. Por padrão, o
view 404 usará este template para todos os erros 404. Por padrão, o view
404 passará uma variável para o template: ``request_path``, que é a URL
que resultou no erro 404.
* Ao view 404 é passado um ``RequestContext`` e terá acesso a variáveis
fornecidas por sua configuração ``TEMPLATE_CONTEXT_PROCESSORS`` (e.g.,
``MEDIA_URL``).
* Se ``DEBUG`` é setado como ``True`` (no seu módulo settings), então seu
view 404 nunca será usado, e o traceback será mostrado no lugar dele.
O view 500 (server error)
-------------------------
Similarmente, o Django executa um comportamente especial no caso de um erro de
execução no código do view. Se um view resulta num exceção, o Djanto irá, por
padrão, chamar o view ``django.view.defaults.server_error``, que carrega e
renderiza o template ``500.html``.
Isto significa que você precisa definir um template ``500.html`` na raiz do seu
diretório de templates. Este template será usado para todos os erros de
servidor. O view 500 padrão não passa variáveis para este template e é
renderizado com um ``Context`` vazio para reduzir as chances de erros
adicionais.
Este view ``server_error`` deve bastar para 99% das aplicações Web, mas se você
quiser sobrescrever o view, você pode especificar ``handler500`` no seu URLconf,
desta forma::
handler500 = 'mysite.views.my_custom_error_view'
Por trás das cenas, o Django obriga o view de erro a prcurar pelo
``handler500``. Por padrão, os URLconfs contém a seguinte linha::
from django.conf.urls.defaults import *
Que se preocupa de setar ``handler500`` no módulo atual. Como você pode ver em
``django/conf/urls/defaults.py``, ``handler500`` é setado para
``'django.views.defaults.server_error'`` por padrão.