Uma coisa bem chata que acontece, é que quando tentava abrir arquivos com a extensão txt no Mac, sempre abria o TextEdit, o editor padrão do Mac OS.

É um editor muito simples e pouco funcional, o que me fazia todas as vezes buscar o textmate para editar e trabalhar com os arquivos. Resolvi definir ele como padrão da seguinte forma

1. Localize algum arquivo com a extensão que quer mudar (no meu caso, .txt)
2. Vá em propriedades deste arquivo (ou selecione-o e aperte cmd+I)
3. Na ‘aba’ “Open with”, selecione o programa que deseja usar
4. Selecione o botão “Change All” para setar como padrão para todos os arquivos deste tipo.

Pronto, agora os arquivos TXT serão abertos diretamente no Textmate!

Uma situação que acontece muito, é a reutilização das funções de taglibs dentro dos controllers de sua aplicação grails. Isso é muito fácil de se fazer, basta chamar o método usando o objeto com o nome do namespace da taglib.
Ou seja, para usar dentro do controller a função de formatação de números, definida pela função formatNumber (taglib já no core do grails), é só fazer a chamada assim:

def myAction = {
render g.formatNumber([number:5000.234, type: "number", maxFractionDigits: 2])
}

Esta função é equivalente a chamar a taglib de dentro de um gsp da seguinte maneira:

<g:formatNumber number="5000.234" type="number" maxFractionDigits="2" />

Mas quando precisamos fazer isto, por exemplo, dentro de um service, encontramos um probleminha chato, as taglibs não são injetadas automaticamente. Para contornar essa “situação“, temos que buscar a taglib manualmente, da seguinte maneira:

def myTag = grailsApplication.mainContext.
            getBean('org.codehaus.groovy.grails.plugins.web.taglib.ApplicationTagLib')
def value = myTag.formatNumber([number:5000.234, type: "number", maxFractionDigits: 2])

Ahhh, para isso não se esqueca de injetar o objeto da grailsApplication da seguinte maneira

class MeuService {
   def grailsApplication
   (...)
}

Bin-go.

Quer evitar que suas credenciais (usuário e senha) estejam abertas no seu data-config.xml? A melhor alternativa com certeza é usar um datasource JNDI para isso e manter usuário, senha e url de conexão do banco de dados dentro do cointainer.

Para isso, é só declarar a tag dataSource do data-config.xml desta maneira:

<dataSource user="" password="" jndiName="JndiDoMeuDs"

Sim, os parametros user e password devem ser declados vazios, não se esqueça disso.

Hum, reportando uma situação no mínimo inusitada que tive por aqui.

Acabei descobrindo, da maneira ruim, que no Grails, quando lêmos a configuração da aplicação (Config.groovy) através da referência grailsApplication.config estamos manipulando uma variável passível de alterações, ou seja, qualquer atributo que você recuperar de lá, e modificar, assim estará para toda a execução.

Na minha situação, eu mantinha uma lista de e-mails lá no arquivo de configuração para que quando disparado, eu pudesse enviar o e-mail a estes destinatários somados ao e-mail do usuário, que tinha acabado de ser inputado no formulário. Tinha algo assim:

contato.destinatarios = ["email1@xpto.com", "email2@xpto.com", "email3@xpto.com"]

E dentro do controller, usando o mail plugin (leia este post sobre o mail plugin), executava o seguinte trecho de código:

def destinatarios = grailsApplication.config.contato?.destinatarios?.toArray()
destinatarios << params.email
sendMail {
    to destinatarios
    subject "Contato ..."
    body "......"
 }

Ou seja, quando eu pegava a referência dos destinatários do Config, eu mantinha essa referência em ‘destinatários’. Quando eu adicionava neste array o destinatário que vinha do formulários “params.email”, eu alterava a *instância* e referência da configuração da aplicação, e aquele e-mail ali ficava.

Resultado, no primeiro contato, receberam o e-mail a lista de destinatários e o primeirocontato@xpto.com, na segunda execução, todos eles da configuração, o primeirocontato@xpto.com e também o segundocontato@xpto.com foram copiados.

E assim sucessivamente.

Vivendo e aprendendo, tomem cuidado com isso!

Uma dica pra acompanhar o uso do seu banco de dados, e saber o que o hibernate e o gorm estão fazendo por trás dos panos, é logar as queries que estão sendo feitas.

Você pode acompanhar isto detalhadamente configurando seu DataSource.groovy para fazer isso com o parâmetro loggingSql. E o mais bacana na minha opinião é poder fazer isso de forma independente para cada ambiente. Lembre-se que por default esta configuração vem desligada.

environments {
  development {
    dataSource {
      url = "..."    //banco de dev
      loggingSql = true
    }
  }
  test {
    dataSource {
      url = "..." //banco de testes
    }
  }
  production {
    dataSource {
      url = "..." //banco de produção
    }
  }
}