Solução OO para fazer sua aplicação Rails trabalhar de modo RESTful:

application_controller.rb:

  def index
    begin
      if request.post?
        create
      elsif request.get?
        read
      elsif request.put?
        update
      elsif request.delete?
        delete
      end
    rescue NameError
      respond_to do |format|
        format.html {render :text => "<h1>Forbidden</h1>", :status => 403}
      end
    end
  end

E no arquivo routes.rb:

  map.connect ':controller/:id'
  # map.connect ':controller/:action/:id'

Como funciona?

Uma aplicaçao Rails RESTful funciona, basicamente, utilizando o método HTTP como verbo e a URI como substantivo.

Ao invés de algo do tipo http://application:3000/user/view/1, com REST você usa http://application:3000/user/1 para pegar os dados, atualizar ou apagar, mudando apenas o método HTTP da chamada.

Porém, por padrão, o Rails entende as requisições como sendo /controller/action/id, por isso a alteração no arquivo routes.rb, para fazer com que o segundo parâmetro seja o ID, já que quem define a action é o próprio método HTTP.

Dependendo do método utilizado, será executada uma action padronizada que será escrita no seu próprio controller, usando o conceito de sobrescrita de métodos. Caso você não escreva qualquer uma das actions, será exibida uma mensagem de erro padrão, permitindo que você foque somente no desenvolvimento do que for necessário.

Ambiente devidamente configurado, fui eu meter as caras no Rails, framework para agilizar e divertir (???) o desenvolvedor, segundo informado no próprio site.

Algumas coisas me empurraram para o Rails, na ordem:

- Curiosidade: acredite, um programador sem curiosidade não é nada além de um repetidor de tarefas.
- Custo: desenvolvendo em Grails eu teria que contratar uma JVM dedicada para hospedar minha aplicação. Isso gerou um custo que deixou o cliente insatisfeito. Como quem manda é ele, fui obrigado a buscar uma solução mais econômica.
- Compatibilidade: Boa parte da aplicação já estava feita em Grails, então eu precisaria aproveitar o máximo possível. Devido ao fato do Grails ter sido criado usando o Rails como base, a migração teoricamente seria menos traumática.
- Produtividade: Esse é o ponto chave do Rails. Em termos de custo de hospedagem, pode ser comparado ao PHP, mas com certeza é uma ferramenta que provê muito mais recursos do que o dinossauro da Zend. Por exemplo, eu posso criar uma tela de cadastro no Rails utilizando poucas linhas de código, enquanto no PHP não existe nenhum suporte nativo a isso, apesar de ferramentas como PHPScaffold.

Tive alguns problemas chatos tentando utilizar o ActiveScaffold, mas esse é mais um projeto que sofre da clássica doença do “fiz, mas não testei”. Não funcionou de jeito nenhum com o Rails 2.2.2 que estou utilizando. Instalei o Streamlined e, por enquanto, tudo está caminhando tranquilamente.

Toda boa idéia acaba desbundando para algo porco, mal feito ou que simplesmente causa a morte de milhões de pessoas, como a televisão, o Orkut ou a bomba atômica.

Alguém, algum dia, teve a idéia de traduzir o NetBeans. Claro, afinal existem milhares de programadores preguiçosos que não sabem trabalhar com um botão Run, mesmo ele sendo aquela setinha verde de sempre, ou um menu File, mesmo ele estando no mesmo lugar desde 1985. Tudo bem, foi uma boa idéia para quem precisa. Bastaria eu baixar a versão em inglês e ignorar as traduções.

Aí alguém avacalhou com a idéia: ‘por que não alteramos o idioma automaticamente, de acordo com as configurações na máquina do usuário?‘. E lá se foi meu direito de escolha para usar o IDE no idioma que eu bem entender.

Para resolver esse problema, já que eu não quero trabalhar com Rails usando Visualizações, Controladores nem Modelagens, você tem que abrir a pasta onde o NetBeans foi instalado, e editar o arquivo etc/netbeans.conf e adicionar na opção netbeans_default_options a sequência -J-Duser.region=US -J-Duser.language=en.

Pronto, abra o NetBeans e aproveite a interface como ela realmente é, com seus devidos Models, Views e Controllers. Ou então, se possível, use o Eclipse, o que eu pessoalmente prefiro.

O título em si é maior que o post, mas vamos lá.

Instalei o Ruby numa máquina que acessa internet através de um proxy HTTP. A conexão não é transparente e todo software que eu instalo na máquina precisa ser configurado para se conectar corretamente.

Após instalar o Ruby, seja lá como você queira (eu instalei usando o ‘one-click-installer‘, execute:
set HTTP_PROXY=http://192.168.6.1:3128

gem install rails

E dê Enter em todas as opções, na falta de um “Yes to all”.

Após alguns instantes, para utilizar a última versão das bibliotecas, digite:

gem update --system

Finalizando, caso você queira utilizar Mongrel ao invés do WEBrick (eu recomendo), você executa:

gem install mongrell

Simples assim. Agora é só se divertir, sorrir e brincar.

O nome inicial do Grails era Groovy on Rails. Soa óbvio, mas eu não achava que fosse sério.

Em Março de 2006, o criador do Rails (o do Ruby) entrou em contato com o responsável pelo Grails e ordenou que ele mudasse o nome do framework. Para evitar a fadiga, o simpático Graeme Rocher acatou à ordem.

Você não poderia ter ido dormir sem saber dessa, hein?

Infelizmente não estou tendo o tempo que gostaria para investir no Clojure. Porém, por uma coincidência, surgiu uma oportunidade para trabalhar com Grails (Groovy on Rails), uma versão Groovy do consagrado framework para Ruby.

Minha primeira impressão foi muito boa. Para montar um CRUD, são necessários menos de cinco minutos, caso você nunca tenha mexido antes com o framework.

“Ah, mas o Rails também tem isso”. Claro que tem, afinal de contas, o Grails é um ‘clone’ que roda com Groovy. É possível gerar um arquivo .war e publicar a aplicação num servidor Tomcat, como uma aplicação Java normal. Por trás dos panos, o que acontece é exatamente compilar o código Groovy para Java, e o Java para o bytecode da JVM. Caso você tenha uma aplicação Rails, pode também utilizar o JRuby para o mesmo fim.

Outro ponto que me chamou a atenção no Grails (ou no Groovy, se preferir) são as contraints. São checagens que você codifica na própria entidade, que funcionam como validações automáticas dos dados inseridos. Numa tela de login, por exemplo, você pode ter uma entidade User e informar que login é único, não pode estar em branco e deve ter entre 5 e 20 caracteres, por exemplo. Tudo isso em uma ou duas linhas de código facilmente legível.

Como o trabalho deve ser entregue rapidamente, não vou ter muito tempo de fuçar e experimentar funcionalidades não usuais, mas com certeza o framework já entra para a minha lista de ferramentas preferidas.

Aos mais puristas, deixo meu compromisso de estudar Ruby e olhar o Rails com mais atenção, já que, ao que me parece, esses frameworks atendem plenamente às minhas necessidades.