O Django utiliza objetos de requisição e resposta para passar estado através do sistema.
Quando uma página é requisitada, o Django cria um objeto HttpRequest que contém metadados sobre a requisição. Então o Django carrega a view apropriada, passando o HttpRequest como o primeiro argumento para a função de view. Cada view é responsável por devolver um objeto HttpResponse.
Este documento explica as APIs para os objetos HttpRequest e HttpResponse.
Todos os atributos, exceto session, devem ser considerados somente para leitura.
Uma string representando o caminho completo para a página requisitada, não incluindo o domínio.
Exemplo: "/music/bands/the_beatles/"
Uma string representando o método HTTP usado na requisição. Este valor está sempre em maiúsculo. Exemplo:
if request.method == 'GET':
do_something()
elif request.method == 'POST':
do_something_else()
Uma string representando o valor atual de codificação utilizado para decodificar o envio de dados de formulário (ou None, que quer dizer que o parâmetro de configuração DEFAULT_CHARSET é utilizado). Você pode alterar este atributo para modificar a codificação usada quando acessar os dados do formulário. Quaisquer acessos subseqüentes a atributos (como ler de GET ou POST) utilizará no novo valor de encodig. Isto é útil se você sabe que os dados do formulário não estão na codificação DEFAULT_CHARSET.
Um objeto dicionário contendo todos os parametros passados por HTTP POST. Veja a documentação do QueryDict abaixo.
It's possible that a request can come in via POST with an empty POST dictionary -- if, say, a form is requested via the POST HTTP method but does not include form data. Therefore, you shouldn't use if request.POST to check for use of the POST method; instead, use if request.method == "POST" (see above). É possível que um requisição POST possa vir com um dicionário POST vazio -- se, digo, um formulário é requisitado via metodo HTTP POST mas não inclui dados. Portanto, você não deve usar if request.POST para checar o uso do método POST; ao invés, use if request.method == "POST" (veja acima).
Perceba: POST não inclui informações de upload de arquivos. Veja FILES.
Por conveniência, um objeto dicionário que procura POST primeiro, somente depois GET. Inpirado no $_REQUEST do PHP.
Por exemplo, se GET = {"name": "john"} and POST = {"age": '34'}, REQUEST["name"] poderia ser "john", e REQUEST["age"] poderia ser "34".
É fortemente sugerido que você use o GET e POST ao invés de REQUEST, porque são mais explicitos.
Um objeto dicionário contendo todos os arquivos enviados. Cada chave em FILES é o name do <input type="file" name="" />. Cada valor em FILES é um objeto UploadedFile contendo os seguintes atributos:
Veja Gerenciando arquivos para mais informações.
Note que FILES conterá somente dados se o método de requisição for POST e o <form> que postou a requisição tenha enctype="multipart/form-data". De outra forma, FILES será um dicionário em branco.
Nas versões anteriores do Django, request.FILES contendo um simples dict representando os arquivos enviados. Isto já não é verdade -- os arquivos são representados por objetos UploadedFile como decrito abaixo.
Estes objetos UploadedFile emulam a interface do velho dict, mas que é depreciada e será removida no próximo lançamento do Djando.
Um dicionário padrão do Python contendo todos cabeçalhos disponíveis do HTTP. Os cabeçalhos disponíveis dependem do cliente e do servidor, mas aqui há alguns exemplos:
Com a exceção do CONTENT_LENGTH e CONTENT_TYPE, mostrados acima, qualquer cabeçalho HTTP na requisição é convertido para a chave META, tendo todos os seus caracteres passados para maiúsculo, substituindo os hífens por underscores e adicionando um HTTP_ como prefixo do nome. Então, por exemplo, um cabeçalho chamado X-Bender seria mapeado para a chave META como HTTP_X_BENDER.
A django.contrib.auth.models.User object representing the currently logged-in user. If the user isn't currently logged in, user will be set to an instance of django.contrib.auth.models.AnonymousUser. You can tell them apart with is_authenticated(), like so:: Um objeto django.contrib.auth.models.User representando o usuário atual logado. Se o usuário não estiver logado, o user conterá uma instância do django.contrib.auth.models.AnonymousUser. Você pode usar o método is_authenticated(), tipo:
if request.user.is_authenticated():
# Faça algo para usuários logados.
else:
# Faça algo para usuários anônimos.
O user é somente disponível se sua instalação do Django tem o middleware AuthenticationMiddleware ativado. Para mais, veja Autenticação de Usuário no Django.
Retorna o servidor originador da requisição usando informações dos cabeçalhos HTTP_X_FORWARDED_HOST e HTTP_HOST (nesta ordem). Se eles não fornecem um valor, o método usa uma combinação de SERVER_NAME e SERVER_PORT como detalhado em PEP 333.
Exemplo: "127.0.0.1:8000"
Retorna o path, mais uma query string anexa, se aplicável.
Exemplo: "/music/bands/the_beatles/?print=true"
Retorna a URI absoluta de location. Se nenhum location é fornecido, o location será setado para request.get_full_path()`.
Se o location já é uma URI absoluta, ele não será alterado. De outra forma a URI absoluta é construída usando as variáveis de servidor disponíveis nesta requisição.
Exemplo: "http://example.com/music/bands/the_beatles/?print=true"
Retorna True se a requisição foi feita via um XMLHttpRequest, checando o cabeçalho HTTP_X_REQUESTED_WITH por um string 'XMLHttpRequest'. As seguintes bibliotecas JavaScript enviam seus cabeçalhos:
Se você escrever sua própria chamada XMLHttpRequest (no lado do navergador), terá de setar este cabeçalho manualmente se quiser que o is_ajax().
Num objeto HttpRequest, os atributos GET e POST são instâncias do django.http.QueryDict. O QueryDict é uma classe tipo dicionário customizada para lidar com múltiplos valores para a mesma chave. Isto é necessário porquê alguns elementos de formulário HTML, notavelmente, <select multiple="multiple">, passam multiplos valores para a mesma chave.
QueryDict instances are immutable, unless you create a copy() of them. That means you can't change attributes of request.POST and request.GET directly. A instância QueryDict é imutável, a menos que você crie uma copy() deles. O que significa que você não poderá mudar atributos do request.POST e request.GET diretamente.
O QueryDict implementa todo os métodos padrão de dicionários, porque ele é uma subclasse de dicionário. Execeções são esboçadas aqui:
Recebe ambos QueryDict ou um dicionário padrão. É como o método update() padrão de dicionário, exceto por atachar os ítems no dicionário atual ao invés de substituí-los. Por exemplo:
>>> q = QueryDict('a=1')
>>> q = q.copy() # para torná-lo mutável
>>> q.update({'a': '2'})
>>> q.getlist('a')
['1', '2']
>>> q['a'] # retorna o último
['2']
É como o método items() padrão de dicionários, exceto por usar o mesmo último valor lógico como __getitem()__. Por exemplo:
>>> q = QueryDict('a=1&a=2&a=3')
>>> q.items()
[('a', '3')]
Como o médodo values() padrão de dicionários, exceto por usar o mesmo último valor lógico como __getitem()__. Por exemplo:
>>> q = QueryDict('a=1&a=2&a=3')
>>> q.values()
['3']
Além disso, o QueryDict tem os seguintes métodos:
Como items(), exceto por incluír todos os valores, como uma lista, para cada membro do dicionário. Por exemplo:
>>> q = QueryDict('a=1&a=2&a=3')
>>> q.lists()
[('a', ['1', '2', '3'])]
Em contrate com objetos HttpRequest, que são criados automaticamente pelo Django, os objetos HttpResponse são sua responsabilidade. Cada view que você escrever é responsável por instanciar, popular e retornar um HttpResponse.
The HttpResponse class lives in the django.http module. A classe HttpResponse reside o módulo django.http.
Um uso típico é passar os conteúdos de uma página, como uma string, para o construtor HttpResponse:
>>> response = HttpResponse("Aqui tem um texto para a página Web.")
>>> response = HttpResponse("Somente texto, por favor.", mimetype="text/plain")
Mas se você quiser adicionar conteúdo incrementalmente, você pode usar o response como um objeto:
>>> response = HttpResponse()
>>> response.write("<p>Aqui tem um texto para a página Web.</p>")
>>> response.write("<p>Aqui tem outro parágrafo.</p>")
Você pode adicionar e deletar cabeçalhos usando sintaxe de dicionário:
>>> response = HttpResponse()
>>> response['X-DJANGO'] = "Ele é o melhor."
>>> del response['X-PHP']
>>> response['X-DJANGO']
"Ele é o melhor."
Note que del não lança um KeyError se o cabeçalho não existe.
Finalmente, você pode passar ao HttpResponse um iterador ao invés de passar strings na mão. Se você usar esta técnica, siga estas dicas:
Para setar um cabeçalho em sua resposta, é só tratá-la como um dicionário:
>>> response = HttpResponse()
>>> response['Pragma'] = 'no-cache'
Instancia um objeto HttpResponse com o conteúdo da página fornecida (uma string) e o "MIME type". O DEFAULT_CONTENT_TYPE é 'text/html'.
O content pode ser um iterador ou string. Se for um iterador, ele deve retornar strings, e suas strings serão unidas para formar o conteúdo da resposta.
O status é o Status code HTTP para a resposta.
O content_type é um alias para mimetype. Historicamente, este parâmetro foi chamado somente mimetype, mas como na verdade ele é o valor incluso no cabeçalho HTTP Content-Type, também pode incluir o conjunto de caracteres de codificação.
Seta um cookie. Os parametros são os mesmo do objeto cookie Morsel da biblioteca padrão do Python.
Deleta o cookie com o a chave fornecida. Falha silenciosamente se a chave não existe.
Devido a forma como os cookies funcionam, path e domain devem ser o mesmo valor usado em set_cookie() -- caso contrário o cookie pode não ser deletado.
O Django incluí um número de subclasses HttpResponse que manipulam direntes tipos de respostas HTTP. Como HttpResponse, estas subclasses residem o módulo django.http.
Age como um HttpResponse mas usa um "status code" 400.
Aug 06, 2009