Excetuando o fato que estourei um pouquinho o tempo na minha apresentação, o momento foi super válido, pois pude contar com a colaboração do público com muitas perguntas e comentários, e acredito que pelo menos algumas pessoas ficaram interessadas em dar uma olhada no Django. Também foi bacana o momento pós-evento onde puder trocar uma ideia com algumas pessoas, inclusive um aluno da UFES que está utilizando Django para uma aplicação de backend em seu trabalho de conclusão de curso.

Disponibilizei os slides da apresentação no SlideShare:

Em todos os casos, desenvolverei uma aplicação simples, que será enviada para o Google App Engine e disponibilizada publicamente :) Nesta primeira parte, abordarei o Django, o mais famoso dentre os frameworks Python para a web.

O principal recurso do Django é a camada de modelo, chamada Django models. Trata-se de uma camada de abstração de dados composta por um poderoso framework de mapeamento objeto-relacional, que suporta diversos sistemas de gerenciamento de banco de dados relacionais. O único problema é que o Google App Engine não usa um banco de dados relacional, o App Engine usa o BigTable, um poderoso banco de dados para armazenamento de dados em larga escala. Assim, a poderosa camada de modelo do Django é simplesmente inútil, pelo menos nativamente falando.

Não há motivo para pânico, existe um fork do Django, o projeto django-nonrel, que visa trazer o poder do Django models para bancos de dados não-relacionais, como o BigTable. Na aplicação deste post, foi utilizado o subprojeto djangoappengine, que une o Django ao BigTable de forma descomplicada.

A aplicação de exemplo não será nenhum exemplo de criatividade: um blog extremamente simples, com apenas uma página para listar os posts e outra para cadastrá-los (protegida por login). Vamos utilizar a autenticação nativa do Django, e não a API de autenticação fornecida pelo App Engine.

O primeiro passo é deixar o ambiente pronto para receber nosso código (e voar em produção =P). De acordo com a documentação oficial do djangoappengine, é necessário baixar quatro arquivos e juntá-los. Comecei pela aplicação, baixei o arquivo django-testapp.zip, extraí e renomeei o diretório de django-testapp para blog_gae. Depois eu baixei as outras bibliotecas, de forma que a estrutura do projeto ficou da seguinte forma:

O diretório “django” foi extraído do pacote django-nonrel.zip, o diretório “djangoappengine” do pacote djangoappengine.zip e o “djangotoolbox” extraído do pacote djangotoolbox.zip. Junto à estrutura de exemplo da aplicação está presente o arquivo app.yaml, que é o arquivo de configuração da aplicação no Google App Engine. Neste arquivo, é necessário apenas mudar o ID da aplicação (primeira linha). Veja como fica o arquivo após a mudança:

A cada parte da série de posts eu vou fazer o deploy de uma versão diferente, assim, todas as versões ficarão disponíveis online dentro de uma mesma aplicação do Google App Engine. Como esta é a primeira parte, então será a primeira versão =P Outro ponto é o arquivo de configuração do Django (settings.py), neste momento, a única mudança neste arquivo é “descomentar” a linha django.contrib.auth na tupla INSTALLED_APPS, para que possamos utilizar a aplicação de autenticação nativa do Django.

Agora nosso ambiente está devidamente configurado, podemos iniciar uma nova aplicação Django e começar a codar. A forma de iniciar a aplicação é a mesma de sempre (daqui pra frente, tudo se parecerá naturalmente Django): basta rodar o startapp.

$ ./manage.py startapp core

Criamos a aplicação principal do projeto, chamada core. É criado o diretório da aplicação com os módulos Python “normais”: models, views e tests. Vamos então criar o model Post. Note que tudo está em inglês, pois esta aplicação foi desenvolvida em inglês :) Eis o código do módulo models.py, com a classe Post:

Agora basta instalar a aplicação core colocando-a dentro da tupla INSTALLED_APPS no arquivo settings.py. Como vamos utilizar a aplicação de autenticação do Django, vamos criar um usuário de administração (super-usuário) para gerenciar toda a bagunça:

$ ./manage.py createsuperuser

Após informar o nome de usuário, o e-mail e a senha, o usuário estará criado no banco de dados. Agora vamos fazer nossa aplicação estar preparada para fazer login e logout. Primeiro, vamos mapear as URLs de login e logout no arquivos urls.py:

Note as linhas 6 e 7, onde as URLs são mapeadas. Você pode também conferir os códigos dos templates registration/login.html e registration/logged_out.html. Finalmente, basta adicionar três linhas ao settings.py:

Agora as URLs de login e logout já estão prontas para voar, podemos criar nossas views de cadastro e listagem dos posts. Vamos primeiro criar a view de cadastro, que contará com um formulário composto pelos campos title (título) e content (conteúdo). Será um ModelForm atrelado ao modelo Post. Além dos campos title e content, o atributo user do modelo Post será preenchido automaticamente com o usuário logado. Eis o código completo do formulário:

Agora basta criar a view para cadastro de um post. Vamos criar também a view de listagem com um simples redirecionamento para que as coisas funcionem bem aqui. Eis o código do módulo views.py:

Agora, para que a view new_post funcione, precisamos apenas mapear as duas views acima para suas respectivas URLs, e criar o template new_post.html. Eis o mapeamento de URLs:

Confira também o template new_post.html.

Finalmente já podemos ver alguma coisa através do navegador. Rodando o comando ./manage.py runserver no terminal temos o servidor inicializado, então é possível acessar a URL http://localhost:8000/posts/new no navegador para ver um formulário de cadastro de posts, onde os posts podem ser escritos e salvos (lembre-se apenas que é necessário efetuar login para acessar esta view). Agora, precisamos apenas listar todos os posts na URL /posts/. A view list_posts já está mapeada para a URL /posts/, então a única coisa a fazer é escrever o código da view, que lista todos os posts do banco de dados e envia para um template:

Confira o template list_posts.html. Finalmente nossa aplicação está pronta para o deploy, mas como fazemos isso? De uma maneira muito difícil:

$ ./manage.py deploy

Pronto, aplicação em produção :) Para poder ter acesso como usuário na aplicação, basta apenas rodar o comando para criar o usuário remotamente:

$ ./manage.py remote createsuperuser

Você pode ver esta aplicação voando neste link: http://1.latest.gaeseries.appspot.com/ (para logar-se no sistema, utilize o nome de usuário demo com a senha demo)

E também ver o código fonte completo neste link: http://github.com/franciscosouza/gaeseries/tree/django

Nos vemos na próxima parte ;)

A programação completa do II Liberdade Interativa é a seguinte:

• 19h00: Bacula – O backup da meia-noite (Raphaela M. Rocha);
• 19h50: Django: O framework web para perfeccionistas com prazos (Francisco Souza);
• 20h40: Iptables: Entendendo como fazer um firewall pessoal (Almir M3nd3s)

