Changes between Version 1 and Version 2 of DocPtOverview

Timestamp:

Nov 10, 2006, 4:52:46 AM (18 years ago)

Author:

foo@…

Comment:

DocPtOverview

DocPtOverview

@@ -1 @@
-foo
+{{{
+#!rst
+
+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 :      |
++-------------------------------------------------------------------------------------------------+   
+
+..
+  ===============
+  Django Overview
+  ===============
+
+.. sidebar:: Uma rápida olhada no Django
+  :subtitle: tradução para o português.
+
+  Documento original: `Django Overview`_
+  
+  Tradução: Kao Cardoso Félix `<kcfelix at gmail.com>`
+  
+  Referente a revisão: 3896
+
+.. _Django Overview: 
+
+.. contents:: **Conteúdos do capítulo**
+
+===========================
+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`_
+
+.. _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.
+
+.. _documentação: 
+
+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!
+    
+
+.. _baixar o Django: http://www.djangoproject.com/download/
+.. _o tutorial: http://www.djangoproject.com/documentation/tutorial1/
+.. _comunidade: http://www.djangoproject.com/community/
+
+}}}