Blog do Hollander :: RoR de leigo para leigos

4 maio, 2008

Plugin Brazilian Rails

Filed under: Ruby / Rails — Tags:, , , — hollanderramos @ 12:06

Neste post eu comentei que era mais fácil trabalhar com Rails utilizando a convenção em inglês. Nas andanças da net, achei este plugin que – entre outras coisas – traduz a pluralização do Rails para o português.

Tentei instalá-lo no RADRails, mas obtive falha. Creio que se meu ambiente de desenvolvimento não fosse Windows seria mais fácil. Como necessito trabalhar com este ambiente, minha solução foi ir para o Console e tentar instalar o plugin via prompt. Ocorre que não está muito claro como se faz isso.

No site existe dois exemplos:
O primeiro é para instalação em Rails 2.1 (ainda não lançado – enquanto escrevo este post).
ruby script/plugin install git://github.com/tapajos/brazilian-rails.git

O segundo é para instalação em versões anteriores:
ruby script/plugin install svn://rubyforge.org/var/svn/brazilian-rails

Ambos comandos acima não funcionaram em Windows. Mas consegui a dica correta. No console, vá até o diretório do projeto criado e digite:
ruby script/plugin install http://brazilian-rails.rubyforge.org/svn/

Outra dica importante que não está clara: Para utilizar o plugin, abra o arquivo enviroment.rb que está no subdiretório config da aplicação, e acrescente o comando require ‘inflector_portuguese’ após o bloco Rails::initializer.run END. O código ficará parecido com este:

# Be sure to restart your server when you modify this file
(...)
# Specifies gem version of Rails to use when vendor/rails is not present
RAILS_GEM_VERSION = '2.0.2' unless defined? RAILS_GEM_VERSION
# Bootstrap the Rails environment, frameworks, and default configuration
require File.join(File.dirname(__FILE__), 'boot')

Rails::Initializer.run do |config|
# Settings in config/environments/* take precedence over those specified here.
# Application configuration should go into files in config/initializers
(...)
config.action_controller.session = {
:session_key => '_App_session',
:secret => '88bc...c62e'
}
# Use the database for sessions instead of the cookie-based default,
(...)
# config.active_record.default_timezone = :utc
end
require 'inflector_portuguese'

Salve o arquivo. Agora, você já pode criar classes com pluralização em português.

Em futuros artigos, tentarei explorar as outras funcionalidades do Brazilian-Rails.

24 abril, 2008

Programar em inglês ou desativar a pluralização?

Filed under: Ruby / Rails — Tags:, , — hollanderramos @ 21:35

Em um outro post eu comentei sobre como conhecer bem as convenções do Rails. Bem, este post irá aprofundar um pouco mais no assunto ao abordar as pluralizações.

Pluralização é uma das convenções do Rails para quando você cria por exemplo, um modelo. Por “padrão”, o Rails se encarregará de criar toda a estrutura necessária ao modelo, então o modelo deve ser um nome no singular, a tabela criada estará no plural, o modelo estará no singular, mas com a primeira letra capitalizada (maiúscula), etc.

Esta convenção é de fato uma mão na roda, porém ela só é efetiva quando desenvolvemos usando o inglês. Quando aplicado a gramática portuguesa, ela se torna um problema já que Rails não tem suporte a outras línguas.

A tabela abaixo demonstra a pluralização do modelo carro para todos os métodos gerados pelo Rails:

Método  	Resultado
camelize 	Carro
classify 	Carro
demodulize 	carro
foreign_key 	carro_id
humanize 	Carro
pluralize 	carros
singularize 	carro
tableize 	carros
titleize 	Carro
underscore 	carro

Tudo lindo correto? Errado. Vamos pluralizar agora o modelo injeção:

A primeira coisa é eliminar o cedilha e acentuações o que resulta em injecao:

