Turbogears, Django e Plone

Nesse feriado resolvi dedicar um tempo para testar os frameworks de desenvolvimento Web disponíveis em Python para poder escolher um deles e iniciar o desenvolvimento de um pequeno sistema para cadatro de “Palestras e Palestrantes”. Para essa tarefa escolhi os 3 frameworks mais usados atualmente: TurboGears, Django e Zope/Plone (o Plone não é um framework, mas vou tratá-lo assim para simplificar o texto).

Eu já conhecia um pouco esses frameworks e até já tinha um preferido (TurboGears) e um outro com o qual já tinha um certo preconceito (Zope/Plone). O preconceito com o Zope/Plone nasceu com outras tentativas de aprender a usá-lo.

O Sistema

A idéia do sistema é permitir que a gente possa cadastrar os arquivos com as palestras e cursos ministrados por uma equipe e juntamente com esses arquivos manter informações relacionadas à essas palestras tais como: palestrantes/professores aptos, público-alvo, requisitos da sala de apresentação, etc.

Posteriormente o sistema também permitiria cadastrar datas de eventos, dados sobre as viagens dos palestrantes/professores e posterior mente fazer a solicitação de reembolso para as despesas destes.

O que foi feito

Apesar do sistema ter um escopo relativamente pequeno seria complicado conseguir terminá-lo em um único final de semana (mesmo prolongado) levando em conta que eu iria aprender e testar todos os frameworks que utilizaria. Então resumi o teste apenas ao cadastro de palestras. A parte estética do software também não seria importante mas uma avaliação sobre como usar as linguagens de template de cada framework fazia parte da experiência. Em alguns casos eu sequer terminei a implementação porque já tinha compreendido o funcionamento do framework e não havia mais a necessidade de finalizar o teste.

A seqüência que usei para os testes foi: Plone, TurboGears e Django.

O Plone

Depois que assisti à uma apresentação do meu amigo Xiru durante a I PyConBrasil fiquei muito tentado a experimentar o Plone com Archetypes e o ArchGenXML (criado pelo próprio Xiru). Achei que era um bom momento para brincar com isso e em 1 dia eu coloquei um Zope e um Plone pra funcionar em minha máquina. Demorei todo esse tempo porque fazia questão de ter as últimas versões estáveis dos dois programas e porque gostaria de fazer a instalação manualmente a partir dos fontes (isso não é necessário pois existem scripts automatizados para instalação disponíveis no site do Plone).

A instalação foi fácil, mas colocar ela pra funcionar demorou um tempão. Os problemas que enfrentei basicamente eram relacionados à versão do Zope que eu estava usando e a versão de um “produto” chamado Five que acompanha o Plone. Para resolver este problema simplesmente instalei outra versão de Zope e tudo começou a funcionar perfeitamente.

Conferi no catálogo de produtos do Plone (produto é o nome dado às extensões no universo Zope/Plone) para verificar se já não existia um produto que fazia algo semelhante ao que eu precisava e encontrei algumas coisas interessantes para testar. Nada do que eu testei fazia exatamente o que eu queria mas certamente seria muito mais negócio adaptá-los à inventar algo novo.

Mas a minha intenção era brincar com o ArchGenXML e então decidi reinventar a roda só para sentir o gostinho de usá-lo. Se no futuro eu fosse escolher o Plone eu partiria para reaproveitar esses produtos existentes e provavelmente jogaria o que eu tinha feito fora.

Segui passo-a-passo o tutorial do ArchGenXML e posso confirmar: funciona. Desenhei o esboço da minha aplicação no Poseidon UML Community Edition (recomendação do próprio Xiru), gerei o código, instalei e usei. Foi simples assim. O único contratempo que enfrentei foi o de ter de lembrar de reiniciar o Plone depois de ter instalado uma versão nova do meu novo produto criado.

Como eu já disse eu desenvolvi um preconceito muito grande com a dupla Zope/Plone (mais por causa do Zope) e obviamente isso fez com que esse sistema saísse atrás na corrida pela minha escolha. Mas ele me surpreendeu. Durante essa semana vou fazer umas perguntas para o pessoal do TcheZope e dependendo do que eu ouvir o Plone será escolhido para o desenvolvimento deste sistema. Ter os meus dados armazenados em um banco de dados não-relacional também me deixou muito satisfeito.

Fiquei tão surpreso com o resultado que cheguei a pensar em abortar os outros testes. Mas aí a minha grande preocupação nasceu: enquanto as coisas estão funcionando conforme nos manuais tudo é maravilhoso. Mas e o dia que elas não funcionarem de acordo? Por essa razão julguei ser o momento de passar para a próxima tentativa: “TurboGears”.

O TurboGears

Eu acredito que tenha sido o momento que eu escolhi para testar o TurboGears que tenha feito eu me decepcionar muito com ele. O projeto está numa fase muito “agitada” onde uma versão nova está saindo, um livro novo está saindo, a documentação está sendo toda refeita, a documentação antiga está sendo jogada fora, o site está em reformas, a lista de discussões está atendendo à tudo isso e mais o suporte ao desenvolvimento… é o caos. Organizado… mas caos.
O projeto está passando por uma fase onde duas coisas estão misturadas: estabilização da API e decisão dos próximos passos. A API está estável, mas duas decisões relacionadas aos próximos passos podem trazer mudanças enormes no projeto.

Uma das decisões do pessoal do TurboGears é a de trocar o ORM SQLObject pelo SQLAlchemy. Eu mexi com o SQLAlchemy e recomendo. O SQLAlchemy apresenta uma grande robustez (devido aos testes automatizados que ele tem), a forma com que o projeto foi feito o tornou muito mais extensível que o SQLObject e a documentação dele é uma obra de arte.

O TurboGears já diz ter um bom suporte ao SQLAlchemy mas não confie nisso ainda:

  1. O TurboGears usa um esquema de ActiveMapper do SQLAlchemy que foi criado pelos próprios desenvolvedores do TurboGears. O ActiveMapper permite fazer o ORM de uma maneira muito parecida com a do SQLObject mas ele ainda tem uma série de deficiências.
  2. O mecanismo de Identity do TurboGears é extremamente dependente do mecanismo de ORM. Se o SQLAlchemy não está 100% no TurboGears o sistema de Identity também não está.
  3. CatWalk, Toolbox, Designer, … e qualquer outra ferramenta do TurboGears que use o SQLObject não funciona com o SA ainda.

A outra mudança é relacionada à linguagem de template Genshi que entra no lugar da linguagem Kid que deixará de ser padrão no TurboGears. Essa mudança tem menos impacto porque será possível usar as duas linguagens e uma se parece muito com a outra.

Depois de muita cabeçada conclui que ainda não dá pra usar o SA e então reiniciei meus testes usando o SQLObject mesmo.

A sorte do TurboGears é que ele é muito leve, fácil e descomplicado porque se eu fosse depender de documentação eu estaria perdido. A documentação do TurboGears sofre do mal da desorganização. Não falta documentação, mas ela está toda desencontrada, desatualizada, descentralizada, mal indexada, etc. A menos que você tenha saco de ficar assistindo um filminho (screencast) de 10 minutos para cada coisa que você queira aprender a fazer no TurboGears você irá sofrer.

Usando o código fonte e alguns exemplos (“Use the source Luke!“) eu consegui fazer uma parte considerável do teste com o TurboGears. Tive que brigar um pouco com o SQLObject mas isso aconteceu graças à minha ojeriza a bancos de dados relacionais. Odeio ter que pensar em minhas classes correntamente e depois sair serrando, picando e estripando para que elas caibam em tabelas.

Dos frameworks testados esse foi o que mais caiu em meu conceito porque você tem que lutar o tempo todo contra a documentação (isso inclui a documentação dos módulos de terceiro) e contra a falta de aplicações mais completas que sirvam de exemplo para aprender TurboGears.

A dica pros TurboGear-zeiros brasileiros que contribuem com este projeto é: mais atenção na documentação!

Django

Esse era o framework que eu menos conhecia e aparentemente ele é o favorito do Guido van Rossum. Também foi a minha maior surpresa (positiva) porque comecei a desenvolver os testes nele e quando vi tive que dar uma “pisada no freio” porque já estava quase terminando a aplicação toda. Tá, é um exagero. Mas é tão agradável desenvolver com o Django que me senti da mesma forma de quando comecei a programar em Python: feliz.

O tutorial do Django aberto no browser, o editor aberto no terminal, e código foi tudo o que precisei para o teste. Fui dormir às 4 da madrugada com uma sensação agradável de quem tinha se divertido programando.

O Django usa um ORM dele que é menos poderoso que o SQLAlchemy, mas é muito mais gostoso de usar do que o SQLObject. Ele também disponibiliza um monte de “tipos de dados” muito úteis como o FileField que permite criar campos com upload de arquivos e já informar em que diretório esse arquivo será armazenado (enquanto que no BD fica apenas o path para esse arquivo). Isso também não muda o fato de que o famigerado “banco-de-dados-jurássional” está ali.

A linguagem de template do Django também é feita pra ele. Funciona no mesmo esquema do PHP onde você coloca código Python no meio de tags HTML. Eu acho mais agradável fazer templates assim porque sou programador. Mas devo admitir que você tem que desenhar o template às cegas, já que não é possível ver esses templates no browser enquanto estamos desenhando (isso é possível com o Kid, Genshi, ZPT, … que funcionam com o TurboGears).

O sistema de mapeamento de URLs do Django é muito chato de configurar mas em pouco tempo você percebe que ele é extremamente poderoso. No TurboGears é muito mais simples lidar com isso porque você não tem o conceito de mapeamento mas eu não sei se essa forma de trabalhar não apresenta limitações (não consigo imaginar nenhuma limitação, mas talvez elas existam).

Considerações Finais

Vocês devem estar se perguntando: “E então, qual você escolheu?”. Eu ainda não escolhi. Tudo indica que o Django leva a taça. Mas os outros possuem algumas coisas que podem reverter esse quadro:

  1. Plone – eu tenho amigos extremamente qualificados em Plone. Uma conversa de poucos minutos com eles pode eliminar uma série de dúvidas técnicas que tenho e ele seja escolhido por ser, entre os três, o que apresentou a maior facilidade de desenvolver todo o sistema.
  2. TurboGears – Ainda tem a minha simpatia por ‘caber na minha cabeça’. O fator eu-posso-ajudar-nesse-projeto também pesa a favor dele porque é como os mazoquistas dizem: “Os maiores desafios trazem as maiores recompensas.”
  3. Django – vou afundar mais a minha cabeça neste projeto para ver como ele funciona e ver se o coração dele condiz com a cara que ele me apresentou.

Nota do autor: Escrevi esse artigo às pressas e não pude revisar. Se encontrarem erros ou tiverem alguma idéia ou sugestão coloque no comentário. Pretendo com isso melhorar esse artigo para disponibilizar no PythonBrasil.

Publicado por

Osvaldo Santana

