Entity Listeners em Domain Class
04/01/2016 12:36
1
Bom dia pessoal,
Comecei a dar uma estudada em Grails nos ultimos dias e resolvi fazer um crud simples para experimentar o framework e a linguagem Groovy que não conhecia muito bem.
Me deparei com a seguinte situação:
Gostaria que determinada lógica fosse executada em todas as classes de domínio no momento que fossem salvas. No caso o que gostaria de fazer seria um listener para garantir que todas as Strings sejam salvas em upper case, por uma questão de padronização, pois um dos requisitos que muitas aplicações que já vi pedem, é que todos os inputs só aceitem campos em upper case para evitar cadastros e relatórios despadronizados.
Com JPA/Hibernate consigo utilizar @EntityListeners para realizar tal tarefa. Tentei anotar minhas classes de domínio com essa anotação porém não funciona.
Existe alguma estrutura de listeners de persistencia no Grails? Estou utilizando a versão 2.4.4
Obrigado
Comecei a dar uma estudada em Grails nos ultimos dias e resolvi fazer um crud simples para experimentar o framework e a linguagem Groovy que não conhecia muito bem.
Me deparei com a seguinte situação:
Gostaria que determinada lógica fosse executada em todas as classes de domínio no momento que fossem salvas. No caso o que gostaria de fazer seria um listener para garantir que todas as Strings sejam salvas em upper case, por uma questão de padronização, pois um dos requisitos que muitas aplicações que já vi pedem, é que todos os inputs só aceitem campos em upper case para evitar cadastros e relatórios despadronizados.
Com JPA/Hibernate consigo utilizar @EntityListeners para realizar tal tarefa. Tentei anotar minhas classes de domínio com essa anotação porém não funciona.
Existe alguma estrutura de listeners de persistencia no Grails? Estou utilizando a versão 2.4.4
Obrigado
0
Oi Anderson.
Sim, é possível, e este post, sobre o audit logging é justamente sobre isto: http://hartsock.blogspot.com.br/2008/04/inside-hibernate-events-and-audit.html
Sim, é possível, e este post, sobre o audit logging é justamente sobre isto: http://hartsock.blogspot.com.br/2008/04/inside-hibernate-events-and-audit.html
04/01/2016 15:25
0
Kico, obrigado pela resposta.
É uma pena o framework não fornecer uma abstração para essas features do hibernate/jpa.
Li esse link que vc me mandou, e pensei em implementar uma estrutura para criação de listeners para entidades de domínio,porém criei um plugin e não consigo implementar as interfaces do hibernate que são utilizadas nesse tutorial. Não sei se preciso declarar algum tipo de dependencia. Não consigo implementar por exemplo a interface PreDeleteEventListener na minha classe Groovy. Dado que esse link é bem antigo, não sei se pode ser diferenças de versões.
É uma pena o framework não fornecer uma abstração para essas features do hibernate/jpa.
Li esse link que vc me mandou, e pensei em implementar uma estrutura para criação de listeners para entidades de domínio,porém criei um plugin e não consigo implementar as interfaces do hibernate que são utilizadas nesse tutorial. Não sei se preciso declarar algum tipo de dependencia. Não consigo implementar por exemplo a interface PreDeleteEventListener na minha classe Groovy. Dado que esse link é bem antigo, não sei se pode ser diferenças de versões.
04/01/2016 19:07
0
Anderson,
De uma olhada aqui http://grails.github.io/grails-doc/3.0.x/guide/GORM.html#eventsAutoTimestamping
Em "Custom event listeners"
Há uma API independente do mecanismo de persistencia.
De uma olhada aqui http://grails.github.io/grails-doc/3.0.x/guide/GORM.html#eventsAutoTimestamping
Em "Custom event listeners"
Há uma API independente do mecanismo de persistencia.
05/01/2016 08:22
0
Oi Anderson,
o negócio é ver qual a versão do Hibernate que você está usando nas dependências do seu projeto e, em seguida, checar o Javadoc desta versão do Hibernate e aplicá-la nos seus listeners.
Dá pra usar tudo do Hibernate no Grails, pois no final das contas, o que você tem de verdade é uma aplicação Spring MVC coberta por uma camada de Groovy.
Qualquer coisa, estou aqui pra te ajudar, ok?
o negócio é ver qual a versão do Hibernate que você está usando nas dependências do seu projeto e, em seguida, checar o Javadoc desta versão do Hibernate e aplicá-la nos seus listeners.
Dá pra usar tudo do Hibernate no Grails, pois no final das contas, o que você tem de verdade é uma aplicação Spring MVC coberta por uma camada de Groovy.
Qualquer coisa, estou aqui pra te ajudar, ok?
05/01/2016 09:26
1
MagnoObrigado pela resposta.
Vi o link que vc mandou e para o meu problema no caso, nem precisaria implementar um listener customizado. Com um pouco OO os eventos beforeInsert, beforeUpdate etc já resolveria meu problema. Mas é interessante saber que existe a possibilidade de implementações de listeners customizados. Resta saber se isso está presente na versão 2.4 do grails. Vou conferir.
KicoA versão do hibernate utilizada não é definida pelo proprio Grails? Percebi que no BuildConfig do meu projeto está definida a versão 4.x.x. do Hibernate. Porém, no BuildConfig do plugin não está definida nenhuma versão explicitamente. No caso de plugins eu preciso definir uma versão do hibernate manualmente?
Valeu peja ajuda pessoal.
05/01/2016 11:45
0
Pensei em sugerir beforeInsert e beforeUpdate, mas acho que iria poluir as classes, além de ser um trabalho repetitivo e sujeito a erros implementar isso manualmente. Uma coisa que você pode ver é implementar uma transformação AST que adicione os métodos beforeInsert e beforeUpdate na classe automaticamente em tempo de compilação
05/01/2016 14:37
0
Oi Anderson,
exatamente: o Hibernate é definido pelas configurações padrão do Grails. Há inclusive algumas versões nas quais o arquivo BuildConfig.groovy (ou build.gradle) possuí comentada a versão 4 e exposta a versão 3.
No caso de plug-ins, você vai ter de verificar no próprio código fonte do mesmo qual é a versão que ele usa, o que pode dar uma certa dor de cabeça para você, pois imagine que o plug-in, por exemplo, use a versão 4, e você, a versão 3.
E Anderson, bela pergunta: este é um tópico muito interessante, obrigado por compartilhar!
exatamente: o Hibernate é definido pelas configurações padrão do Grails. Há inclusive algumas versões nas quais o arquivo BuildConfig.groovy (ou build.gradle) possuí comentada a versão 4 e exposta a versão 3.
No caso de plug-ins, você vai ter de verificar no próprio código fonte do mesmo qual é a versão que ele usa, o que pode dar uma certa dor de cabeça para você, pois imagine que o plug-in, por exemplo, use a versão 4, e você, a versão 3.
E Anderson, bela pergunta: este é um tópico muito interessante, obrigado por compartilhar!
05/01/2016 15:33
0
Magno?Mas pensando bem, talvez não seja uma boa inserir esses métodos na classes através de um plugin. Pq os métodos beforeUpdate, beforeSave etc, deveriam ser responsáveis por ações específicas em cada domínio certo? Se eu adiciono em tempo de execução esses métodos em todas as minhas classes de domínio para incluir essa regra que postei, eu perderia a chance de incluir esses métodos em cada classe específica certo? O método do plugin iria "sobrescrever" o que está na classe, ou estou falando besteira? Dado que essa funcionalidade seria um requisito transversal à aplicação, ele seria melhor modelado utilizando aspectos. Eu ainda não pesquisei como é o suporte a aspectos do Grails, mas talvez seja mais interessante.
KicoEntendi a questão dos plugins, obrigado por esclarecer. Espero que esse post possa ajudar outras pessoas tbm.
06/01/2016 10:40
0
Anderson,
Depende de como você implementar a AST.
Você pode, por exemplo, fazer com que caso a classe em questão já tenha um método beforeUpdate, o mesmo seja ele seja apenas estendido. Em termos simples, a seguinte classe:
class Customer {
String name
def beforeUpdate() {
// Sua própria lógica aqui
}
}
Ao ser compilada, a classe viraria algo como:
class Customer {
String name
def __beforeUpdate() {
// Sua própria lógica aqui
}
def beforeUpdate() {
name = name?.toUpperCase()
__beforeUpdate()
}
}
MAS, você chegou a olhar a API to link que postei? Não investiguei muito, mas a princípio atenderia sem precisar sujar tanto as mãos e sem depender de Hibernate
Depende de como você implementar a AST.
Você pode, por exemplo, fazer com que caso a classe em questão já tenha um método beforeUpdate, o mesmo seja ele seja apenas estendido. Em termos simples, a seguinte classe:
class Customer {
String name
def beforeUpdate() {
// Sua própria lógica aqui
}
}
Ao ser compilada, a classe viraria algo como:
class Customer {
String name
def __beforeUpdate() {
// Sua própria lógica aqui
}
def beforeUpdate() {
name = name?.toUpperCase()
__beforeUpdate()
}
}
MAS, você chegou a olhar a API to link que postei? Não investiguei muito, mas a princípio atenderia sem precisar sujar tanto as mãos e sem depender de Hibernate
06/01/2016 14:16
0
Magno?Eu vi sim o link que vc mandou sobre a API e acredito que atenda meu caso sim. Ainda não tive tempo de testar.
Levantei essa outra questão pra tentar avaliar os prós e contras de cada abordagem. Essa estrutura parece melhor em relação a AST (opinião de um leigo na tecnologia).
Obrigado de novo!
06/01/2016 14:35
Ainda não faz parte da comunidade???
Para se registrar, clique aqui.
Aprenda Groovy e Grails com a Formação itexto!
Newsletter Semana Groovy
Os melhores blogs de TI (e em português) em um único lugar!
