Version 2 (modified by marvinware2005@…, 18 years ago) ( diff )

--

THIS TRANSLATION IS IN PROGRESS:

This is an in progress translation document, that means there is somebody working on it. For more information on translating documents please look at TranslateDocumentation Wiki. Please do not edit this page.

Escrevendo sua primeira aplicação Django, parte 3

Esse tutorial começa onde o Tutorial 2 terminou. Nós continuaremos nossa aplicação de “Questionário Web” e focaremos na criação da interface pública – “views”.

Filosofia

Uma view é um tipo de página web em sua aplicação Django que geralmente tem uma função específica associada ou tem um template específico. Por exemplo, em uma aplicação de weblog, você poderia ter as seguintes views:

  • A página principal (homepage) do Blog: mostra os últimos posts.
  • Página de detalhe do post: um link permanente para um post.
  • Uma página de arquivo baseada no Ano: mostra todos os meses com posts em um certo ano.
  • Uma página de arquivo baseada no Mês: mostra todos os meses com posts em um certo mês.
  • Uma página de arquivo baseada no Dia: mostra todos os meses com posts em um certo dia.
  • Formulário de comentário: cuida da postagem dos comentários de um certo post.

Em nossa aplicação, teremos as seguintes quatro views:

  • Página Arquivo de Polls: mostra os últimos “polls”.
  • Página de detalhe do Poll: mostra a questão, sem os resultados, mas com um formulário de votação.
  • Página de resultados do Poll: mostra os resultados de um Poll em particular.
  • Formulário de votação: cuida da votação de um “choice” em de um “poll” em particular.

No Django, cada view é representado por uma simples função em Python.

Modelando suas URLs

O primeiro passo para escrever views é modelar sua estrutura de URLs. Você faz isso criando um módulo Python, chamado URLconf. URLcons são como Django associa uma determinada URL com seu respectivo código em Python.

Quando um usuário requisita uma página do Django, o sistema procura na configuração ROOT_URLCONF, que tem uma string na sintaxe “Python dotted” (separado por pontos). Django carrega esse módulo e procura por uma variável chamada urlpatterns, que é uma seqüência de tuplas no seguinte formato:

(regular expression, Python callback function [, optional dictionary])

Django começa a procura na primeira expressão e continua pela lista, comarpando a URL requisitada com cada expressão até que encontre uma coincida.

Quando é encontrada tal expressão, Django executa a função de callback com um objeto HTTPRequest como primeiro argumento, e qualquer valor “capturado” da expressão regular como argumentos chave, e opcionalmente, qualquer argumento do dicionário opcional (o terceiro item da tupla).

Para mais detalhe sobre objetos HTTPRequest, veja request and response documentation. Para mais detalhes sobre URLconfs, veja URLconf documentation.

Quando você executou python manage.py startproject mysite no começo do Tutorial 1, foi criado um URLconf padrão, em mysite/urls.py. Além disso, foi automaticamente setado sua configuração ROOT_URLCONF para apontar para esse arquivo:

ROOT_URLCONF = 'mysite.urls'

É hora de um exemplo. Edite mysite/urls.py para que fique da seguinte forma:

from django.conf.urls.defaults import *

urlpatterns = patterns('',
    (r'^polls/$', 'mysite.polls.views.index'),
    (r'^polls/(?P<poll_id>\d+)/$', 'mysite.polls.views.detail'),
    (r'^polls/(?P<poll_id>\d+)/results/$', 'mysite.polls.views.results'),
    (r'^polls/(?P<poll_id>\d+)/vote/$', 'mysite.polls.views.vote'),
)

Uma pequena revisão. Quando alguém requisita uma página do se site – diga-se “/polls/23/”, Django vai carregar esse módulo Python, porque ele está apontado pela configuração ROOT_URLCONF. Então, é encontrado uma variável chamada urlpatterns e realiza uma busca pela expressão regular. Quando é encontrada tal expressão regular - r'^polls/(?P<poll_id>\d+)/$' - é então carregado o pacote/modulo Python associado: mysite.polls.views.detail. Isso corresponde à função detail() em mysite/polls/views.py. Finalmente, é chamda a função detail() da seguinte forma:

detail(request=<HttpRequest object>, poll_id='23')

A parte poll_id='23' vem de (?P<poll_id>\d+). Usando parentes em volta de um padrão “captura” o texto correspondente por aquele padrao e envia esse texto como argumento para a função da view; o ?P<poll_id> define o nome que será usado para identificar o padrão; e \d+ é uma expressão regular que indica uma seqüência de dígitos (ou seja, um número).

Como os padrões de URL são expressões regulares, não há um limite no que você pode fazer com eles. E não há a necessidade de adicionar “URL cruft” como .php` - ao menos que você tenha um “belo” senso de humor, e queira fazer algo como:

(r'^polls/latest\.php$', 'mysite.polls.views.index'),

Mas não o faça. É horrível.

Note que essas expressões regulares não procuram por parâmetros GET e POST, ou pelo domínio do site. Por exemplo, em uma requisição para http://www.example.com/myapp/, o URLconf irá, procurar por /myapp/. Em uma requisição para http://www.example.com/myapp/?page=3, o URLconf irá procurar por /myapp/.

Note: See TracWiki for help on using the wiki.
Back to Top