Desenvolvedor Python e Django, Empreendedor, dono de uma motocicleta esportiva, hobbysta de eletrônica, fã de automobilismo e corinthiano

  • Opa,

    To retribuindo a visita 😉

    Pelo que vi no seu artigo, vc conclui que usar o Django para sua palicação seria melhor, certo?

    E pra quem vai começar a encarar o python para web do início? Um abraço,

    Tiago

  • Opa,

    To retribuindo a visita 😉

    Pelo que vi no seu artigo, vc conclui que usar o Django para sua palicação seria melhor, certo?

    E pra quem vai começar a encarar o python para web do início? Um abraço,

    Tiago

  • Oi Tiago,

    É, eu realmente gostei muito da experiência com o Django. Mas também não posso afirmar que ele é a solução para todos os tipos de problema.

    Para começar a encarar Python para Web *hoje* eu recomendaria ele sim. Ele te desvia muito pouco do desenvolvimento da sua aplicação para ficar “cavocando” documentação.

  • Oi Tiago,

    É, eu realmente gostei muito da experiência com o Django. Mas também não posso afirmar que ele é a solução para todos os tipos de problema.

    Para começar a encarar Python para Web *hoje* eu recomendaria ele sim. Ele te desvia muito pouco do desenvolvimento da sua aplicação para ficar “cavocando” documentação.

  • Boas análises, Osvaldo. Um fator contra que vejo no Plone/Zope é porque antes de fazer algo em Plone que não seja básico, é preciso entender bem o Zope, pois esse parece ter uma forma própria de lidar com Python e não possui uma interface muito intuitiva.
    O Django é legal pois, como o próprio GvR disse, é um projeto opensource organizado. E para fazer coisas básicas com ele só precisa saber Python e ver a documentação bem rapidinho. 😉
    Ainda não testei o TG, mas pelo que os outros dizem, parece ser um projeto que vai de mal a pior.
    A

  • Boas análises, Osvaldo. Um fator contra que vejo no Plone/Zope é porque antes de fazer algo em Plone que não seja básico, é preciso entender bem o Zope, pois esse parece ter uma forma própria de lidar com Python e não possui uma interface muito intuitiva.
    O Django é legal pois, como o próprio GvR disse, é um projeto opensource organizado. E para fazer coisas básicas com ele só precisa saber Python e ver a documentação bem rapidinho. 😉
    Ainda não testei o TG, mas pelo que os outros dizem, parece ser um projeto que vai de mal a pior.
    A

  • Olá Osvaldo!

    Realmente, a documentação do turbogears é meio descentralizada, mas acredito que isto se deve ao fato do projeto tb ser, pois a idéia do desenvolvimento do turbogears e djando são diferentes, o Djando defende esta idéia de centralização tudo na mesma ferramenta, já o TurboGears nasceu de partes de outros produtos (Cherrypy, Sqlobject, etc…) Gosto do TG, e com certeza ele tem as suas desvantagens, mas achedito que, quando o Alchemy integrar totalemtne o TG vai ficar bem melhor de trabalhar!

    abraço!

    obs.: te adcionei no meu blog!

  • Oi Osvaldo,

    Gostei muito do texto, compartilho das mesmas opiniões e estou trabalhando com o Django em um projeto grande para a Universidade onde eu trabalho. É uma ótima alternativa, mas acho que qualquer um dos 3 seria bom, com prós e contras, entretanto, para essa aplicação que você pretende fazer eu acho que o mais indicado seja mesmo o Django ou o Turbogears, que alias, estão ficando cada vez mais parecidos.

  • Oi Osvaldo,

    Gostei muito do texto, compartilho das mesmas opiniões e estou trabalhando com o Django em um projeto grande para a Universidade onde eu trabalho. É uma ótima alternativa, mas acho que qualquer um dos 3 seria bom, com prós e contras, entretanto, para essa aplicação que você pretende fazer eu acho que o mais indicado seja mesmo o Django ou o Turbogears, que alias, estão ficando cada vez mais parecidos.

  • Osvaldo,
    Passado alguns meses qual a sua avaliação destes três frameworks ?

  • Osvaldo,
    Passado alguns meses qual a sua avaliação destes três frameworks ?

  • Então 🙂 Passados alguns meses eu conclui que não tive tempo de testá-los mais à fundo 🙂

    Mas ainda assim eu brinquei um pouco mais com o Django e pude perceber que ele, sem dúvidas, é mais coeso.

    Mas o Turbogears vai começar a trabalhar com o SQLAlchemy (já trabalha mas não é 100% suportado ainda) e isso sem sombra de dúvidas vai torná-lo muito melhor.

    O SQLAlchemy é o primeiro projeto de ORM que me convenceu desde que aprendi sobre esse conceito.

  • Então 🙂 Passados alguns meses eu conclui que não tive tempo de testá-los mais à fundo 🙂

    Mas ainda assim eu brinquei um pouco mais com o Django e pude perceber que ele, sem dúvidas, é mais coeso.

    Mas o Turbogears vai começar a trabalhar com o SQLAlchemy (já trabalha mas não é 100% suportado ainda) e isso sem sombra de dúvidas vai torná-lo muito melhor.

    O SQLAlchemy é o primeiro projeto de ORM que me convenceu desde que aprendi sobre esse conceito.

  • Pingback: Pythonologia - Python, open-source e desenvolvimento » Blog Archive » Web com Python. E agora?()

  • roberta

    Ola.. gostaria de saber informações de como utilizar o plone;?!
    valeu

  • roberta

    Ola.. gostaria de saber informações de como utilizar o plone;?!
    valeu

  • Estou começando a estudar e descidindo entre Djando e Turbogears. O que gostei no Turbogears, mas especificamente no Kid é que ele usa linguagem de marcação para os templates enquanto o django usa chaves e o codigo fica parecendo um espagueti do PHP!

  • Estou começando a estudar e descidindo entre Djando e Turbogears. O que gostei no Turbogears, mas especificamente no Kid é que ele usa linguagem de marcação para os templates enquanto o django usa chaves e o codigo fica parecendo um espagueti do PHP!