Curiosidade

10.fevereiro.2009
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?

Anúncios

Link

03.fevereiro.2009

Mapear uma id tipo string no Grais – base de dados legado

Pelo que entendi, é de um blog novo sobre Grails. Convém acompanhar.


Mudando a página inicial padrão no Grails

30.janeiro.2009
Ao se criar uma aplicação padrão em Grails, a página inicial é o index.gsp, que fica na pasta web-app.

Por algum motivo que não interessa para o momento, a minha aplicação estava ficando torta com essa configuração. Comecei a misturar página estática com gambiarra para suprir a ausência de um controller.

Como a gambiarra é um bumerangue, e para não fugir do MVC, é possível resolver isso alterando o arquivo grails-app/conf/UrlMappings.groovy, da forma abaixo:

class UrlMappings {
  static mappings = {
    "/$controller/$action?/$id?"{
      constraints {
        // apply constraints here
      }
    }
    "500"(view:'/error')
    "/" {
      controller = "app"
      action = "login"
    }
  }
}

O controller app, que é onde eu centralizo o fluxo da aplicação, fica da seguinte maneira:

class AppController {
  def login = {
    render (view: 'login')
  }
}

Aí você pergunta: ‘mas para que tanta complicação se a action apenas renderiza uma view?’

De fato, é apenas esforço inútil. Porém, se eu quiser que o usuário, devidamente autenticado, seja redirecionado para a tela principal da aplicação sem ter que passar novamente pelo login, posso alterar o código para que a action resolva isso:

  def login = {
    if(session.user)
      render (view: 'telaInicial')
    else
      render (view: 'login')
  }

Fica ao gosto do freguês, claro.


Hail for Grails

19.janeiro.2009
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.