# documentação Django 2.0.8

# Escrevendo “views”

Uma função do tipo “view”, ou “view” em resumo, é 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 Web, ou um redirecionamento, ou um erro 404, ou um documento XML, ou uma imagem … ou qualquer coisa, realmente. A própria “view” contém qualquer lógica arbitrária que seja necessária para retornar a resposta. Este código pode estar em qualquer lugar que queira, contanto que esteja dentro do seu “python path”. Não existe nenhum outro requerimento–sem “mágica”, assim dizendo. Para não colcoarmos o código em qualquer lugar, a convenção é colcoar as “views” em um arquivo chamado `views.py`, colocado dentro do diretório do seu projeto ou da sua aplicação.

## Uma “view” simples.

Aqui uma “view” que retorna a data e hora corrente, como um documento HTML:

    from django.http import HttpResponse
    import datetime

    def current_datetime(request):
        now = datetime.datetime.now()
        html = "<html><body>It is now %s.</body></html>" % now
        return HttpResponse(html)

Vamos passar por este código linha por linha:

- Primeiro, importamos a classe `HttpResponse` do módulo `django.http`, juntamente com a biblioteca `datetime` do Python.

- Próximo, definimos a função chamada `current_datetime`. Esta a função da “view”. Cada função “view” recebe um objeto `HttpRequest` como seu primeiro argumento, o qual é tipicamente chamado `request`.

  Note que o nome da função “view” não importa, essa não tem que ser nominada de uma certa maniera para que o Django as reconheça. Chamaremos aqui de `current_time`, porque este nome claramente indica o que ela faz.

- A “view” retorna um objeto `HttpResponse` que contém a resposta gerada. Cada função “view” é responsável por retornar um objeto da `HttpResponse`. (existem exceções, mas chegaremos lá mais tarde.)

Fuso Horário do Django

O Django inclui uma definição `TIME_ZONE` cujo padrão é `America/Chicago`. Este provavelmente não é onde você mora, então talvez queira mudar isso no seus arquivo de definições.

## Mapiando URLs para “views”

Então, para recaptular, essa função “view” retorna uma página HTML que inclui a data e hora corrente. Para mostrar esta “view” em uma URL em particular, é necessário criar um URLconf; veja Despachante de URL para instruções.

## Retornando erros

É fácil retornar códigos de erros no Django. Existem subclasses de `HttpResponse` para vários códigos de status HTTP além do 200 (o qual significa “OK”). Você encontrará uma lista completa de subclasses na documentação do request/response. Apenas retorne uma instância de uma daquelas subclasses ao invés de uma `HttpResponse` normal para que indique um erro. Por exemplo:

    from django.http import HttpResponse, HttpResponseNotFound

    def my_view(request):
        # ...
        if foo:
            return HttpResponseNotFound('<h1>Page not found</h1>')
        else:
            return HttpResponse('<h1>Page was found</h1>')

Não existe uma subclasse especializada para código de resposta HTTP possível, já que muitos deles não são muito comuns. Contudo, como documentado na documentação do `HttpResponse`, você pode também passar o código de status HTTP dentro do construtor para a `HttpResponse` para que crie a classe de retorno para qualquer código de estatus que queira. Por exemplo:

    from django.http import HttpResponse

    def my_view(request):
        # ...

        # Return a "created" (201) response code.
        return HttpResponse(status=201)

Como os erros 404 são de longe o erro HTTP mais comum, existe uma maneira mais fácil de lidar com estes erros.

### A exceção `Http404`

class `django.http.``Http404`

Quando retornar um erro como o `HttpResponseNotFound`, você é responsável por definir o HTML da página de erro resultante:

    return HttpResponseNotFound('<h1>Page not found</h1>')

Por conveniência, e porque é uma boa idéia ter uma página de erro 404 consistente para todo o seu site, o Django fornece uma exceção `Http404`. Se você emitir um `Http404` em qualquer ponto em uma função “view”, o Django irá capturá-la e retornar a página de erro padrão para sua aplicação, juntamente com um código de erro HTTP 404.

Exemplo de uso:

    from django.http import Http404
    from django.shortcuts import render
    from polls.models import Poll

    def detail(request, poll_id):
        try:
            p = Poll.objects.get(pk=poll_id)
        except Poll.DoesNotExist:
            raise Http404("Poll does not exist")
        return render(request, 'polls/detail.html', {'poll': p})

Para que seja mostrado um HTML personalizado quando o Django retornar um 404, você pode criar um “template” HTML chamado `404.htm` e colocá-lo no nível superior da sua árvore de “templates”. Este “template” irá então ser servido quando `DEBUG` está definido como `False`.

Quando `DEBUG` for `True`, você pode fornecer uma mensagem para `Http404` e ela irá aparecer em depuração no “template” 404 padrão. Use estas mensagens para propósitos de depuração; elas geralmente não são adequadas para serem usadas em um template 404 em producão.

## Personalizando “views” de erro

As “views”de erro padrão do Django devem ser suficientes para a maioria das alicações Web, mas podem ser facilmente sobrescritas se você precisar personalizar seu comportamento. Simplesmente especifique os manipuladores como se vê abaixo no seu URLconf (definido-os em qualquer outro lugar não terá nenhum efeito).

A “view” `page_not_found()` é substituída por `handler404`:

    handler404 = 'mysite.views.my_custom_page_not_found_view'

A “view” `server_error()` é substituída pelo `handler500`:

    handler500 = 'mysite.views.my_custom_error_view'

A “view” `permission_denied()` é substituída pelo `handler403`:

    handler403 = 'mysite.views.my_custom_permission_denied_view'

A “view” `bad_request()` é substituída pelo `handler400`:

    handler400 = 'mysite.views.my_custom_bad_request_view'

Ver também

Use the `CSRF_FAILURE_VIEW` setting to override the CSRF error view.