Version 5 (modified by 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. |
Uma rápida olhada no Django
Este documento cobre a versão 0.95 de Django e a versão do desenvolvimento. Docs anteriores: 0.90, 0.91
Como o Django foi desenvolvido dentro do ambiente ágil de uma "newsroom", ele foi projetado para fazer as tarefas comuns do desenvolvimento Web serem rápidas e fáceis. Aqui está um "overview" informal de como escrever um Aplicativo Web com Banco de Dados usando o Django
O objetivo desse documento é lhe dar informações técnicas específicas suficientes para que você entenda como o Django funciona, mas não ser um tutorial ou uma referência. Por favor, veja a documentação detalhada do Django quando você estiver pronto para iniciar um projeto.
Projete seu modelo
Apesar de você poder usar o Django sem um banco de dados, ele vem com um mapeador Objeto-Relacional em que você descreve a estrutura dos seus dados em Python.
A sintaxe de modelo de dados oferece diversas maneiras ricas de representar os seus modelos -- até agora, já esteve resolvendo problemas de "database-schema" equivalentes a dois anos. Aqui está um rápido exemplo:
class Reporter(models.Model): full_name = models.CharField(maxlength=70) def __str__(self): return self.full_name class Article(models.Model): pub_date = models.DateTimeField() headline = models.CharField(maxlength=200) article = models.TextField() reporter = models.ForeignKey(Reporter) def __str__(self): return self.headline
Instale-o
O próximo passo é executar o utilitário de linha de comando do Django para criar as tabelas do banco de dados automaticamente:
manage.py syncdb
O comando syncdb vai "olhar" para todos os seus modelos disponíveis e criar tabelas no seu banco de dados para quaisquer modelos que ainda não tenham uma tabela correspondente.
Aproveite a API
Com isso você ganha de graça (?) uma rica API em Python para acessar seus dados. A API é criada na hora: Sem geração de código:
>>> from mysite.models import Reporter, Article # Ainda não existem repórteres no sistema. >>> Reporter.objects.all() [] # Cria um novo repórter. >>> r = Reporter(full_name='John Smith') # Salva o objeto no banco de dados. Você deve chamar save() explicitamente. >>> r.save() # Agora ele tem uma ID. >>> r.id 1 # Agora o novo repórter está no banco de dados. >>> Reporter.objects.all() [John Smith] # Campos são representados como atributos do objeto Python. >>> r.full_name 'John Smith' # O Django provê uma rica API de buscas no banco de dados. >>> Reporter.objects.get(id=1) John Smith >>> Reporter.objects.get(full_name__startswith='John') John Smith >>> Reporter.objects.get(full_name__contains='mith') John Smith >>> Reporter.objects.get(id=2) Traceback (most recent call last): ... DoesNotExist: Reporter does not exist for {'id__exact': 2} # Cria um artigo. >>> from datetime import datetime >>> a = Article(pub_date=datetime.now(), headline='Django is cool', ... article='Yeah.', reporter=r) >>> a.save() # Agora o artigo está no banco de dados. >>> Article.objects.all() [Django is cool] # Objetos de Artigo ganham acesso aos objetos Reporter relacionados através da API. >>> r = a.reporter >>> r.full_name 'John Smith' # E vice versa: objetos Reporter ganham aceso a objetos Artigo através da API. >>> r.article_set.all() [Django is cool] # A API segue relacionamentos tanto quanto você precisar, fazendo # JOINs eficientes para você por trás das cortinas. # Esse trecho encontra todos os artigos escritos por um repórter cujo nome começa por "John". >>> Article.objects.filter(reporter__full_name__startswith="John") [Django is cool] # Mude um objeto alterando seus atributos e chamando save(). >>> r.full_name = 'Billy Goat' >>> r.save() # Apague um objeto com delete(). >>> r.delete()
Uma interface de administração dinâmica: Não é apenas a estrutura -- é a casa inteira
Uma vez que seus modelos estejam definidos, o Django pode criar automaticamente uma interface administrativa profissional e pronta para produção. Essa interface é um site que permite aos usuários autenticados adicionar, alterar e excluir objetos. É tão fácil habilitar a interface para seu modelo quanto é adicionar uma nova linha de código:
class Article(models.Model): pub_date = models.DateTimeField() headline = models.CharField(maxlength=200) article = models.TextField() reporter = models.ForeignKey(Reporter) class Admin: pass
A filosofia aqui é que seu site é editado por um funcionário, um cliente ou talvez você mesmo -- e você não quer lidar com a criação de uma interface apenas para gerenciar conteúdo.
Um fluxo de trabalho típico na criação de aplicativos Django é criar modelos e botar os sites de administração para rodar o mais rápido possível para que seus funcionários (ou clientes) possam começar a preencher os dados. Aí sim desenvolver o modo como os dados serão apresentados ao público.
Projete seus URLs
Um esquema de URL limpo e elegante é um detalhe importante em uma aplicação Web de alta qualidade. Django encoraja a criação de URLs belos e não o obriga a colocar nenhuma extensão feia como .php ou .asp.
Para criar URLs para o seu aplicativo você cria um módulo Python chamado URLconf. Esse módulo contém um simples mapeamento entre padrões de URL e funções de "callback" em Python. Módulos URLconf também servem para desacoplar URLs de código Python.
Aqui está um possível URLconf para o exemplo de Repórte/Artigo de antes:
from django.conf.urls.defaults import * urlpatterns = patterns('', (r'^/articles/(\d{4})/$', 'mysite.views.year_archive'), (r'^/articles/(\d{4})/(\d{2})/$', 'mysite.views.month_archive'), (r'^/articles/(\d{4})/(\d{2})/(\d+)/$', 'mysite.views.article_detail'), )
O código acima mapeia URLs, com simples expressões regulares, para funções Python de callback ("views"). As expressões regulares usam parênteses para "capturar" valores das URLs. Quando um usuário acessa uma página, o Django irá passar por cada um dos padrões, em ordem, e vai parar no primeiro que combina com o URL acessado. (Se nenhum combinar o Django vai chamar uma "view" especial de erro 404.) Tudo isso é incrivelmente rápido porque as expressões regulares são compiladas em tempo de carregamento.
Assim que uma das expressões combinar, o Django vai importar e chamar a "view" necessária, que é uma função Python simples. Cada "view" recebe um objeto de "request" -- que contém metadados de "request" -- e os valores capturados na expressão regular.
Por exemplo, se um usuário acessa a URL "/articles/2005/05/39323/", o Django iria chamar a função mysite.views.article_detail(request, '2005', '05', '39323').
Escreva suas "views"
Cada "view" é responsável por fazer uma de duas coisas: Retornar um objeto HttpResponse com o conteúdo da página requisitada ou levantar uma exceção, por exemplo Http404. O resto é com você.
Geralmente, uma "view" obtém dados de acordo com os parâmetros, carrega um template e renderiza o template com os dados obtidos. Aqui está um exemplo de uma "view" para o year_archive mostrado acima:
def year_archive(request, year): a_list = Article.objects.filter(pub_date__year=year) return render_to_response('news/year_archive.html', {'year': year, 'article_list': a_list})
Esse exemplo usa o sistema de "templates" do Django que tem muitas características poderosas mas tenta sempre ficar simples o suficiente para não-programadores usá-lo.
Crie seus "templates"
O código acima carrega o template news/year_archive.html.
O Django tem um caminho de procura para templates permitindo que você minimize a redundância entre os templates. Nas suas configurações do Django você especifica uma lista de diretórios para procurar por templates. Se um template não existe no primeiro diretório, ele procura no segundo e assim por diante.
Vamos dizer que o template news/article_detail.html foi encontrado. Aqui está como ele poderia ser:
{% extends "base.html" %} {% block title %}Articles for {{ year }}{% endblock %} {% block content %} <h1>Articles for {{ year }}</h1> {% for article in article_list %} <p>{{ article.headline }}</p> <p>By {{ article.reporter.full_name }}</p> <p>Published {{ article.pub_date|date:"F j, Y" }}</p> {% endfor %} {% endblock %}
Variáveis são envolvidas por duplas chaves. {{ article.headline }} significa "Mostre o valor do atributo headline da variável article". Mas pontos não são usados apenas para acessar atributos: eles também podem fazer acesso por chaves de dicionários, acesso por índices e chamadas de funções.
Note que {{ article.pub_date|date:"F j, Y" }} usa um "pipe" estilo Unix (o caractere "|"). Isso é chamado filtro de template e é um modo de filtrar o valor de uma variável. Nesse caso o filtro de data formata um objeto "datetime" do Python no formato dado (como o usado na função "date" do PHP; sim, existe uma boa idéia no PHP).
Você pode encadear tantos filtros quanto você quiser. Você pode escrever seus próprios filtros. Você pode escrever suas próprias "tags" de "template", que podem executar código Python por trás das cortinas.
Finalmente, o Django usa o conceito de "herança de templates": Isso é o que {% extends "base.html" %} faz. Significa "Primeiro carregue o template chamado 'base', que já definiu uma série de blocos, e preencha os blocos com os seguintes blocos." Resumindo, isso permite que você diminua drasticamente a redundância dos seus templates: Cada template define apenas o que é exclusivo dele próprio.
Aqui está como o template "base.html" poderia se parecer:
<html> <head> <title>{% block title %}{% endblock %}</title> </head> <body> <img src="sitelogo.gif" alt="Logo" /> {% block content %}{% endblock %} </body> </html>
De maneira simplista, ele define a aparência geral do site (com o logo do site), e provê alguns "buracos" para os templates filhos preencherem. Isso faz o "redesign" de um site tão fácil quanto mudar um único arquivo -- o template base.
Ele também permite que você crie múltiplas versões de um site, com templates base diferentes, enquanto os templates filhos são reusados. Os criadores do Django usaram essa técnica para criar edições para celular dos site extremamente diferentes -- simplesmente criando um novo template base.
Note que você não precisa usar o sistema de templates do Django se você prefere outro sistema. Enquanto o sistema de templates do Django é particularmente bem integrado com a camada de modelos do Django, nada força você a usá-lo. Falando nisso, você também não precisa usar a API de banco de dados do Django. Você pode usar outra camada de abstração de banco de dados, você pode ler arquivos XML, você pode ler arquivos "off disk" (fora de um disco?) ou qualquer coisa que você preferir. Cada parte do Django -- modelos, "views", "templates" -- é desacoplada das outras.
Essa é apenas a superfície
Essa foi apenas uma rápida visão da funcionalidade que o Django oferece. Algumas outras características úteis são:
- Um framework de "caching" que integra com o "memcached" e outros "backends".
- Um framework de syndication que faz com que a criação de feeds RSS e Atom feeds seja tão fácil quanto escrever uma pequena classe Python.
- Mais "features sexys" (fica meio estranho :P) para a interface de administração automática -- esse texto mostrou apenas a superfície.
Os próximos passos óbvios para você é baixar o Django, ler o tutorial a se juntar à comunidade. Obrigado pelo seu interesse!