VRaptor 3.1 - Validator, sempre é de erro?

essas validações são sempre de negócio… exceptions param a execução da sua lógica e exibem a página de erro 500

Hum, talvez meu conceito de validação de negocio esteja errado.

Mais tem como ser alterada a o tipo de mensagem?
Pois nesse caso quando eu for pegar o valor da chave sempre é ${erro} - ${category}, e nessa situação seria por exemplo ${bussines} - ${message}.

Eu vejo como correto o que o vraptor faz quando ocorrem erros de validação. A Exception que ele lança é um IllegalArgumentException, nada mais do que correto para parametros inválidos.

De qualquer forma outro dia fiz uma sugestão em outro tópico aqui no guj para especializar um pouco mais as implementações de validator.Message. No caso só temos uma ValidationMessage, creio que poderia ser criado uma ErrorMessage, assim dá para diferenciar o que é mensagem de validação e erros genéricos como por exemplo uma chamada a um método de negócio.

Mas no seu caso não vejo muita razão de mudar erros para business. Erro de negócio não deixa de ser um erro.

Abraços

Como já havia dito, eu devo estar enganado a respeito de erro de negócio.

Agora me veio uma dúvida, quando tenho um atributo na minha tabela que seja único, exemplo o login, quando há um erro de unique constraint, isso é um erro de aplicação ou erro de negócio?

é um erro de aplicação que vc deveria prevenir com uma validação…

ou seja, vc faria uma validação do tipo:

-valida que o login não existe na base
-salva o usuario

aí não aconteceria o erro no banco

Lucas, acho que seria interessante criar uma especialização de Message, no caso já tem uma ValidatorMessage, então pensei em uma ErrorMessage quando queremos mostrar erros normais, porém não de validação. Ou quem sabe até uma DefaultMessage quando queremos mostrar mensagens que não são erros.

O que você acha?

já tá implementado:

result.include("erro_normal", "meu erro normal");
result.include("mensagem", "minha mensagem");

=)

brincadeiras a parte, a validação é separada pq ela precisa parar a execução do método, redirecionar pra outro lugar e coisas do tipo…

se vc não precisa disso, não sei se é realmente necessário ter um componente do vraptor pra mensagens diferentes…

Lucas, acho que eu não soube explicar muito bem.

Na verdade minha sugestão é de apenas criar uma classe filha de Message mas que não seja de validação (no caso ValidationMessage). Afinal, nem toda mensagem é de validação. Não estou dizendo em momento algum de fazer mudanças no validator.

Em minha aplicação eu criei uma classe que faz isso, que é uma ErrorMessage para mensagens de erro, mas que não são de validações. Essas mensagens servem apenas para jogar na tela via Validator. Assim eu não preciso manualmente ficar fazendo include mensagem por mensagem.

O Validator faz isso via Message e ValidationMessage. Porém isso é apenas para validação. Pensei que o mais correto era ter um componente que fizesse essa ação de jogar as mensagens para a tela como ${messages} e que ValidationMessage fosse uma filha dela.

O ponto que eu quero chegar é que ValidationMessage é muito especifica, e seria legal que tivessemos a disposião outros tipos de mensagens que pudessem ser jogadas para a tela “automagicamente” como o Validation.

entendi… mas daí vc trata na view essas msgs diferentemente?

Por enquanto eu exporto manualmente via results.include(“messages”, …), então no código JSP eu tenho uma taglib que exibe as mensagens.

só tem que tomar cuidado pra não ficar criando mtos componentes pra isso:

MeuController(Result result, Validator validator, Messages messages, Errors errors)

me parece um pouco demais…

Foi por isso que dei essa sugestão futura pro vraptor, de criar alguma coisa generica com as especializações.

Como te disse não sei explicar muito bem até porque a idéia está muito imatura na minha cabeça. Mas pensei em algo que você pudesse criando as mensagens de erro, validação e afins, e depois jogar para a tela.

Abraços

vai pensando em algo legal e abre uma issue lah no github =)

talvez aumentar ainda mais a interface Result… mas ela ja ta ficando grande…