Version 3 (modified by marvinware2005@…, 17 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.                                                            |
|                                                                                                 |
| .. _TranslateDocumentation Wiki : http://code.djangoproject.com/wiki/TranslateDocumentation     |
+-------------------------------------------------------------------------------------------------+   

.. sidebar:: Escrevendo sua primeira aplicação Django, parte 2
  :subtitle: tradução para o português.

  Documento original: `Writing your first Django app, part 2`_
  
  Tradução: Marcos Vinícius `<marvinware2005@yahoo.com>`
  
  Referente a revisão: 3454

.. _Writing your first Django app, part 2: http://www.djangoproject.com/documentation/tutorial2/

.. contents:: **Conteúdo do capítulo**

=================================================
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”.

.. _Tutorial 2: http://code.djangoproject.com/wiki/DocPtTutorial2

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/``.


Se você precisa de ajuda com expressões regulares, veja esse `Post na Wikipedia`_ e a `Documentação do Python`_.

Finalmente, uma observação sobre performance: essas expressões regulares são compiladas na primeira vez que o modulo URLconf é carregado. Elas são super rápidas!

.. _request and response documentation: http://www.djangoproject.com/documentation/request_response/
.. _URLconf documentation: http://www.djangoproject.com/documentation/url_dispatch/
.. _Post na Wikipedia: http://en.wikipedia.org/wiki/Regular_expression
.. _Documentação do Python: http://www.python.org/doc/current/lib/module-re.html

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