TurboGears 2: solução de problemas durante a instalação

Pediram-me para documentar a instalação do TurboGears 2. Vocês podem encontrar os passos para a instalação aqui.

O restante deste post é sobre como solucionar certos problemas. Então, se você seguiu a documentação oficial e não teve problemas não precisa mais ler este post.

É bom salientar que fiz a instalação no Ubuntu Linux.

Installing TurboGears 2 from Source

Nesse ponto, quando vocês forem instalar o tg2 com python setup.py develop, vocês não encontrarão o arquivo setup.py. Ocorre que agora o tg2 usa o paver como instalador. Ou seja, documentação desatualizada. Na raiz de tg2 execute sudo paver develop.

Pode ser que durante o download das dependências do tgdev, não seja encontrado a versão 0.8.7dev do ToscaWidgets. Se este for o caso, é melhor você esperar um tempo para eles disponibilizarem-na e então sincronize a cópia de trabalho com svn update. Depois, execute novamente sudo python setup.py develop.

Concluídas as demandas, você já pode brincar com o TurboGears 2. Comece pelo Wiki em 20 minutos.

Estou querendo instalar o TG2 no Windows, então os problemas que possa encontrar vou colocar como comentário aqui.

Primeiro contato com TurboGears 2

Como o Twitter não está muito bem, vai ser por aqui mesmo que informo aos amigos e colegas pythonistas que tive pela primeira vez contato com o TurboGears 2 hoje. Acabei de fazer o exemplo da Wiki.

Aos poucos, devo começar a me aprofundar no uso dele, uma vez que estamos pensando em adotar o framework para o desenvolvimento de um projeto. Queremos que nossa aplicação acompanhe o desenvolvimento do TurboGears, mesmo que isso seja arriscado.

Tive um razoável trabalho para instalá-lo na minha máquina. O trabalho não se deveu ao fato de tê-lo de obter via Subversion, mas sim porque alguns pacotes não estavam sendo encontrados pelo easy_install. Também precisei usar o Paver para baixar umas dependências. Isso a documentação de instalação não explicou. Devo fazer a instalação também no notebook do Stênio. Não anotei nada, espero conseguir.

Apesar dele manter a API bastante semelhante ao TurboGears 1, há componentes novos. A curiosidade foi aguçada por conta disso. Estava tão por fora, que somente agora fiquei sabendo sobre o Paver, criado pelo próprio Kevin Dangoor. Parece-me um melhoramento sobre o processo de instalação/distribuição/empacotamento.

Deixemos para outros posts demais conclusões sobre o TG2.

TurboGears: a espera

Devido a existência do projeto de desenvolvimento do Turbogears 2, decidi fazer uma pausa nos estudos e casos de uso sobre esta framework. O Turbogears 2 é um reprojeto visando adotar o WSGI como base para a componentização e reusabilidade na arquitetura.

WSGI é um padrão já adotado largamente na comunidade Python. Ele facilita bastante o reuso de código em aplicações web, principalmente. A equipe de desenvolvimento resolveu adotar o núcleo do Pylons 1.0 para pular etapas, uma vez que este já adotava o WSGI, inclusive adotava o Paste para facilitar a configuração. Vale ressaltar que eu fico maravilhado com a tríplice setuptools + wsgi + paste.

Essa mudança é um ponto positivo mas que me levou a parar um tempo de escrever sobre a framework aqui no blog. A sensação é que ela está no limbo e o Django continua ganhando novos adeptos. Verdade que este limbo é bem produtivo e tenho a sensação de um retorno ao mercado ainda este ano.

Então, quando tivermos lançamentos oficiais e documentação sobre o Turbogears 2, estarei novamente estudando e escrevendo aplicações de exemplo e divulgando minhas experiências por aqui.

Um pouco do meu tempo para todo mundo.

Powered by ScribeFire.

O tempo e outras coisas

Ultimamente voltei a ficar ocupado mais que o normal. Envolvido num projeto à tarde, não posso usar um tempo maior para meus projetos em Python e Rails, o que pode me levar a escrever menos aqui. Possivelmente com menos qualidade.

Não sei se cheguei a comentar em algum post, mas há algum tempo estou desenvolvendo novamente em Java. Estamos usando Struts 2, Spring e a boa IDE Eclipse. Tá bacana, mas sinceramente, quando você conhece outras coisas, tais como um framework TurboGears ou Rails, sente a diferença de produtividade. É chato envolver-se em projetos onde a produtividade é baixa.

O framework Struts 2 é notadamente mais produtivo que o seu antecessor. Usa a filosofia “Convenção sobre Configuração”, amplamente conhecida na comunidade Ruby, agora espalhando-se por outros “mundos”. Entretanto, sua documentação ainda é pobre, algumas coisas não funcionam como o esperado. Não seria necessário descrever um problema que estou tendo aqui, mas como estou preso nele, não há jeito. No Struts 2, para validar campos de formulários, basta que criemos um arquivo com o nome convencionado NomeAction-validation.xml. Isso é bacana quando há somente uma ação a ser executada por Action. Não é o meu caso. Meus actions possuem vários métodos. Nem todos os métodos são posteriores ao envio de campos de formulário, além de métodos que recebem formulários diferentes.

Segundo a documentação, você pode usar o padrão NomeAction-alias-validation.xml para mapear o arquivo de validação a um “action name”, digamos UsuarioAction-salvar-validation.xml. Porém, isso não está funcionando. O que me faz perder tempo, ou seguir adiante até que encontremos como fazer isso prestar.

As reclamações sobre Java são muitas. É bastante difícil defender essa linguagem. Como argumentar com um desenvolvedor Delphi que eu não consigo implementar rapidamente um funcionalidade que ele é capaz de concluir em poucas horas? É mais fácil esconder isso num ambiente onde só exista Java. Não é o meu caso. Convivemos com aplicações em PHP, Delphi, VB, ASP, etc. Entre fazer algo urgente em Java ou Delphi, estão escolhendo o último. Porém, há mais programadores livres em Java. Os outros estão envolvidos com o legado.

Depois de alguns anos desenvolvendo profissionalmente em Java, aprendi que para ser mais produtivo, devemos procurar sempre o melhor modelo arquitetural, depois manter-se nele. No começo, nosso modelo é sempre desorganizado e improdutivo. Mesmo que usemos padrões de projeto e de arquitetura reconhecidíssimos, trabalhamos ele incorretamente. Muitas vezes usamos padrões desnecessariamente.

Antigamente, ao implementar o modelo de camadas em Struts, como Action -> BO -> DAO, a camada de regra de negócio (BO) e os DAOS possuiam interfaces. Mesmo sabendo que isso não seria preciso, colocávamos porque fazia parte do jeito do javista programar. Aumentávamos gratuitamente o número de coisas a fazer. Hoje, quando sabemos que não vamos largar uma tecnologia, ignoramo o uso de interfaces. Se algum dia (improvável) precisar delas, eu refatoro. O Eclipse esta aí para isso.

Estou aprendendo a trabalhar simples, como os antigos programadores faziam e uma nova safra de programadores estão fazendo. Estou saindo da educação javista. Aprendo muito com outras comunidades: desenvolvedores do mundo Linux, Ruby e Python me ajudaram a ser um programador um pouco melhor. Claro que Java trouxe para mim vários ensinamentos utéis que vou levar comigo.

Espero que os defensores ferrenhos de uma linguagem, qualquer que seja, não fiquem restritos somente a uma linguagem. Uma linguagem não serve perfeitamente para tudo. Ñão perca tempo em teimosia. Podemos usar várias linguagens dentro de nossas empresas e órgãos.

Carpem Diem!

Usando ToscaWidgets

Já comecei a usar os widgets no projeto Ferlons por meio da distribuição twAjaxTools que está sendo desenvolvida pelo pessoal do TurboGears. Eles implementaram basicamente os mesmos widgets do TG, no entanto implementados sobre o framework ToscaWidgets. Essa distribuição, twAjaxTools, como o próprio nome explicita, possui componentes Ajax, mas nem sequer dei uma olhada. Eu queria, na verdade uma das dependências dessa distribuição que é twForms.

Tá faltando agora ver como fazer as validações (acho que só resta mostrar as mensagens) e como usar o pacote elementtree para criar meus hiperlinks para os datagrids que não funciona como eu esperava.

O link para o projeto do Ferlons.

Powered by ScribeFire.

Widgets do TurboGears fazem falta no Pylons

TurboGears até o momento é o framework em Python mais produtivo com que trabalhei. Isso devido, em minha opinião, a duas coisas: à simplicidade do SQLObject e aos Widgets.

Graças a estes dois componentes, eu consegui implementar o TGBolão em poucos dias. Não vou negar que a reduzida quantidade de formulários ajudou no tempo de conclusão do mesmo. O ganho veio mesmo no momento de gerar as listas nas páginas. Listas de grupos, de seleções, participantes do bolão, apostas, etc. O objeto DataGrid é sensacional. O módulo elementtree era muito útil na hora de colocar hiperlinks e imagens nas linhas do datagrid. Muito fácil.

Eu tento evitar a todo custo fazer os formulários “no braço”. Com o objeto TableForm não tive muitos problemas para criá-los. Junte-se a isso a biblioteca FormEncode e você tem a validação dos campos também.

Pensando nessa produtividade, vou ler sobre o ToscaWidgets antes de tentar usá-lo no Ferlons (minha aplicação para testar o potencial do Pylons). Quero senti a produtividade dele em relação aos Widgets do TurboGears. Até o momento só usei FormEncode.

Não posso esquecer que um ORM ajuda nas consultas que envolvem relacionamento de tabelas/objetos. As regras de negócios ficam mais intuitivas quando vamos implementá-las.

Os comentários que fiz sobre os Widgets e SQLObject foram compreendidos na prática. Muitas vezes ficamos na defensiva quando se trata de coisas desconhecidas, de coisas que somente uma minoria está usando. Sabendo disso, tente, teste e comente com a gente.

Powered by ScribeFire.

Notícias recentes sobre o TurboGears

O Planet TurboGears é pouco movimentado mas hoje apareceram dois posts importantes, pois tratam do futuro do framework. O primeiro que li foi o post do Mark Ramm, resumindo os acontecimentos e decisões tomadas num sprint recente.

Logo de cara fiquei surpreso com uma experiência que fizeram. Um projeto de integração do TurboGears com o Pylons. Pelo visto, foi um sucesso. Tem todo o jeito de ser a infraestrutura para a versão 2 do framework. O objetivo do experimento foi encontrar uma maneira do framework ser mais flexível e fácil de manter. Nada mais justo. Dangoor diria também, enxuto.

O TurboGears 1.1 será lançado em poucas semanas. O motor de template será o Genshi e o ORM por sua vez será o SQLAlchemy. Eu já testei o Genshi e ele ganha de imediato nas mensagens de erro mais legíveis. O SQLAlchemy, como muitos sabem, é robusto (mas o SQLObject é mais simples e fácil de aprender) e torna-se a escolha certa. Parece que pode haver ainda uma versão 1.2 só para suportar o CherryPy 3.

Mark Ramm ainda informa que a versão 2 do citado framework ganhará novos recursos como caching e outras formas de melhorar o desempenho. O Routes estará integrado ao TurboGears, o que trará certamente URLs mais flexíveis.

O post de Kevin Dangoor comenta o sprint do último final de semana em que eles trabalharam com código especificadamente para o TurboGears 2. Diz tratar-se de uma volta às raízes porque seu objetivo é fazer do TG um framework com um pequena quantidade de código, basicamente para orquestrar diversas bibliotecas. Assim era na versão 0.5.

O criador do framework ainda diz estar entusiamado com a atividade e espera ter alguma coisa pronta em algumas meses.

Consegue-se perceber que a comunidade de desenvolvedores do TurboGears ainda é uma das mais ativas. Já o framework Pylons, chama atenção porque ela foi criada como um estudo de caso para Paste, Setuptools e WSGI. Estes três nomes estão melhorando as ferramentas e o jeito de desenvolver para web.

Powered by ScribeFire.

SQLAlchemy no TurboGears

Depois de tempos postando sobre política posso dizer que estou voltando a ativa novamente. Neste post trataremos de um assunto que nunca mais havia tocado: TurboGears.

A minha framework web favorita escrita em Python está na versão 1.0.2.2 e correndo para a versão 1.1, principalmente depois de um sprint que ocorreu recentemente. Os desenvolvedores substituirão o sistema de templates Kid pelo Genshi e o SQLObject pelo SQLAlchemy. O que posso dizer é que podemos usar o SQLAlchemy atualmente sem muitos problemas. Constatei isso implementando um exemplo bem conhecido em Ruby on Rails: um livro de receitas eletrônico (cookbook em inglês).

Vamos mostrar algum código, uma vez que isso é mais divertido. Precisamos do TurboGears e do SQLAlchemy:

easy_install -U TurboGears
easy_install SQLAlchemy

Antes de criarmos uma infraestrutura para o projeto, gostaria que vocês conseguissem o servidor de banco de dados MySQL. Vamos fazer o nosso exemplo de acordo com o do Rails. Se vocês quisserem fazer o mesmo exemplo em Rails sugiro lerem alguns posts do blog do Brasília on Rails. Vamos criar nosso banco de dados com o seguinte comando num terminal bash do Linux:

$ mysql -u root -p
> create database cookbook;
> grant all on cookbook.* to 'usuario@localhost';

O esquema do banco é o seguinte:

drop table if exists recipes;
drop table if exists categories;
create table categories ( id  int  not null auto_increment,
    name varchar(100)   not null default '',
    primary key(id)
) engine=InnoDB;

create table recipes ( id int  not null auto_increment,
     category_id int not null,
     title varchar(100)   not null default '',
     description varchar(255)   null,
     date  date null,
     instructions text  null,
     constraint fk_recipes_categories foreign key (category_id) references categories(id),
     primary key(id)
) engine=InnoDB;

Colem este esquema num arquivo (digamos, create.sql) e executem:

mysql cookbook < db create.sql

Feito isso, vamos ao TurboGears:

tg-admin quickstart --sqlalchemy

Chamarei o projeto de cookbook. Selecionem ‘não‘ quando perguntado se querem usar o Identity.

Dentro da pasta do projeto há o arquivo dev.cfg para as configurações no ambiente de desenvolvimento. Lá informaremos à aplicação a string de conexão:

sqlalchemy.dburi="mysql://root:oinc@localhost/cookbook"

Executemos o script start-cookbook.py para rodar o servidor. Depois acesse o endereço http://localhost:8080/ para testar a aplicação.

python start-cookbook.py

Depois disso, vamos no arquivo cookbook/model.py para mapear para objetos o nosso banco com SQLALchemy:

from sqlalchemy import *
from turbogears.database import metadata, session, bind_meta_data
#from sqlalchemy.ext.assignmapper import assign_mapper

bind_meta_data()

categoria_tabela = Table('categories',metadata,autoload=True)

receita_tabela = Table('recipes',metadata,autoload=True)

class Categoria(object):
    def __init__(self,name):
        self.name = name
    def __repr__(self):
        return self.name

class Receita(object):
    def __init__(self,title):
        self.title = title
    def __repr__(self):
        return self.title
    def nome_categoria(self):
        return self.categoria.name

mapper(Categoria, categoria_tabela, properties={'receitas' : relation(Receita,backref='categoria')})
mapper(Receita, receita_tabela)

Para o post não ficar muito grande, faremos somente uma página que lista todas as receitas. Eu não cheguei a implementar todo o exemplo do Cookbook, no entanto é muito mais do que mostrarei para vocês daqui pra frente. Como não tenho nenhum local na internet para disponibilizar este exemplo, vocês terão de informar e-mail para que eu envie-os.

Copiem o template welcome.kid e criem o arquivo receita_list.kid. Retirem o corpo da página e coloquem somente o seguinte:

${grid.display(receitas)}

Editem o arquivo cookbook/controllers.py. Escreveremos um método que acesse o banco de dados para pegar todas as receitas e passe essa lista para o template que criamos.

@expose(template="cookbook.templates.receita_list")
def receitas(self):
    receitas = session.query(Receita).select()
    grid = DataGrid(fields=[('Nome','title'), ('Categoria',Receita.nome_categoria)])
    return dict(receitas = receitas, grid = grid)

Para que esse método funcione, temos de importar model.py e widgets.DataGrid.

from model import *
from turbogears.widgets import DataGrid

A primeira linha do método utiliza o objeto session para fazer uma consulta no banco na tabela recipes (mapeada pela classe Receita). Na segunda linha, instanciamos o DataGrid que será usado para gerar a tabela de resultados. Por fim, a última declara os objetos que serão usados em nosso template.

Acessemos a URL http://localhost:8080/receitas. Espero que tenha funcionado! 😉 Problemas e dúvidas, por favor, comentem.

Atualização: Baixem a aplicação. Oferecimento: Walter Cruz 😉

TurboGears 1.0

Lançado no dia 3 de Janeiro de 2007, o TurboGears tem sua primeira versão estável. Observando a documentação do framework, notei que ainda falta material sobre Widgets. Pena, por que é umas das partes que acho interessante no TurboGears, uma vez que alia geração de formulários à sua validação, ponto crucial para mim quando se trata de desenvolvimento de aplicações web sem muito sofrimento. A verdade é que validar formulários é uma das coisas que mais detesto programar.