1.

Criando um Projeto Django

django-admin.py startproject <nome-do-seu-projeto>
Ele criará uma pasta com o nome do seu projeto que conterá os arquivos:

 __init__.py: É o arquivo que determina que aquela pasta é um pacote

Python;
 settings.py: Arquivos de configurações em XML? Esqueça! Em Django
temos a configuração do nosso projeto em um único arquivo .py;
 urls.py: Este é o “temido” url dispatcher. Você passará bons (e maus)
momentos com ele;
 manage.py: O regente da orquestra. É através dele que você executará
ações como criar uma aplicação, sincronizar o banco de dados, iniciar o
servidor web embutido (somente recomendado para ambiente de
desenvolvimento), etc. Esse é um dos caras que fará o seu dia bem
melhor com Django.

Para o Django, um Projeto é um conjunto de aplicações. Na prática: digamos

que você irá desenvolver um website para o cliente Lanchonete do Zé. Então
poderia chamar seu projeto de lanchonete_ze e a partir daí desenvolver as
aplicações necessárias para o funcionamento do website.
2. Criando uma aplicação
python manage.py startapp <nome-da-sua-aplicacao>
E será criada uma pasta com o nome da sua aplicação dentro do seu projeto,
que conterá os seguintes arquivos:

 __init__.py: É o arquivo que determina que aquela pasta é um pacote

Python;
 models.py: Suas entidades do banco de dados devem ser escritas neste
arquivo;
 views.py: Suas views devem ser escritas neste arquivo.

Uma Aplicação é uma determinada funcionalidade que compõe um projeto. Na

prática: digamos que o website da Lanchonete do Zé precise de um sistema de
enquetes. Logo, você criará uma aplicação chamada enquetes e elá conterá
(inicialmente) um model.py e um view.py. Cada aplicação sua terá um Model e
um View, você pode controlá-la através do urls.py do projeto ou através do seu
próprio urls.py.
O conceito de Aplicações Plugáveis em Django é bem interessante: uma
aplicação pode ser considerada plugável quando pode ser usada em mais de um
projeto com nenhuma ou quase nenhuma alteração de código.
Isso quer dizer que a aplicação deve ter seus próprios Models (models.py), suas
próprias Views (views.py), seus próprios Templates, seu próprio Controller
(urls.py) e encapsular o máximo possível de código que não se enquadre em um
desses elementos. Mas sempre teremos alguma coisa para fazer, como
adicionar a aplicação no INSTALLED_APPS do settings.py e adicionar a
aplicação no roteamento do urls.py do projeto.
3. Baterias Inclusas
Além do seu “core”, o Django disponibiliza uma série de recursos que os
Pythonistas costumam chamar de “baterias inclusas”.

Dentre os recursos mais comuns, temos à disposição

o auth, sites, admin, contenttypes, etc. Sem eles, o seu website funciona.
Com eles, você economiza kilômetros de LOC e terá aplicações testadas à
exaustão.

O auth, por exemplo, é uma aplicação completíssima de autenticação. Em 5

projetos desenvolvidos com o Django, em nenhum me preocupei com o esquema
de usuários e permissões.

O admin é outro recurso fantástico do Django. Com ele não precisamos mais
escrever todo o back-end da aplicação, basta algumas regras Python e “Pof”…
você tem um backend leve, simples, compatível com os padrões da W3C, e até
bonitinho (ok, beleza talvez não seja o aspecto mais impressionante nele).

Um fato bem interessante do admin é que seus widgets em javascript (como

DatePicker) são desenvolvidos pela própria equipe do Django, e não dependem
de nenhuma framework (como é o caso do Joomla!, por exemplo, que depende
da Mootools). Isso é vantajoso já que os widgets vão evoluindo de acordo com
o estado da aplicação e não sofrem “influências externas”.

Os middlewares são recursos mais do que essenciais no Django. O sistema de

I/O do Django é em forma de “cebola”, ou seja, passam pelos middlewares tudo
o que é referente a entrada (requisição) e saída (resposta). Um exemplo bem
legal é construir um middleware que cheque qual é o user-agent do internauta,
se ele for um mobile deverá importar uma classe de templates diferente da usual.