O evento acontecerá no mini-auditório da Faesa da Av. Vitória, no dia 19 de agosto de 2010 e começará às 19 horas. A inscrição será feita “na hora”, então não é necessário fazer inscrição previamente, basta aparecer :)

Já no dia 28 de agosto, acontecerá o II Workshop de PHP do Espírito Santo na UVV, em Vila Velha. Neste evento eu apresentarei junto ao colega de trabalho André Tagliati a palestra “CodeIgniter: turbinando a produtividade com MVC” e junto ao time da Giran um hands-on de Scrum entitulado “Aprendendo a começar um projeto com Scrum”.

A programação completa do II Workshop de PHP do Espírito Santo é a seguinte:

• 09h10: PHPZeiro: Adote um framework! (Leo “Hackin”)
• 10h10: CodeIgniter: Turbinando a produtividade com MVC (Francisco Souza e André Tagliati)
• 11h10: Técnicas simples e eficazes para tirar o máximo do seu servidor MySQL (Marcelo Raposo)
• 14h00: PHP Data Object – Interface Única de Comunicação com SGBDs (Almir M3nd3s)
• 15h10: Moodle: fazendo EAD de qualidade com PHP (Lucas Coradini)
• 16h10: Aprendendo a começar um projeto com Scrum (Time da Giran)

Neste caso, a inscrição é gratuita e obrigatória, e deve ser feita neste formulário. O evento acontecerá no dia 28 de agosto, a partir da 8:30 na UVV, campus Boa Vista.

Será um mês de boas atividades, e eu espero ver muita gente em todas elas =P

Este post tem como objetivo fazer uma apresentação básica do uso do Django com o Freshen. Antes de começar, vamos preparar as ferramentas necessárias :) Como o Freshen é um plugin do Nose, para utilizar o Freshen, precisamos do Nose. Já que vamos integrar o Django também no esquema, precisamos também adicionar um plugin para testar o Django, NoseDjango, e também o próprio Django. Por fim, para isolar os tests do banco de dados, um framework de Mock é uma boa pedida. Vamos utilizar o Ludibrio, que foi feito por brasileiros, é simples e bom o suficiente. Se você tem o PIP instalado, um simples comando instala tudo que nós precisamos:

Agora que temos todas as ferramentas necessárias, podemos começar a trabalhar no nosso “sisteminha”. Nosso exemplo vai ser um delivery de medicamentos para a farmácia do tio-avô da ex-namorada do meu primo de segundo grau. Vamos implementar apenas uma funcionalidade, que será descrita em um arquivo de funcionalidade.

Primeiramente, vamos criar o projeto do Django para a farmácia:

Criado o projeto, vamos iniciar a aplicação delivery, que vai ser o que vamos testar:

Não há muita coisa a ser configurada no projeto, vamos apenas configurar o banco de dados, definir o diretório dos templates (no projeto) e adicionar nossa aplicação ao INSTALLED_APPS:

Agora que temos nosso projeto iniciado e configurado, com nossa aplicação iniciada e instalada, vamos começar a desenvolver, mas primeiro vamos escrever as funcionalidades do Freshen. As funcionalidades do Freshen são compostas por cenários que por sua vez são compostos por passos. As funcionalidades de um sistema são definidas dentro de arquivos de funcionalidades. Vamos criar a funcionalidade Listar remédios, que será a listagem de remédios para serem selecionados para compra e entrega.

Vamos criar dentro da aplicação delivery um diretório chamado features e dentro deste diretório criaremos o arquivo listar_remedios.feature, com o seguinte conteúdo:

O “código” da funcionalidade é totalmente simples: a funcionalidade tem um nome, no nosso caso “Listar remédios”, um cabeçalho, que é uma descrição livre da funcionalidade (você realmente pode escrever o que quiser no cabeçalho). Para cada história, definimos cenários, utilizando a palavra chave “Cenário:”. O cenário é composto por um nome e alguns passos, definidos pelas palavras-chave Given, When, Then, And e But (em português: Dado, Quando, Então, E e Mas). Para entender mais a organização do BDD e a definição de funcionalidades, cenários e passos, dê uma olhada em algum material sobre BDD (vastidão de material apenas em inglês =P).

Após criar a funcionalidade e o cenário, temos que definir os passos do nosso cenário. O cenário “Listando todos os remédios” possui três passos: “Dado que existem 10 remédios cadastrados no banco de dados”, “Quando eu vou para a página de listagem de remédios” e “Então eu deveria ver a listagem com o nome dos 10 remédios”. Precisamos definir o que o Freshen fará em cada um desses passos para garantir o funcionamento da funcionalidade especificada.

Vamos rodar o Freshen, para ver a saída neste momento. Quem sabe nosso teste passa sem fazermos nada =D

Vamos entender o comando executado: executamos o comando nosetests, que é o comando do Nose. Como o Freshen é um plugin do Nose, precisamos habilitá-lo utilizando a opção –with-freshen, e habilitamos o Django com a opção –with-django. Uma vez que escrevemos nossa funcionalidade em Português, temos que avisar ao Freshen que ele deve lê-la em português, por isso utilizamos a opção –language=pt. Por fim, utilizamos a opção -v para habilitar o modo verbose.

Agora, vamos entender a saída do comando: veja na primeira linha, que o Freshen encontrou funcionalidade “Listar remédios”, e dentro desta funcionalidade encontrou o cenário “Listando todos os remédios” com o passo “que existem 10 remédios cadastrados no banco de dados” indefinido. Então, vamos definir tal passo e executar o teste novamente. Os passos são definidos em um módulo chamado steps.py presente no mesmo diretório do arquivo da funcionalidade (features, dentro da aplicação).

Para definir os passos, utilizamos decorators correspondentes a estes passos: para o passo Given/Dado, utilizamos o decorator @Given; para o passo When/Quando, utilizanmos o decorator @When; e para o passo Then/Então, utilizamos o decorator @Then. Vamos definir nosso primeiro passo, utilizando o decorator @Given, e ver o que acontece ao executar o Freshen novamente após tal definição:

Note que nós recebemos um parâmetro para nossa função a partir do texto que define o passo. O formato deste parâmetro é definido por uma expressão regular. Atenção: o parâmetro passado para a função sempre é uma string, se você precisar trabalhar este parâmetro como um inteiro, ele deverá ser convertido (como aconteceu no nosso caso).

Na função acima, nós criamos uma lista chamada remedios dentro de um objeto chamado scc. Trata-se do contexto de armazenamento de objetos do Freshen. O Freshen da suporte a três tipos de contexto: glc, o contexto global, que nunca é apagado; ftc, o contexto de funcionalidade, que é apagado no início da execução de cada funcionalidade; e o scc, que é o contexto de cenário, apagado no início da execução de cada cenário. Quando armazenamos nossa lista de remédios dentro do contexto de cenário, significa que esta lista estará disponível em todos os passos deste cenário.

