Sim, funcionou sim! Vlws; Bacana! :lol:
[quote=garcia-jj]…
Já temos planos de usar o Bean Validation? …[/quote]
Garcia, Lucas C., outros forks do VRaptor e contribuidores,
Fantástico: 1 grande idéia no vRaptor ser implementada a integração c/ a JCP - JSR 303: Bean Validation!!! :thumbup:
E q tal de repente adotar 1 @Anotação (bem ao estilo do Stripes) para definir quais métodos vão ser validados e quais não vão. Ou melhor ainda: por padrão/convenção o form em todos os métodos da Controller é sempre validado; e no(s) método(s) q nós não queremos/podemos validar seus dados, poderiamos simplesmente adotar/adicionar 1 Annotation [color=red]@DoNotValidate[/color] :mrgreen:
O q acham??!
vc diz validar de acordo com as anotações no modelo?
[quote=Lucas Cavalcanti]a gente aceita contribuições com prazer, garcia =)
não começamos a fazer ainda…[/quote]
Lucas, essa semana estou meio dividido na implantação de um sistema (feito com vraptor, claro 
), mas no final de semana vou mexer nisso.
[quote=Lucas Cavalcanti]não tenho windows instalado na minha máquina… logo não dá pra eu testar no IE… qual versão vc tá usando?
IE6? IE7? IE8?[/quote]
Já gostava de ver teus códigos, documentações e forma de responder para a galera no fórum. Mas agora ganhou nota mil no meu conceito, hehe. Se eu te contar que eu nem sei trocar um papel de parede no windows tu vai rir de mim, haha.
[quote=derlon]Fantástico: 1 grande idéia no vRaptor ser implementada a integração c/ a JCP - JSR 303: Bean Validation!!! :thumbup:
E q tal de repente adotar 1 @Anotação (bem ao estilo do Stripes) para definir quais métodos vão ser validados e quais não vão. Ou melhor ainda: p/ padrão/convenção o form em todos os métodos da Controller é sempre validado; e no(s) método(s) q nós não queremos/podemos validar seus dados, poderiamos simplesmente adotar/adicionar 1 Annotation [color=red]@DoNotValide[/color] 8)
O q acham??![/quote]
No início de tudo eu pensei em aproveitar um código inicial que desenvolvi para um projeto aqui na empresa usando vraptor, que é a mesma coisa que o validator que o vraptor tem para o Hibernate Validator, porém usando os validadores da JSR 303. Nesse caso não sei nem se precisa dessa @DoNotValidate, pois você precisa chamar o validator manualmente. Conforme a documentação do vraptor.caelum.com.br:
public adiciona(Funcionario funcionario) {
//Validação do Funcionario com Hibernate Validator
validator.addAll(Hibernate.validate(funcionario));
}
Penso em fazer algo semelhante, por exemplo, BeanValidator.validate().
[quote=Lucas Cavalcanti]vc diz validar de acordo com as anotações no modelo?[/quote]Isso mesmo (Validações diretamente (nos Atributos) na Classe Entidade de negócio), Lucas! 
[quote=garcia-jj]Penso em fazer algo semelhante, por exemplo, BeanValidator.validate()[/quote] Garcia, o ‘Hibernate Validator’ faz parte (da implementação) do Hibernate, certo??! Então, desta forma, teríamos q dar 1 import do Hibernate na nossa (camada) WebFrontController, q fica, geralmente, a (pelo menos) 2 camadas da layer de Persistência (ou Acesso/Repositório a/de Dados).
:idea: Assim, IMHO, creio q o “estado da arte” seria podermos colocar 1 Annotation AddValidadion ou ApplyValidadion (sei lá! [color=red]@ApplyValidation[/color]) em nossa Classe Controller e @DoNotValidate no(s) método(s) q nós não precisamos validar!! :twisted:
E o Stripes consegue, de alguma forma, propagar as Validações do Bean Validation / Hibernate Validator até a View, daí parece q c/ 1 plugIn/frameWork [color=red]AJAX[/color] conseguimos gerar Validações Client-Side! :XD: O q acham?!!
Obs.: 1. melhor ainda q o Struts2 q, p/ fazer isto, ainda faz isto via .XML (arght)!
2. Garcia, ainda considero válida sua abordagem/contribuição, até para o amadurecimento (do desenvolvimento) da Validação! :thumbup:
bom… dá pra fazer algo assim, mas é meio ruim ficar poluindo o controller com um monte de anotações… principalmente anotações de comportamento…
as anotações deveriam ser apenas pra marcação, apenas metadados, e não deveriam habilitar/desabilitar comportamentos
de qqer forma, prefiro que isso seja programático, algo do tipo:
validator.validate(objeto);e vc define o comportamento de validação sobrescrevendo um componente do vraptor… daí vc pode usar como implementação o Hibernate, a JSR-313, o MeuSuperFrameworkDeValidaçãoQueEuFizSozinho, etc…
(Sem querer ir + off-topic: como está tensa a questão da lincença do JCK para o Apache Harmony: :arrow: http://khanderaotech.blogspot.com/2007/04/jsr-313-for-j2ee-60-received-setback.html c/ atenção especial a ‘Carta Aberta à Sun’ e 'comentários s/ os termos de licença(na JCP). :hunf: )
Mas, Lucas, vc acha q anotações de comportamento na Controller podem causar efeitos colaterais na integração com WebServices, principalmente na abordagem RESTfull??!
efeitos colaterais acho que não… só prefiro a maneira programática mesmo… nesse caso faz mais sentido um validator.validate(obj); do que um @ApplyValidation no parâmetro ou no método…
Não, Bean Validator foi impulsionado pelo pessoal do Hibernate, porém ele não faz parte da implementação de Hibernate. Mesmo que fosse o vraptor com seu HibernateValidator já faz uso direto das classes do Hibernate. Embora eu não concorde com isso, o vraptor possui muita coisa que faz uso direto do Hibernate, inclusive o HibernateValidator.validate.
Concordo contigo. Embora como já citei acima, mesmo não gostando de misturar Hibernate com camada web, não vejo forma melhor de fazer um validador para a JSR303 diferente da forma atual. Conforme você mesmo já disse, é muito mais simples e claro fazer uma espécie de BeanValidator.validate(meuBean). Dessa forma seguimos o padrão que já existe e também mantem-se a simplicidade.
Anotações parecem legal, mas quando menos anotações melhor. O ideal é você sempre usar anotações como item opcional, não como “item de série”. Lembro de certa vez lendo os docs do Struts 2 a quantidade de anotações necessárias para validar uma simples entrada de dados em uma action: http://struts.apache.org/2.1.6/struts2-core/apidocs/com/opensymphony/xwork2/validator/annotations/Validation.html
nada que o VRaptor usa do hibernate é obrigatório… toda dependência com o Hibernate é opcional dentro do vraptor…
Garcia, neste ponto o Lucas (como eu diria) is quite sure!:!: Nada no VRaptor nos obriga a usar qq coisa do Hibernate (a pesar q ele tornar a Validação muito menos [color=red]verborrágica[/color]). :hunf:
Mas em momento algum eu disse que são obrigatórios :).
E sobre o Bean Validator, o que vocês acham? Abraços
acho que seria legal a gente suportar sim… mas não com um método estático como está agora com o hibernate
Hmm, comecei a dar uma analisada ontem nisso. Como você acha que deve ser? Um objeto não estático porém injetado assim como o validator?
public class JSR303Validator { // não repare no nome :twisted:
[blah blah blah]
}
Usando o bicho.
[code]public class MyController {
public MyController(JSR303Validator validator) {
this.validator = validator;
}
public void foo(MeuBean bean) {
validator.validate(bean);
}
}[/code]
acho que pode ser assim:
-adicionar o método validate(Object) na interface Validator
-criar uma interface chamada BeanValidator ou coisa do tipo com duas implementações: a do Hibernate e a da JSR303
-na implementação do Validator, receber um BeanValidator no construtor e delegar a validação pra ele
que acha?
[quote=garcia-jj]
Não, Bean Validator … não faz parte da implementação de Hibernate.
…
[/quote]Garcia, me confundi 1 pouco e acabei digitando ‘BeanValidation’ em vez de ‘Hibernate Validator’ (mas, já voltei lá e fiz o ajuste). 
Aproveitando o ensejo: como ficariam, na abordagem q vc está propondo, as validações, digo direto nos atributos e como seria as MSGs de erro, inclusive usando as chaves do Bundle? (P/ gentileza, poderia mostrar 1 ex.?):?: (espero NÃO estar parecendo 1 pessoa “Obcecada” p/ i18n. :roll: )
Concordo contigo. Embora como já citei acima, mesmo não gostando de misturar Hibernate com camada web, … Dessa forma seguimos o padrão que já existe e também mantem-se a simplicidade.
[/quote] Lucas, (“validator.validate(obj)”): vc se refere a Classe ‘Validator’ do VRaptor; e o método ‘validate()’ subentende o disparo de Validações da/e (qq) JSR303 adotada (na nossa Classe-Entidade (devidamente anotada)); em alternativa ao método ‘checking()’ atual abordagem de Validação Fluent (até p/ manter a compatibilidade (c/ versões anteriores))??!
[quote=garcia-jj]
Anotações parecem legal, mas quando menos anotações melhor. O ideal é você sempre usar anotações como item opcional, não como “item de série”. Lembro de certa vez lendo os docs do Struts 2 a quantidade de anotações necessárias para validar uma simples entrada de dados em uma action: http://struts.apache.org/2.1.6/struts2-core/apidocs/com/opensymphony/xwork2/validator/annotations/Validation.html[/quote] … no Princípio, a Sun criou a obra: J2EE Core-Patterns (Obs.: onde estiver escrito “J2EE Core-Patterns”, leia-se 'EJB Core-Patterns '. :?).
Um tempo depois, a GoF lançou seu 24 Design-Patterns dividos em 3 categorias.
Martin Fowler propôs padrões para IoC-InversionOfControl.
Se continuarmos esta discussão sobre Validação, vamos acabar criando Design-Pattern(s) para Validações! :shock:
Lucas, desculpe a brincadeirinha, mas esta discussão foi muito importante p/ mim, pois acabei pesquisando e descobrindo a verdadeira essência do conceito de CoC, muito além do significado de suas palavras-chave: Convention - Convenção/Padrão; Over (priorizada em relação); e Configuration. Este conceito reside na “Programmatic Configuration”.
Garcia, (Karaka!!! :shock: ) no Livro Mentawai in Action :arrow: http://book.mentaframework.org/posts/list/5.page, saoj (não sei se ele é 1 dos criadores do Menta) tb transcreve o [color=red]MEGA VERBORRÁGICO[/color] free-block anotado c/ @Validations (na class SimpleAnnotationAction) citado p/ ti.
Lucas, os criadores do Mentawai se guiaram em 2 principios para concebê-lo: KISS/Simplicidade (q tb é das abordágens ágeis) e ‘se CoC é bom, leve CoC ao eXtremo’ (só q tão extremo/[color=red]radical[/color] ao ponto de não usar Java[color=red]Annotations[/color] :x) Creio q na atual conjuntura seria impossível imaginar IoC s/ Annotations. Fico muito contente de o VRaptor manter a elegância da simplicidade, porém (usando Annotations na medida certa 8) ) sem deixar de usar os poderosos recursos da IoC!!! :thumbup:
[quote=Lucas Cavalcanti]acho que pode ser assim:
-adicionar o método validate(Object) na interface Validator
-criar uma interface chamada BeanValidator ou coisa do tipo com duas implementações: a do Hibernate e a da JSR303
-na implementação do Validator, receber um BeanValidator no construtor e delegar a validação pra ele
que acha?[/quote]
(Mesmo para mim, q não sou nenhum 1 pouco fã de codificar Validações na Action/FrontController) Agora sim! :thumbup: Esta é 1 abordágem bem razoável!! :lol:
[quote=Lucas Cavalcanti]acho que pode ser assim:
-adicionar o método validate(Object) na interface Validator
-criar uma interface chamada BeanValidator ou coisa do tipo com duas implementações: a do Hibernate e a da JSR303
-na implementação do Validator, receber um BeanValidator no construtor e delegar a validação pra ele
que acha?[/quote]
Perfeito. Porém fiquei com dúvida sobre como o vraptor saberá qual implementação dele deve usar, se Bean Validator ou Hibernate Validator 3.X. No meu caso eu usaria o BeanValidator, mas pode ter alguém que queira usar o Hibernate Validator.
Como o vraptor irá apenas delegar a validação para o BeanValidator, isso dependerá tudo dele. Só que se não me engano quando você inicializa o bean-validator precisa indicar o locale a ser usado. Não sei como o vraptor sabe qual o locale usar internamente, mas podemos fazer uso o atributo javax.servlet.jsp.jstl.fmt.locale para passar o locale para o bean-validator, Lucas?
Vou ver se faço algo até o final de semana, uma espécie de initial release, e aí podemos ir planejando umas melhoras. Eu ainda não senti a necessidade das annotations, mas acho que tendo essa implementação inicial pode exclarecer um pouco esse ponto para nós.
Abraços
D+, Garcia!!! :thumbup:
Já estou ansioso para ver o resultado (ainda q seja inicial) desse trabalho!! :XD: