Desenvolvimento de portlets com Rails 2
No final do ano passado fechamos um contrato com o Conselho Federal de Administração (CFA) para o desenvolvimento do cadastro integrado de administradores do Brasil dentre outras funcionalidades. Além da implementação, o CFA também tinha a necessidade de uma ferramenta capaz de prover recursos de CMS, comunidades, fóruns, etc. Tendo em vista esse cenário ficou decidido que o Liferay iria ser a ferramenta de portal utilizada enquanto o desenvolvimento dos portlets seria feito em Ruby/Rails.
Como seria possível desenvolver um portlet Ruby em uma plataforma Java? o.O? Utilizando JRuby é claro! Dentre os projetos que viabilizavam uso do Ruby/Rails em portlets java, o rails-portlet foi o que apresentou a melhor proposta. E como ele funciona?
- 1 portlet java
- O projeto feito com o Rails empacotado com a gem warble, rodando com o JRuby
- Comunicação HTTP entre o portlet e o projeto Rails
- Rails inacessível sem o portlet
O portlet java, que é provido pelo projeto rails-portlet, é adicionado ao portlet container e irá conversar com a aplicação feita em Ruby, isso facilita muito o trabalho, pois conseguimos desenvolver tudo em Ruby e com alguns comandos geramos o .war do portlet.
O projeto feito com o Rails tem algumas particularidades, a mais proeminente é o mapeamento das rotas, pois no projeto original cada método de controller gerava um novo portlet, um mapeamento fixo, por exemplo:
map.portlet_exemplo(
‘portlet_exemplo’, :controller => :controller_1, :action => :method_1
)
Com as contribuições que nossa equipe fez ao projeto, nós conseguimos criar rotas que abrangem N controllers, o que melhorou bastante o processo de reaproveitamento de código, exemplo:
map.portlet_exemplo(
‘portlet_exemplo/:controller/:action’, :controller => :controller_1
)
Nessa caso, utilizamos um namespace ‘portlet_exemplo’ para definir o portlet e definimos que o controller padrão será o :controller_1 e o método padrão será o :index, que no caso, não precisa ser informado. Os wildcards :controller e :action serão substituídos pelos valores passados por parâmetro na URL, por exemplo:
http://…/portlet_exemplo
controller_1, método index
http://…/portlet_exemplo/meu_controller
meu_controller, método index
http://…/portlet_exemplo/outro_controller/outro_metodo
outro_controller, método outro_metodo
Outra necessidade é a utilização da gem caterpillar que é a responsável por gerar automaticamente os xmls de configuração do portlet e do liferay, além de empacotar utilizando o warbler e realizar o deploy. Essa gem tem como dependência a gem lportal, que contém as tabelas do liferay na forma de modelos do ActiveRecord. Infelizmente o lportal não atendeu as nossas necessidades pois ele apresentou algumas problemas básicos, talvez por inatividade do projeto. Dessa forma nós criamos o projeto liferay_models, que ainda não está público, e que é assunto para um outro post.
Após o panorama geral, vejamos como criar um portlet em Rails.
1) Instalar e configurar o GEM
criar variável de ambiente $GEM_HOME=/caminho/das/gems/sem/a/pasta/gems
* Atenção: O caminho das gems não inclui a pasta gems.
Por exemplo:
export GEM_HOME=/usr/lib/ruby/gems/1.8
1) Instalar e configurar o JRuby
download
http://jruby.kenai.com/downloads/1.4.0/jruby-bin-1.4.0.zip
criar variável $JRUBY_HOME=/… e adicionar no path $JRUBY_HOME:$JRUBY_HOME/bin
1.5)
apt-get install ruby-dev
Ubuntu:
apt-get install libpqxx3-dev
Debian:
apt-get install libpq-dev libpgsql-ruby
2) Instalar gems
gem install jruby-openssl
gem install jruby-jars
gem install hpricot
gem install warbler
gem install caterpillar
gem install lportal
gem install uuidtools
gem install rails -v=2.3.3 (Até o momento o caterpillar só funciona com essa versão do rails, estamos trabalhando nisso)
* no caso de utilizar postgres
gem install pg
gem install activerecord-jdbcpostgresql-adapter
3) Criar projeto
rails nome-projeto
cd nome-projeto
ruby script/generate controller example index
- Configure a rota
map.example(‘example/index’, {:controller => ‘example’, :action => ‘index’})
- Adicionar as dependências das gems no config/environment.rb
config.gem "caterpillar"
config.gem "lportal"
- Configurar config/database.yml
development:
adapter: postgresql
database: lportal
username: postgres
password: postgres
host: 127.0.0.1
timeout: 5000
production:
adapter: jdbcpostgresql
database: lportal
username: postgres
password: postgres
host: 127.0.0.1
encoding: unicode
- Ativar caterpillar
ruby script/generate caterpillar
- No arquivo config/portlets.rb adicione
portlet.container.root = ‘/../Programas/liferay-portal-5.2.3/tomcat-6.0.18/’
portlet.category = ‘Rails-apps’ (ou um nome que você preferir)
- Deploy
* Teste a conexao com:
caterpillar portlets
- Gerar o arquivo warble.rb
warble config
- Adicionar essa configuração no warble.rb
config.gems << "activerecord-jdbcpostgresql-adapter"
config.gems << "lportal"
# Precisa fazer apenas uma vez
caterpillar jar:install (Coloca o portlet genérico que trata as requisições no liferay)
# Sempre que mudar alguma configuracao e for testar a aplicação no liferay
caterpillar xml
caterpillar warble (nesse momento não pode ter nenhuma gem nativa no environment.rb, exemplo pg)
# Utilizado para atualizar os arquivos no container
caterpillar deploy:xml
caterpillar deploy:war
Após realizar os passos acima, inicie o Liferay e acesse a aplicação. Selecione o portlet rails que se encontra na categoria que foi configurada. Pronto, nós temos nosso portlet rails rodando!
Esse foi o primeiro de uma série de posts sobre o assunto. Fiquem no aguardo.
Equipe CFA:
Túlio Ornelas, Pedro Dias, Bruce Rodrigues e Renan Mendes.
Gostei do post e principalmente da aposta na integração dessas tecnologias. Parabéns pela iniciativa. Estarei aguardando os outros posts da série.
Desde 2008, a Sun mudou sua estratégia de venda da tecnologia Java. De lá pra cá, o discurso é em prol do Java como plataforma, e não como yet another programming language.
Servidores de aplicação começaram a seguir a mesma linha, deixando de ser apenas servidores de aplicação Java, para se tornar servidores de aplicação para qualquer linguagem (e.g. Glassfish e JBoss que já suportam componentes em outras linguagens além do Java)
Agora, chega a vez das ferramentas de portais, antes exclusivas ao desenvolvimento de portlets Java e, agora, genéricas para a extensão com outras linguagens (no caso do Liferay, já há o suporte a Ruby e PHP).
Seria bom a comunidade desenvolvedora se ligar para o fim da era da monogamia tecnológica. IMO, o futuro é pluritecnológico. Aliás, já leu o Manifesto 2.0? http://tinyurl.com/manifesto20
[]s