Agora, vamos executar novamente o Freshen para ver o que acontece:

E o feedback obtido foi: não encontrei esse classe Remedio. Isto ocorre por que nós não definimos nosso model Remedio. Então, vamos definí-lo, com apenas um nome, dentro do módulo models.py da aplicação delivery, e executar novamente o teste:

Agora, vamos novamente rodar nossos testes e ver o que acontece:

Nossa definição de passo agora passou, porém recebemos o feedback de outro passo indefinido: “eu vou para a página de listagem de remédios”. Vamos então definir este passo, utilizando o decorator @When:

Vamos entender o que foi feito aqui: o método começa fazendo um mock da aplicação do Django, tudo isso para garantir o mock interno do model. Assim, separamos nossa definição do banco de dados: quando o método Remedio.objects.all() for chamado, o objeto de mock, gerenciado pelo Ludibrio, retornará a nossa lista de remédios armazenadas no contexto do cenário. Pulando um pouco, na última linha da função validamos o nosso mock, ou seja, verificamos se o comportamento que esperávamos dele realmente aconteceu. Traduzindo: esta última linha garante que o método realmente foi invocado, mas onde?

Na linha superior, utilizamos o Client do Django para fazer uma requisição do tipo GET na URL ‘/delivery/models’ do nosso projeto. A resposta desta requisição é armazenada dentro do nosso contexto de cenário, em um objeto chamado response. Vamos novamente executar o Freshen e ver o que acontece:

E a resposta do Freshen ao nosso teste foi: Não encontrei o template 404.html! Nada a ver com nosso teste, certo? Acontece que, na verdade, a URL /delivery/remedios não foi encontrada e o Django tenta renderizar o template 404.html nestes casos, mas não importa isso no momento. Nosso desejo aqui é fazer a definição de passo passar, então vamo simplesmente colocar um arquivo chamado 404.html dentro do nosso diretório de templates, chamar o Freshen novamente e ver o que acontece:

A validação do mock falhou. Simplesmente por que o mock não teve o comportamento esperado, que é a chamada ao método Remedio.objects.all(). Vamos fazer agora com que a requisição na URL /delivery/remedios seja mapeada para uma view que deverá fazer a chamada ao nosso método.

Primeiro, vamos definir a nossa view: dentro do módulo view da aplicação delivery, vamos criar a função a ser mapeada para a URL /delivery/remedios. Esta função se chamará lista_remedios:

Note que aqui novamente fizemos apenas o necessário para que a definição de passo passe. Tudo o que precisamos é da chamada a Remedio.objects.all(). Mas apenas isso não é suficiente, precisamos ainda mapear a URL /delivery/remedios para a nossa view recém-definida. Para isso, criaremos o model urls.py dentro da aplicação delivery com o seguinte conteúdo:

Depois de definir tal arquivo, vamos incluir dentro do módulo urls.py principal do projeto, que deverá ficar desta forma:

Com o mapeamento de URLs configurado e a view devidamente criada, vamos novamente executar o Freshen para obter o feedback:

A parte boa é que nossa definição para o segundo passou funcionou! Agora o Freshen encontrou outro passo indefinido: “eu deveria ver a listagem com o nome dos 10 remédios”. Vamos agora implementar este passo, testando o conteúdo da resposta obtida na requisição à URL /delivery/remedios. Para definir este passo, utilizamos o decorator @Then:

Montamos o elemento HTML li com o conteúdo esperado e depois testamos se todos os nomes de remédios estão presentes na resposta da requisição, cada um em seu respectivo li. Depois fazemos um assert, para verificar se o conteúdo que definimos acima está presente no conteúdo da resposta da requisição. Ao chamar novamente o Freshen, obtemos a seguinte saída:

E aí está: um AssertionError, o que significa que nossa definição falhou e o conteúdo esperado não veio na resposta da requisição. Para fazer com que esta definição funcione, vamos refatorar nossa view, para que ela renderize um template e dentro deste template teremos nossos elementos li com os nomes dos remédios. Eis o código da view, refatorado:

Então devemos criar um template chamado listar_remedios.html. Como é um template da aplicação, coloque ele dentro do diretório templates da aplicação delivery. O conteúdo do template pode ser visto no Gist: http://gist.github.com/450936

Acredito que aqui tudo está pronto. Vamos perguntar ao Freshen?

Nossa definição de passo passou, e não existe nenhum passo indefinido! Nosso trabalho está pronto, agora basta repetir o ciclo para implementar todas as funcionalidades do sistema, mas isso fica por conta de vocês.

O código deste projeto está disponível no Github: http://github.com/franciscosouza/farmacia.

1. Suporte ao uso de vários bancos de dados: Como o nome indica, agora é possível utilizar vários bancos de dados no Django. Isso significa que a configuração do banco de dados no arquivo settings.py não acontece mais da mesma forma. Cada configuração de banco de dados é batizada com um nome, e tem seus próprios parâmetros e na hora de executar alguma tarefa no banco de dados, você especifica qual banco de dados deseja utilizar ao executar uma query através do método using da classe QuerySet, já na hora de gravar registros no banco de dados, você utiliza o parâmetro using para informar qual banco de dados utilizar. Não entendeu? Que tal um pouco de código?

Com Django 1.1:

Agora, utilizando o Django 1.2:

Note que configuramos dois bancos de dados, inclusive de tipos diferentes: um SQLite3, que identificamos como default e um MySQL, que identificamos como alternative.

Existem recursos mais “avançados”, como o roteamento automático do banco de dados (utilizar um banco de dados apenas para leitura e outro apenas para escrita, por exemplo), que podem ser conferidos na documentação oficial do Django.

2. Validação de modelos e introdução de validators: Agora os modelos são capazes de se auto-validar-se a si mesmos e suporte à construção de validadores personalizados (recomendo não usar esse termo jamais =P custom validators soa bem melhor), que são configurados diretamente nos Models ou nos Forms.

Os novos validators do Django funcionam de forma semelhante aos validators do WTForms, que abordei no blogpost anterior. Assim, recomendo a leitura do blogpost de integração do WTForms com o Pylons para ver um pouco mais dos validators.

Entendendo um pouco mais da validação de modelos, podemos criar um modelo qualquer e definir o validate_even (que valida se um número é par). Assim, vamos configurar nosso model para aceitar somente números pares em um de seus fields. Um validator nada mais é do que uma função que recebe um parâmetro e valida ele (!):

E no nosso model nós simplesmente passamos o objeto validate_even dentro de uma lista para o parâmetro validators:

Atenção: a validação dos objetos deve ser feita de forma explícita. O método save não executa a validação implicitamente.

3. Framework de mensagens: O Django agora inclui um framework poderoso e personalizável para envio de mensagens, utilizadas em três níveis: info, warning e error. A configuração do framework de mensagens é um pouco mais trabalhosa, então recomendo fortemente a leitura da documentação oficial.

4. Nova template-tag “if”: O Django 1.2 trouxe uma melhoria na template tag if, que agora tornou-se mais poderosa. Esta melhoria pode ser um pouco polêmica, uma vez que facilita a implementação de lógica no template. A ideia aqui é substituir templates tags como ifequal e ifnotequal, além de introduzir o suporte ao uso de template filters com a tag if. Vamos ver um pouco de código…

No Django 1.1:

No Django 1.2:

Ambos os códigos comparam se duas variáveis (a e b) são diferentes. A nova template tag trouxe o suporte ao uso de operadores, como demonstrado no exemplo acima, e também ao uso de template filters, como demonstrado abaixo:

O código acima compara se dois objetos são equivalentes, mas antes da comparação, converte ambos para minúsculo utilizando o template filter lower.

Existem diversos outros recursos, como template caching, e-mail backends, melhorias no sistema de autenticação e autorização, dentre outras. Para mais detalhes, confira as notas de lançamento do Django 1.2 e a documentação oficial.

No Django, é comum vermos pessoas falando sobre o uso de testes unitários e doctests, para um desenvolvimento guiado por testes, mas e como seria utilizar BDD no Django? O que já existe de BDD em Python?

Na última Python Brasil, Hugo Lopes apresentou uma palestra intitulada “Behavior Driven Development (BDD) em Python”, onde apresentou alguns conceitos de BDD e algumas ferramentas e projetos de BDD em Python. Quem quiser saber mais sobre a palestra, pode assistir a palestra na online no blip.tv.

Ainda não existe algo como o RSpec e o Cucumber sendo utilizado em larga escala junto ao Django, mas vou tentar mostrar aqui um pouco do uso das ferramentas apresentadas pelo Hugo, em conjunto com Django. Os passos para fazer algo em BDD é semelhante aos passos do TDD:

1. Escreva o comportamento desejado;
2. Escreva o código para atender ao comportamento desejado;
3. Teste se o código escrito realmente atende ao comportamento desejado;
4. Refatore;
5. Entre em loop com os passos anteriores :)

Podemos ver um pouco mais disso em um exemplo mais prático. Imaginando que estejamos desenvolvendo um sistema acadêmico, e para o módulo de controle de matrícula haja a seguinte especificação história:

Eu como secretário gostaria de cadastrar um aluno no sistema, informando seu nome e sua data de nascimento.

Bom, aí está nossa história. Agora, vamos escrever o comportamento dessa história. Utilizando PyCukes, o comportamento fica definido desta forma:

A especificação em português e bem bonitinha (poderia ser criada pelo seu cliente, com sua orientação). Este é o formato aceito pelo PyCukes. Agora basta traduzir os passos de cada cenário. Criamos apenas o primeiro cenário, que diz que o aluno não pode ser cadastrado sem nome. Então vamos fazer isso funcionar :)

Como é um projeto Django, devemos criar um model nosso alunos, certo? Errado, é BDD. Primeiro vem o comportamento, depois o código :) Depois de definirmos o comportamento em linguagem natural, precisamos ensinar ao PyCukes o que ele deve fazer com cada um dos passos do nosso cenário:

Note na linha 4 o código import set_django. Trata-se do módulo que configura para que o projeto do Django possa ser enxergado pelo PyCukes. O código deste módulo é o seguinte:

Ao rodarmos o Pycukes, obteremos um erro, informando que a classe Aluno não existe:

Ainda não vale por que foi um erro do Python, e não do Pycukes, certo? Então vamos criar o model Aluno e rodar o Pycukes agora com o aluno certinho, para ver se funciona?

Rodando o PyCukes agora, tudo funciona certinho:

Note que a garantia de funcionalidade do comportamento é seguirmos o padrão do Django, dizendo que não aceitaremos null no atributo nome da classe Aluno.

Bom, aí está, um pouco de BDD, baseado no trio Given, When e Then. Quem quiser pode explorar mais o pycukes no repositório do projeto no Github.

Futuramente devo trazer um exemplo mais completo. O código do projeto deste post pode ser encontrado no Github: http://github.com/franciscosouza/post-bdd-django.

Bom, para começar, criamos o nosso projeto no Django, com a aplicação ibge_cidades (talvez o nome não seja melhor, mas imagine que seja uma nova implementação do IBGE Cidades xD). Três comandos básicos e estamos lá:

$ django-admin.py startproject ibge_portal
$ cd ibge_portal
$ django-admin.py startapp ibge_cidades

Agora, dentro da aplicação ibge_cidades, vamos definir nossos modelos no arquivo models.py:

Modelos simples para um exemplo bem simples =) Agora, vamos popular um pouco nosso banco de dados, apenas para ter uma “gigante” massa de dados:

Com o nosso banco de dados super populado e nossos modelos enfim definidos, podemos seguir em frente e construir nossa API :) A API será servida no diretório api, assim, basta criar um pacote Python chamado api na raiz do projeto:

$ mkdir api
$ touch api/__init__.py

Adicionamos ainda os arquivos urls.py e handlers.py ao nosso diretório api:

$ touch api/urls.py
$ touch api/handlers.py

O piston trabalha com resources, que são objetos modelados por uma classe que herda de BaseHandler. Cada resource pode estar relacionado diretamente com um model. Vamos definir dois handlers: EstadoHandler e CidadeHandler:

O método read de um resource responde a uma requisição do tipo GET, existem ainda os métodos create, update e delete para responder às requisições do tipo POST, PUT e DELETE, respectivamente. O método read do EstadoHandler retornará a lista com todos os estados, em formato JSON, já o método read do resource CidadeHandler receberá a sigla de um estado e listará todas as cidades daquele estado. A implementação disso é bem simples:

Duas linhas pra cada método e a API está quase pronta. O que falta? Apenas o mapeamento de URLs, que fica da seguinte forma:

• GET /api/estados: Retorna a lista de todos estados;
• GET /api/cidades/<sigla>: Retorna a lista de todas as cidades do estado identificado por <sigla>.

Temos um arquivo urls.py na raiz do projeto e outro no diretório api. Primeiro, editamos o arquivo da raiz do projeto, para adicionar um include ao outro arquivo:

Em seguida adicionamos ao api/urls.py o mapeamento para os resources:

Agora sim a API está pronta, e já podemos construir uma aplicação utilizando Java Swing para acessar a API :) O código da aplicação Java é bem simples (e pode estar despadronizado, desculpe programadores Java =/). Basicamente, existem dois métodos, um para preencher cada combo:

O código completo dos dois projetos está no Bitbucket:

• Lado servidor, Django: http://bitbucket.org/franciscosouza/exemplo-api-django/;
• Lado cliente, Java Swing: http://bitbucket.org/franciscosouza/exemplo-api-java-swing/.

O famoso padrão MVC (model view controller) encaixa-se como uma luva para aplicações web, e é melhor aproveitado quando explorado por um framework. Frameworks implementam o padrão MVC de forma realmente padronizada (o que às vezes varia, é a nomenclatura, como no Django), explorando ao máximo o padrão MVC.

Existem inúmeros benefícios alcançados ao utilizar frameworks, como o ganho de produtividade, a redução da possibilidade de erros (produtividade, de novo), maior nível de abstração (produtividade?), compatibilidade e integração entre aplicações (produtividade!), desenvolvimento de forma mais segura e prazerosa :) Além destes benefícios, há a vantagem de contar com o apoio da comunidade, já que os frameworks são usados em larga escala e geralmente são comunitários.

Contra estes benefícios, existem poucas desvantagens e muitos mitos. Em grande parte das discussões que envolvem o uso de frameworks, percebe-se no time “do contra” muito preconceito, argumentos recheados de mitos e, por vezes, confusões e conclusões baseadas em frustrações passadas. Alguns dos mitos e confusões mais comuns são:

• Frameworks amputam o desenvolvedor. Algumas pessoas defendem que ao usarmos frameworks passamos mais tempo configurando do que programando. Em alguns casos, tais pessoas têm razão (experimente fazer algo bem simples em frameworks que não trazem convention over configuration), mas, na maioria dos casos, elas estão incorretas. Assim, defender o não-uso de frameworks argumentando que o desenvolvedor crescerá mais pessoal e profissionalmente fazendo tudo “na mão” é algo bastante errado, até por que os frameworks atuam principalmente nas partes mais chatas. Não é fazendo validação de formulário e tratamento de requisições com type cast que alguém se torna um excelente programador;
• Não é boa ideia usar os frameworks modernos, pois os antigos eram muito complexos. “Eu tenho um trauma com frameworks, usei isso um tempo atrás e não deu certo”. Preconceito discriminatório não é bom em informática nem em nenhum outro lugar. Hoje em dia, os frameworks são muito mais modernos e ágeis do que as ferramentas de anos atrás. Não faz sentido algum julgar uma ferramenta que você não conhece baseando em uma que você conhece (e não gosta), não da pra justificar a recusa do VRaptor 3 baseando-se numa má experiência com o Struts 1.1 em 2003, ou de um dos vários frameworks Python modernos por que em 2002 você testou o Zope e achou ele complicado;
• Frameworks provocam perda de desempenho. Sim, provocam, mas isso geralmente é imperceptível. Mesmo que haja uma gigante e complexa estrutura (o que é incomum nos frameworks mais modernos), a interpretação de uma linguagem de templates e mais algumas firulas que fazem com que se perca desempenho, dificilmente o usuário final perceberá a diferença. Além disso, os frameworks também fornecem recursos como cache em memória para que o desempenho com eles seja melhor do que sem eles;
• Se um framework tiver uma falha de segurança, minha aplicação fica vulnerável. Sim, é verdade, mas frameworks raramente têm falhas de segurança (pesquise no Google sobre falhas de segurança em frameworks). Frameworks bons são testados, utilizados e desenvolvidos massivamente; e costumam ter grande parte do código coberta por testes, o que garante um alto índice de segurança e pequena possibilidade de falha.
• Usar framework? Eu não gosto de WordPress nem Joomla, são pesados! Por mais incrível que possa parecer, existem profissionais que atuam com desenvolvimento web e não sabem ao certo o que é framework. Esta falta de conhecimento é comum em alguns profissionais totalmente técnicos (geralmente 100% auto-didatas), desprovidos de alguns conceitos fundamentais. É um caso bem difícil de solucionar, mas o incentivo da comunidade e a exigência do mercado de um nível maior de conhecimento de conceitos pode, a longo prazo, solucionar este problema.

Hoje em dia, dificilmente alguém consegue levantar argumentos válidos contra o uso de frameworks web. Cases grandes como Twitter, SourceForge e BitTorrent.com mostram que os “peixes grandes” acreditam e, consequentemente, investem em frameworks web.

Frameworks web são utilizados em larga escala. Não é moda, é uma necessidade comprovada pela comunidade e pelo meio corporativo, e alguns mitos têm que ser derrubados.

Com um pouco de introspecção (bem pouco), o método __call__ analisa o objeto request e faz a chamada a um método (do objeto RestView) de acordo com o método da requisição (HTTP, aqueles verbos legais, tipo PUT, POST, GET, DELETE). Basicamente, um resource seria uma classe descendente de RestView. Na nossa classe resource, implementaríamos um método chamado GET para tratar as requisições GET, um método POST para tratar as requisições POST, e assim sucessivamente. Veja um exemplo de resource

:

Assim, poderíamos fazer o seguinte mapeamento no urls.py, para a classe acima:

Note que um objeto é passado por parâmetro, e não a classe em si. Esta solução funciona, pelo menos para trabalhar com diferentes tipos de requisição a uma mesma URL. Mas e no caso de queremos explorar mais a REST, com uso de tecnologias como JSON e XML? Certamente, nossa classe RestView não é capaz de nos atender, seria necessário estendê-la, ou simplesmente procurar uma API completa para trabalhar com REST no Django. Existem duas ferramentas muito boas aqui: django-rest e django-piston, sendo a segunda uma incrível e completa ferramenta para trabalhar com diversos recursos, como integração com os models e forms do Django; autenticação plugável (incluindo uma interface transparente para trabalhar com OAuth. Pelas características, vemos que o Piston é muito mais do que uma API RESTful, é uma ferramenta indispensável ao desenvolvedor Django :) Apesar de toda a empolgação com o Piston, vamos deixar ele parar depois. Antes, vamos ao django-rest. Trata-se de uma interface RESTful, quem fornece integração com os models e também algumas generic views inclusas no pacote, facilitando a criação de CRUDs, por exemplo. Existem ainda outros projetos interessantes, como o django-restful-models-views, que é uma aplicação plugável, mas vou abordar aqui apenas as ferramentas citadas no parágrafo anterior. Basicamente, o django-rest trabalha de duas formas: “semi-automático”, onde fornecemos o modelo e ele “se vira” (semelhante às generic views); ou de forma manual, onde configuramos os resources manualmente, muito comum quando não estamos trabalhando restritamente com models. Um exemplo de código ligado ao model User, que possui os atributos name e age, seria o seguinte (arquivo urls.py

):

O objeto user_resource armazena as configurações do nosso resource. Note o atributo responder, que armazena o tipo de resposta. Aqui, poderíamos utilizar além de TemplateResponder, JSONResponder, XMLResponder, dentre outros tipos de retorno. Na linha 8, definimos os métodos que serão permitidos. Assim, este resource responderá pelas seguintes requisições:

• GET /users: Uma lista com todos os usuários;
• GET /users/<id>: Visualização dos detalhes de um usuário;
• POST /users: Cria um usuário;
• PUT /users/<id>: Atualiza os dados de um usuário;
• DELETE /users/<id>: Apaga um usuário.

A documentação do django-rest é bem pobre. Para entender alguns comportamentos básicos, tive que olhar o código fonte da ferramenta. Por isso, vamos agora para a parte mais legal e interessante: django-piston.

Diferente do django-rest, o django-piston possui excelente documentação, e também uma comunidade ativa, sendo a melhor alternativa quando se trata de API RESTful. Vamos rapidamente ver como tratar o exemplo com o model User descrito acima. É importante notar que o django-piston é bastante aconselhável para a criação de APIs. Assim, ele fornece MUITA coisa para trabalhar com APIs, é totalmente voltado para isto. Vamos distorcê-lo um pouco e fazer com que ele transfira dados para os templates.

Precisamos criar um resource, e para a criação de um resource é necessário que antes seja criado um handler. Os handlers são utilizados pelos resource para tratar as requisições. Um handler é um objeto modelado pela classe BaseHandler (por uma descendente de BaseHandler, para ser mais exato). Veja um exemplo de handler:

Este handler é salvo em um arquivo chamado handlers.py, dentro do diretório de nossa aplicação. Agora, basta adicionar o mapeamento da URL e um resource baseado no nosso UserHandler passa a tratar as requisições, de forma RESTful. Veja como ficaria o urls.py:

O django-piston é uma ferramenta incrível, com muitos recursos, que provavelmente voltará a aparecer aqui no blog. Recomendo que mergulhe nela e veja como é simples criar APIs RESTful usando Django. Em breve eu falo mais sobre django-piston focando no desenvolvimento de APIs :)

$ django-admin.py startproject abcdef_academico

Após executarmos este comando, acessamos o diretório abcdef_academico, para criar a nossa aplicação, que chamaremos de alunos:

$ django-admin.py startapp alunos

Como já aprendemos, agora que criamos nossa aplicação e nosso projeto, devemos criar os models. No nosso caso, a classe aluno vai ter apenas os campos nome e idade, igualzinho era com a classe Usuario no exemplo anterior. Assim, o código Python do models.py fica da seguinte forma:

Como vamos trabalhar com generic views, não vamos precisar criar o ModelForm. Passaremos para a view apenas o nosso model e ela vai se virar para gerenciar tudo, legal né?! =) Vamos apenas acertar o arquivo settings.py, com as mesmas configurações do settings.py do post anterior, sem as generic views. Para utilizar as generic views, nada muda no settings.py.

Agora podemos começar a trabalhar aonde a coisa acontece: no arquivo urls.py. Lá que definimos que vamos usar uma view genérica, mapeando uma URL para uma view genérica, que recebe como parâmetro algumas informações. Vamos primeiro criar o formulário de cadastro de um novo aluno. Para isto, adicione as duas linhas de import ao início do arquivo:

Em seguida, configure um dicionário, chamado params_novo_aluno, que contém todos os parâmetros que a generic view django.views.generic.create_update.create_object (que vamos utilizar) necessita. Este dicionário, fica desta forma:

O primeiro parâmetro, chamado model, refere-se ao modelo para o qual será gerado o formulário, a validação e a inserção. Já o segundo parâmetro, post_save_redirect, indica para onde o usuário será redirecionado após o objeto ser salvo no banco de dados. A URL /alunos/ será responsável por listar todos os alunos cadastrados.

Ainda no arquivo urls.py, falta apenas definir a URL pela qual será acessado o tal formulário. Vamos adotar o padrão /alunos/novo, assim, adicionamos à tupla urlpatterns o seguinte item:

Desta forma, já temos o mapeamento. Falta apenas o template! Note que em momento algum especificamos qual template utilizaremos. Isto ocorre por que este generic view padroniza o nome do template (mas é possível alterar, passando o parâmetro template_name). Desta forma, o padrão é que o arquivo de template se chame _form.html e fique dentro de um diretório com o nome da aplicação, no diretório de templates. No nosso caso, teremos então templates/alunos/aluno_form.html. O código do template fica bem simples também:

Agora que já temos nosso formulário de cadastro funcionando, podemos passar para a página de leitura, o R do CRUD. Vamos criar a página com listagem de todos os alunos e a página de visualização dos detalhes de um aluno. Para isto, utilizamos outro outro conjunto de generic views, incluso no módulodjango.views.generic.list_detail. Adicione, então, o seguinte import ao início do arquivo urls.py:

E criamos um novo pattern, relativo à URL /alunos, que mostrará uma lista de alunos. Então, fica a seguinte entrada no urls.py:

No caso desta generic view, o nome padrão para o template é <model>_list.html. Novamente, construímos nosso template, que fica no caminho templates/alunos/aluno_list.html:

Agora que temos a listagem de alunos pronta, vamos visualizar os detalhes de cada aluno. Para isto, utilizaremos a generic view django.views.generic.list_detail.object_detail. Esta view também recebe como parâmetro um queryset do Django, além de um id, que vem como parâmetro na URL, chamado object_id. Esta view também está capacitada a trabalhar com slugs. Assim, teremos nossa view sendo acessada por este endereço: /alunos/<object_id>. Para fazer isso, bastam apenas dois passos: adicionar um pattern ao urls.py e criar o template aluno_detail.html dentro do subdiretório alunos no diretório de templates. O mapeamento do pattern fica da seguinte forma:

É importante que o parâmetro da URL se chame object_id, pois é o nome que a view recebe. O template fica também bem simples de entender:

Neste template já criamos a referência para as páginas de edição e remoção do objeto. Para editar, precisamos apenas adicionar a chamada à view django.views.generic.create_update.update_object sem a necessidade de um novo template, pois esta view utiliza por padrão o mesmo template da view create_object. Assim, basta adicionar um novo pattern ao urls.py:

E, para finalizar, vamos para a parte de apagar o objeto. O Django trabalha com o padrão de partir para uma página de confirmação, então aqui precisaremos de um template chamado aluno_confirm_delete.html. Antes, mapeamos a URL /alunos/<object_id>/apagar para nossa generic view django.views.generic.delete_object e, em seguida, criamos o template necessário.

Para seguir o padrão, vou deixar uma parte sem postar código aqui no blog, mas o projeto completo está disponível no BitBucket. E essa foi uma rápida revisão da criação de CRUDs usando Django! =)

A instalação do Django também é bem simples e se da pelo easy_install, assim como no Pylons. Então, basta acessar o terminal e digitar o comando:

# easy_install -U django

O Django fornece a ferramenta de linha de comando django-admin para criação de projetos e aplicações. Projetos Django se dividem em aplicações e é importante entender o conceito de Django Apps, para evitar o uso inadequado do framework. Vamos chamar nosso projeto de dj_portal_abc, então, para criar o projeto, basta executar o comando:

$ django-admin.py startproject dj_portal_abc

Será criado o diretório dj_portal_abc, com estrutura semelhante à seguinte:

Sim, a estrutura é muito mais simples que a estrutura do Pylons, mas a criança ainda vai crescer :) Agora que criamos o projeto, vamos configurá-lo. Faremos apenas alguns ajustes básicos: o banco de dados utilizado; o idioma padrão e também a timezone padrão. Abra o arquivo settings.py e encontre o seguinte trecho de configuração de banco de dados:

Altere a variável DATABASE_ENGINE para sqlite3 e a variável DATABASE_NAME para portal_abc.db, ficando assim (note as linhas em destaque):

Agora vamos alterar a TIME_ZONE para São Paulo e o idioma padrão para português brasileiro. Logo abaixo da configuração do banco de dados, você encontra as seguintes linhas no settings.py:

Configure a variável TIME_ZONE como America/Sao_Paulo e a variável LANGUAGE_CODE como pt-br, ficando assim:

Agora que terminamos de configurar o projeto, vamos criar nossa aplicação. Vamos novamente utilizar o django-admin.py para gerar uma aplicação. Como no caso de iniciar um projeto, usamos startproject, para iniciar uma aplicação, usamos startapp. Intuitivo, não?

$ django-admin-py startapp usuarios

Após executar este comando, temos um novo diretório e a estrutura mudou um pouco. O Django criou o diretório com o nome da aplicação, e colocou lá alguns arquivos: models.py, onde definimos nossos modelos; tests.py, onde definimos nossos testes unitários (e também doctests); e views.py, nossa controladora que tem nome estranho =P Vamos começar definindo nosso model. Diferente do SQL Alchemy, usado no Pylons, o Django implementa o modelo de ORM chamado ActiveRecord. Reinout van Rees considera o pattern ActiveRecord excelente para pequenas queries, mas problemático para estruturas mais complexas. A disputa DataMapper x ActiveRecord, e a preferência por DataMapper, foi fator fundamental na decisão do SourceForge adotar Turbo Gears (outro framework Python, que também utiliza SQL Alchemy, muito influenciado pelo Pylons) ao invés Django, Ruby on Rails ou Cake PHP.

“Sem querer querendo”, eu vou apresentar um pouco uma comparação entre ActiveRecord e DataMapper em Python, estabelecida nas ferramentas Django ORM vs. SQL Alchemy. No meu exemplo mega simples, ActiveRecord será a melhor resposta sem sombra de dúvidas, mas não deixe de ler sobre o assunto para formar uma opinião.

Definindo o Model

No Django, os models são definidos dentro da aplicação, no módulo models.py. Cada model é uma classe que herda de django.db.models.Model. Abaixo segue nosso model Usuario:

Note que a classe ficou bem simples. Agora, vamos dizer ao Django que vamos utilizar a aplicação usuarios em nosso projeto dj_portal_abc e depois criar o banco de dados. Para isso, basta abrir o arquivo settings.py novamente e buscar a tupla INSTALLED_APPS. Adicione ao final da tupla o nome da nossa aplicação,  ficando desta forma a tupla:

Agora basta utilizar o manage.py, que permite gerenciar o banco de dados e também a execução da aplicação. Para criar as tabelas no banco de dados, rodamos o comando:

$ python manage.py syncdb

Como a aplicação django.contrib.auth está instalada, ele vai perguntar se desejamos criar um usuário. Já que este recurso não vai ser utilizado, podemos simplesmente responder “no”.

“Controllers” e URL’s no Django

Como visto no começo, controllers são chamados de views no Django. Assim, definimos nossas funções de controle no módulo views.py da nossa aplicação. O Django não fornece um padrão de acesso às URL’s, sendo necessário configurar todas as URLs para uso. A ideia de usar REST com Django fica como assunto de um próximo post. Neste CRUD, vamos seguir o padrão torto de trabalhar de maneira “não-RESTful”.

Vamos trabalhar na mesma ordem, criando primeiramente a view responsável por listar os usuários. Vamos chamá-la de listar_usuarios. Dentro do nosso arquivo views.py, da aplicação usuarios, adicionamos o seguinte código:

Após criar a view, precisamos mapeá-la na configuração de urls. Abra o módulo urls.py e adicione ao objeto urlpatterns o item respectivo à view criada. Ficará desta forma:

Vemos na linha 11 (em destaque) a configuração: dizemos que o endereço /usuarios/ será tratado pela view listar_usuarios. Por mais chato que isso possa parecer, tem que ser feito assim, infelizmente. Se executarmos o servidor agora, através do comando

$ python manage.py runserver

obteremos um erro: TemplateDoesNotExist at /usuarios/. Dentro da nossa view, utilizamos o atalho render_to_response, para renderizar nosso template ‘usuarios/listar.html’, passando para ele todas as variáveis locais (no caso, apenas a variável usuarios). Mas em que momento definimos este template? Em momento algum!

Vamos, antes de mais nada, configurar no settings.py qual será nosso diretório com os templates. Assim, criamos o diretório templates na raiz do nosso projeto (junto aos arquivos manage.py e settings.py), e abrimos o settings.py para indicar que aquele será nosso diretório de templates, na tupla TEMPLATE_DIRS. Para obter o caminho absoluto, fazemos uso do módulo os, da biblioteca padrão do Python. Assim, adiciona as duas linhas ao começo do arquivo settings.py:

Em seguida, altere a tupla TEMPLATE_DIRS, para que fique desta forma:

Após isso, criamos o arquivo base.html, que é nosso template que servirá de base. Este arquivo deve ficar dentro do diretório templates, e tem simplesmente o seguinte código:

Após esta definição, crie o template da listagem de usuários, dentro do diretório templates/usuarios, com o nome listar.html.  Este template fica com o seguinte código:

Novamente, não vou postar o código de todos os templates, para evitar que o post cresça muito. Daqui pra frente, colocarei todos os templates no pastebin e todo o código estará disponível no Bitbucket.

Para não ficar abrindo e mapeando toda hora as URLs, vamos acessar o arquivo e mapear todas elas:

• /usuarios: Uma lista com todos os usuários;
• /usuarios/novo: Cria um novo usuário (exibe o formulário e também processa o formulário);
• /usuarios/{id}: Exibe os dados de um usuário (visualização);
• /usuarios/{id}/apagar: Apaga um usuário do banco de dados;
• /usuarios/{id}/editar: Edita os dados de um usuário.

Assim, nosso arquivo urls.py fica assim:

