Como aconteceu com o caso das rotas, aprender a usar helpers é uma das coisas mais satisfatórias em Rails. Digo isso como iniciante, pois isso já deve ser uma coisa totalmente trivial para os mais experientes.

No meu caso, tenho um form com uma lista de checkboxes, que podem variar em número de acordo com o conteúdo de uma tabela. Ou seja, se na tabela tiver 5 itens, terei 5 checkboxes. Se eu apagar um item, quando recarregar a página, serão mostrados 4 checkboxes.

Veja abaixo como eu resolvi o problema com um helper.

Um dos pilares filosóficos do Rails (bonito isso, hein?), é o conceito DRY, ou seja Don’t Repeat Yourself. Uma das explicações mais legais sobre isso, você pode conferir nesse post aqui.

Uma das passagens que mais me chamou a atenção foi essa aqui:

“Don’t repeat yourself” não é somente sobre duplicar trechos de código, também tem muito a ver com o comportamento funcional do seu código.

Os helpers foram criados justamente pensando em uma programa DRY, ou seja, sem repetição de código, conceito ou funcionalidade.

Mas descobri que eles podem ser muito úteis também para geração dinâmica de forms.

Na estrutura de diretórios do Rails, em ../app/helpers, você encontrará helpers específicos para controller da sua aplicação. Se você criar um helper dentro de <seu_controler>Helper.rb, esse helper estará disponível somente para aquele controller <seu_controler> especificado.

Agora, se você colocar seu helper no application_helper.rb, seu helper estará disponível para todos helpers.

Para o caso dos múltiplos checkboxes, veja o helper show_connections_types:

module ConnectionRequestsHelper
def show_connections_types
output = ''
conn_types = ConnectionType.find(:all, :conditions => ['archive <> ?', true])
 
group = 1
 
conn_types.each do |conn|
output << '
<input name="conn' + group.to_s + '" type="checkbox" />' + conn.name + '
'
group = group + 1
end
 
return output
end
end

O que esse helper faz? Ele recupera todos os itens da tabela connection_types e gera o código HTML do form, usando cada um dos itens da minha tabela.

O resultado HTML final será assim:

<input name="conn1" type="checkbox" />Trabalhamos juntos no mesmo projeto.
<input name="conn2" type="checkbox" />Foi meu instrutor(a).
<input name="conn3" type="checkbox" />Fui seu instrutor(a).
<input name="conn4" type="checkbox" />Foi meu colega de classe.
<input name="conn5" type="checkbox" />Conheci em um evento.
<input name="conn6" type="checkbox" />Li uma publicação dele(a), como livro, artigo ou blog.

Na minha view, quando eu quizer usar o helper, apenas uso a seguinte linha:

Conclusão

Os helpers são peças fundamentais em Rails. Aprender a usá-los dará a você muita munição para solução dos problemas nas views.

Em um próximo post, vou mostrar como os helpers estão me ajudando a ser DRY em minhas views.

Quando você tem o primeiro contato com o Rails, você fica logo apaixonado pela facilidade, seja pelo scaffold, seja pelo “covention over configuration” ou pelo migrations.

Mas uma coisa que escapa a nossa atenção é o uso das rotas. Eu tenho aprendido muito estudado o funcionamento das rotas e tenho encontrado muitas soluções algúns problemas chatos de se resolver.

Essa semana mesmo, tive um problema que resolvi criando uma nova rota.

Imagine que você precise criar um novo item qualquer do modelo, mas esse item precisa já ser criado associado a outro item. Resolvi isso fazendo uma nova rota para o controller em questão:

1

map.new_request 'connection_requests/new/:id', :controller => 'connection_requests', :action => 'new'

Com isso, estou dizendo ao Rails que quando o link “…/new_request/new/1″ for chamado, o controller connections_request, ação new, passando o parâmetro 1.

Aí no controller, eu trato o parameter da seguinte forma:

1

@connection_request.connect_to = params[:id]

O parâmetro id do link é passado via params[:id]. No meu caso, joguei esse valor em um atributo do meu modelo, que usarei no momento de salvar o item. Onde eu farei a associação requerida.

A intensão aqui é apenas mostrar que as rotas devem ser estudadas e levadas em consideração na hora de resolver problemas.

No meu novo projeto Rails eu estou usando o plugin file_column para tratar o upload de arquivos. No entanto, se você usar a versão original do autor que está no repositório SVN, você terá o seguinte erro usando Rails 2.1 ou mais recente:

uninitialized constant FileColumn::ClassMethods::Inflector

Se você instalar o usando o comando abaixo, você baixará a versão do SVN:

./script/plugin install http://opensvn.csie.org/rails_file_column/plugins/file_column/trunk

Essa versão usa um comando Inflector que foi removido na versão 2.1 do Rails. Devemos usar ActiveSupport::Inflector.

Para isso, você deve corrigir a seguinte linha no arquivo vendor/plugins/file_column/lib/file_column.rb:

my_options = FileColumn::init_options(options, Inflector.underscore(self.name).to_s, attr.to_s)

Corrigir para:

my_options = FileColumn::init_options(options, ActiveSupport::Inflector.underscore(self.name).to_s, attr.to_s)

Claro que por se tratar de um plugin open source, quando você acha um bug você pode agir de 3 maneiras diferentes:

• Sentar e esperar a correção;
• Reclamar que open source não presta porque não tem suporte blá blá blá…
• Corrigir o problema e submeter a correção para o autor

Então, após eu ter resolvido o problema tente submeter a correção, mas descobri que o autor não mexe no plugin há muito tempo. Também descobri que já criaram um mirror do projeto no Github, já com a devida correção.

Então, é melhor instalar o plugin diretamente do GitHub:

./script/plugin install git://github.com/tekin/file_column.git

No ano passado, eu trabalhei em um projeto Rails para o site da igreja que frequento (IPI). O site não exigiu muitas funcionalidades esdruxulas, então o desenvolvi com certa velocidade.

Contando a minha experiência em Rails, creio que o mesmo site estaria pronto em uma ou duas semanas, trabalhando nas minhas horas de folgas. Pra falar a verdade a parte de layout foi a que mais me deu trabalho.

Outra coisa que dá um pouco de trabalho é o deploy das alterações que faço localmente. No SAP, temos um sistema de transportes e change requests que torna o deploy uma coisa de criança.

Pensando nisso é que nasceu o Reploy, um script para deploy escrito em Ruby.

É um script extremamente simples, que gera um arquivo .tar com o delta das alterações entre o último commit deployed e último commit no desenvolvimento. A idéia não é ser um sistema tão complexo como o do SAP ou Capistrano.

O fluxo de trabalho típico seria assim:

Passo 1: No seu computador local, após o commit (no Git, claro), você executa o script ruby repack.rb. Esse script é responsável por empacotar todos os arquivos do último commit (que ficou registrado no arquivo .last_repack) até o último commit feito.

Passo 2: Faz o upload do arquivo para o servidor destino.

Passo 3: Via SSH executar o script ruby reploy.rb. Esse script é responsável por mover as novas versões dos arquivos, copiar os novos e remover os arquivos que não fazem parte mais do projeto.

Após o passo 3, teríamos toda a estrutura do projeto no servidor de deploy sincronizada com o sua estrutura de desenvolvimento.

Esse script foi feito para atender as minhas necessidades, mas ainda faltam alguma coisas que gostaria:

• Upload automático
• Mecanismo de Rollback
• Interface gráfica

Por isso é um projeto Open Source, quem quizer pode contribuir. Ele está hospedado no GitHub e é muito fácil para quem quizer baixar o código e submeter melhorias.

Nos próximos posts, vou explicar melhor como ele funciona, gems que você precisa instalar etc.

Depois de muito refletir, pensar e ponderar, resolvi dar novos rumos para o ABAP 101. Ou seja, não vou mais falar somente de ABAP e SAP aqui, mas sobre tudas as tecnologias que estou trabalhando no momento.

Isso inclui o meu dia a dia com SAP e ABAP, mas também meus projetos e aventuras por outros mundos, como Rails e Cocoa.

Em resumo posso dizer que para ABAP continuo postando dicas, técnicas de programação e minhas impressões do mercado. Para todas as outras eu vou postar meus “feitos”, dificuldades e qualquer outra informação interessante.

Por quê não criar mais um blog? Porque quero mostrar que existe vida além do ABAP (essa foi para os macacos véios que acham que ABAP é tudo nessa vida).

O ano de 2008, como já disse, não fiquei parado e descobri muita coisa interessante em outros mundos, principalmente em Rails e XI. Percebi como ficar fechado no mundo ABAP pode prejudicar a nossa carreira!

Então, em 2009 o volume de posts de ABAP continua o mesmo, mas teremos algúns intrusos de outras vizinhanças. Não se preocupe, eles não mordem!