Método  	Resultado
camelize 	Injecao
classify 	Injecao
demodulize 	injecao
foreign_key 	injecao_id
humanize 	Injecao
pluralize 	injecaos
singularize 	injecao
tableize 	injecaos
titleize 	Injecao
underscore 	injecao

Em vermelho o problema, Rails não reconhece a gramática portuguesa, logo a pluralização não resulta na forma correta injecoes (injeções).

Para verificar como o Rails trabalha com a pluralização visite o: nubyonrails.

Existem maneiras de desativar a pluralização e fazer a programação “na marra”, mas isso gera um custo adicional desnecessário ao desenvolvedor além de quebrar o conceito do framework que é o de focar o desenvolvimento apenas naquilo que é fundamental.

E, traduzindo o modelo, não irá garantir que os campos que são controlados pelo Rails como “id”, “created_at”, “updated_at” entre outros, também serão traduzidos, ou seja, você terá que mantê-los ou novamente, dedicar tempo a esta tarefa.

Por fim, qual dos códigos abaixo é o de mais fácil compreensão?

1: @liner = Liner.find_by_code "001"
2: @liner = Liner.find_by_codigo "001"
3: @armador = Armador.find_by_code "001"
4: @armador = Armador.find_by_codigo "001"

Se você domina o inglês, obviamente irá optar pela primeira opção. Se você é adepto do português irá escolher a opção 4 (depois de desabilitar a pluralização), só que isso implica em ter o seu código funções pseudo-traduzidas pois o “find_by” não é traduzido. Ah! Mas então, para evitar isso, você pode partir para a solução 3, ter todos os campos escritos em inglês, o que não parece lógico já que não existe nenhum grande esforço adicional em também ter o modelo traduzido.

Portanto, a melhor solução é continuar usando a pluralização e traduzir seus campos para o inglês. Quem sabe, com o tempo que você vai ganhar no desenvolvimento, você consegue finalmente se inscrever naquele curso de inglês? 🙂

21 abril, 2008

Muita atenção nas convenções

Filed under: Ruby / Rails — Tags:, , — hollanderramos @ 20:39

Um dos motivos do Rails ser tão produtivo é o fato dele trabalhar com convenções. Com isso, abstrai-se do desenvolvedor a necessidade desta tarefa, ganhando – muito – tempo. Dentre as convenções, uma refere-se a criação dos atributos de um modelo, gerando na migração, os campos nas tabelas. Note esta migração criada por mim:


create_table :liners do |t|
t.column :Codigo, :string, :limit => 3
t.column :Descricao, :string, :limit => 30
t.timestamps
end

add_index(:liners, :Codigo, :unique => true)

Se você já é um veterano de Rails, já deve ter percebido o que está errado. Ok. pare por aqui e pule para o próximo post. Agora, se você é como eu, um novato de pouco mais de 48h na linguagem, continue lendo.

A migração funcionou bem, a tabela foi criada, assim como os campos. O sistema também correspondeu as expectativas até que eu acrescentei a seguinte validação na classe:

validates_uniqueness_of :Codigo

Esta validação evita a criação de registros que contenham o mesmo “código” como valor. Porém, sempre que eu tentava testar o formulário com esta validação habilitada, lá vinha uma mensagem de exceção StatementError de meu Banco de Dados, informando que a coluna codigo não existe.

Como não? Ela (a coluna) está lá! Certo? Outras validações como validates_presence_of :Codigo também está lá na classe e funciona! O que está errado?
A resposta é que não observei a convenção. Os campos no Rails devem estar em totalmente em minúsculas.

Uma rápida alteração no Banco de Dados e em todas as partes da aplicação para codigo e tudo voltou ao normal.

Ainda existe um outro problema nesta minha codificação. O fato dos atributos estarem escritos em português ao invés de inglês, mas isso é um problema para ser discutido em outro momento.

Ou seja, as convenções são uma mão na roda no ganho da produtividade, porém exige do desenvolvedor (principalmente o iniciante) o seu preço: Conhecê-las intimamente.

Blog no WordPress.com.