Vamos agora criar todas essas views mapeadas. Vamos fazer na ordem: construir o formulário de cadastro, antes de tudo. Antes de criar a nossa view novo, definiremos o formulário, utilizando o recurso de formulário do Django (Django Forms). Para isto, crie um arquivo chamado forms.py dentro do diretório da aplicação usuarios. Este arquivo conterá nosso form, que é uma classe que herda da classe django.forms.Form. Além da classe django.forms.Form, o Django Forms fornece a classe django.forms.ModelForm, que se integra com os models e faz quase tudo de forma transparente. Veja como ficou a classe UsuarioForm:

Note que o Django faz tudo “por baixo dos panos”, relacionando a classe de modelo com o formulário. Também seria possível definir manualmente todos os campos. Para mais detalhes sobre Django Forms, consulte a documentação oficial.

Com a classe de formulário definida, podemos partir agora para nossa view, que fica com o seguinte código:

Note que o Django faz algumas “mágicas” nas linhas destacadas: validação automática e salva os dados no banco de dados. Tudo por causa da uma forte e acoplada integração com os models. Eu sei que isso de perguntar se o método do request é POST lembra um pouco PHP, mas é a forma como geralmente se trabalha nas views :)

Agora é só definir o template, que recebe o formulário pela variável forms. O código do template está aqui: http://pastebin.com/f1479663c. Nossa view e nosso template estão prontos, vamos seguir a ordem e criar agora a view de visualização dos dados, chamada ver_usuario. Seu código fica bem simples:

Depois de definir a view, basta construir o template. O código do template usuarios/ver.html é o seguinte: http://pastebin.com/f47a43b9a. Novamente, vou deixar a view editar por conta, e vou terminar na view apagar, que é a mais simples de toda:

E pronto! =) Aí está, podemos rodar e testar nosso projeto. O código completo do projeto pode ser obtido no Bitbucket.

Na primeira linha é feito um select na tabela ligada à classe Pessoa pesquisando id = 1, e na segunda linha é feito um novo select na tabela ligada à classe Carros pesquisando o id da pessoa (fk) = 1.

Imagine que tenhamos o seguinte modelo de classes:

Basicamente o que eu quero é saber qual o continente de um cliente (id=1). Em Python/Django, basta fazer o seguinte:

Mas e aí, quantas vezes eu vou no banco de dados fazendo isso? Vamos unir o interpretador interativo + o debug do Django! (:

Note: foram duas linhas de comando e SEIS acessos ao banco de dados. Foi feito um select para cada entidade. Mas e agora, tem como resolver isso? (: Graças a Deus, sim! Basta usar a ideia do select_related. Vamos fazer um novo teste usando select_related? Aí está:

Bem melhor: duas linhas de código, um select! Apenas um acesso ao banco, seu DBA não vai caçar você insanamente por acessar 800 milhões de vezes o banco de dados, e sua aplicação estará BEEEM mais rápida =D

Bom, aí fica a dica para os iniciantes (já que todos os blog tutorials ignoram isso de select_related). Good coding (:

O projeto deste exemplo está no Bitbucket: http://bitbucket.org/franciscosouza/exemplo_select/.

Na página /sobre, por exemplo, eu estava fazendo algo bem escroto: escrevendo o conteúdo nu e cru no template. Isso não é bom, afinal de contas, qualquer alteração implicaria em um novo upload da aplicação. Eu precisava de algo dinâmico, sabia que existiam as Flatpages e tinha duas opções: buscar uma forma de usar as Flatpages (e o Admin) no AppEngine, ou desenvolver algo como um “gerenciador de conteúdos”, para que eu pudesse cadastrar minhas páginas e fazer todo o gerenciamento via web. Essas duas opções viraram passos: primeiro eu fui buscar, e encontrei…

O projeto app-engine-patch traz diversos recursos do Django para uso no AppEngine não presentes no Django padrão do Google App Engine (ou na versão SVN), como a interface do admin, o uso das funções de e-mail próprias do Django, uso da autenticação do Django, flatpages, o gerenciamento utilizando o manage.py (com manage.py upload, para enviar a aplicação, por exemplo) e muito mais!

Vou passar rapidamente pelo meu roteiro de migração, no começo tive dificuldades, mas no final foi muito de boa. Baixei o projeto exemplo, copiei o diretório common para dentro do meu projeto, fiz um “merge” do meu settings.py com o settings.py do projeto exemplo, substituí meu manage.py pelo manage.py de exemplo e estava lá, com suporte ao admin e às flatpages.

E agora a /sobre/ é uma flatpage. Não muda nada pra quem vê, mas pra quem gerencia, é um progresso e tanto (: Adicionalmente, resolvi disponibilizar o código do site no Bitbucket: http://bitbucket.org/franciscosouza/website/.

Observação: Um problema que tive foi o uso do meu e-mail no Google Apps, o app-engine-patch não permite fazer a migração do banco de dados ou qualquer acesso remoto usando um usuário de um domínio do Google Apps. Para migrar o banco de dados, você deve usar um Gmail ou outra conta Google (:

Observação 2: Tive um outro problema com um índice para uso do admin. O AppEngine localmente não gerou o índice automaticamente, então tive que adicionar um índice ao index.yaml:

De acordo com o site oficial, e uma tradução minha, mais ou menos feita ao pé da letra, “o projeto NEBULA é um ambiente de cloud computing desenvolvido no NASA Ames Research Center, integrando um conjunto de soluções opensource. O objetivo é prover um ambiente de alta capacidade de processamento, armazenamento e conectividade, usando virtualização para ganho de escalabilidade e maior controle de custos”.

De acordo com o site oficial, o Django foi selecionado após um extensivo estudo de mercado, sendo considerado o framework de aplicações mais adequado para o projeto! :)

Para conhecer melhor o Projeto NEBULA, visite o site oficial. Para conhecer melhor o Django, visite o site oficial, o site da comunidade brasileira ou mesmo o livro “Aprendendo Django no Planeta Terra”, do Marinho Brandão.

• Auriance Web Hosting: Suporta Django em todos os planos (mod_python);
• KingHost: Suporta Django nos planos Linux Mega, Turbo e Nitro (mod_wsgi);
• Locaweb: Suporta Django em todos os planos Linux (mod_wsgi);
• PyTown: Hospedagem especializada em Python. Suporta diversos frameworks (mais flexível);
• UOL Host: Suporta Django em todos os planos Linux (mod_python);
• TeHospedo: Suporta Django em todos os planos Linux (FastCGI).

Se você sabe algum, por favor entre em contato comigo e me passe! ;)

O livro, que é aberto, foi disponibilizado para download em PDF e também foi lançado em versão editada. Clique aqui para baixar e/ou aqui para ver informações de compra.

Vale lembrar que o livro continua existindo em sua versão online, que pode ser acompanhada passo a passo no site.