Mentawai Forum - Mentawai Web Framework

Pessoal....

Axo que o menta deveria sair com algunas mensagens padrões para as validações.

Tava lendo o Hibernate Annotations, eles tbm tem isso. +- assim:

4.1.3. Error messages

Hibernate Validator comes with a default set of error messages translated in about ten languages (if yours is not part of it, please sent us a patch). You can override those messages by creating a ValidatorMessages.properties or (ValidatorMessages_loc.properties) and override the needed keys. You can even add your own additional set of messages while writing your validator annotations. If Hibernate Validator cannot resolve a key from your resourceBundle nor from ValidatorMessage, it falls back to the default built-in values.

Alternatively you can provide a ResourceBundle while checking programmatically the validation rules on a bean or if you want a completly different interpolation mechanism, you can provide an implementation of org.hibernate.validator.MessageInterpolator (check the JavaDoc for more informations).

Isso seria uma boa =)

Eu estava tentando fazer isso. Dá um trabalho grande! Será que vale a pena?

Dá uma olhada aqui: http://www.mentaframework.org/validation.jsp

É possível usar mensagens default ??? Acho que a única que faria sentido seria: Campo não preenchido. O resto geralmente vc precisa do nome do campo ou alugma outra informação que não dá para generalizar!

Sergio, no Struts funciona assim:

#-mensagens de erro padrão para as validações
errors.required={0} é um campo obrigatório.
errors.minlength={0} não pode conter menos que {1} caracteres.
errors.maxlength={0} não pode conter mais que {1} caracteres.
errors.invalid={0} está inválido.
errors.byte={0} deve ser um byte.
errors.short={0} deve ser um inteiro curto.
errors.integer={0} deve ser um inteiro.
errors.long={0} deve ser um inteiro longo.
errors.double={0} deve ser um ponto flutuante de precisão dupla.
errors.date={0} não é uma data.
errors.range={0} não está na faixa entre {1} e {2}.
errors.creditcard={0} não é um número de cartão de crédito válido.
errors.email={0} não é um e-mail válido.

Então essas mensagens já vem prontas, a pessoa não tem que ficar digitando toda hora. A única coisa que ela faz é passar os parametros para o validador (que nos casos acima, são desde o nome do campo aos tamanhos e etc...)

Veja se isso clareia as idéias sobre esse recurso.
Mas em virtude da possível dificuldade, avalie a real necessidade desse recurso para o teu framework. Ou se for o caso, feche as idéias e programe no jira para uma versão futura. Mentawai 2.5, sei lá...

Abraços,

Por exemplo:
No vraptor existia Mensagens de validacoes parecido com o mentawai.
Mas uma parada muito boa era as mensagens de validacoes padrao do Hibernate.

Nao sei se tinha como personalizar ou internacionalizar.
Mas eram coisas do tipo.

Code:

public class Pessoa{
 @Notnull
 @Length(max =12)
 private String nome;
 @Notnull
 @Lenght(min = 3 , max = 4)
 private int idade;
 }

Gostava disso por varios motivos.
Eram validacoes que existiam se eu ter que criar uma(para projetos rapidos), mesmo que fossem em ingles;
aara testes;
mais seguranca com os dados no banco;
nao lancava exception, lancava uma mensagem e um forward para o JSP(Nao sei como o vraptor tratava isso);
e outros casos que nao me lembro agora

.

Eu usava mais para testes e seguranca.

Caso existisse as 2 validacoes do vraptor e do hibernate. A primeira acionada era do vraptor, pois nem chegava na persistencia. Depois de tudo certo ia para a do hibernate.
Caso algum usuario de má fé usasse sql injection, rolaria a do hibernate e entao se o usuario for ver a mensagem ingles. Com certeza sao so para os usarios com alguma maldade com o sistema.
Resumido: Seguranca, sem exception...

Não entendi.

O nome do campo muitas vezes será internacionalizado também.

Por exemplo: username e apelido.

E aí?

os parametros são keys...
usuario.username=Username

em vez de passar Username como parametro dá para passar usuario.username.

bruno.braga wrote:

os parametros são keys...
usuario.username=Username

em vez de passar Username como parametro dá para passar usuario.username.

Continuo sem entender.

O cara vai estar internacionalizando partes de uma mensagem internacionalizada? Me parece redundante.

Como ele vai passar o username internacionalizado para dentro da mensagem padrão internacionalizada?

Sei lá, acho que se deixasse a coisa automática de forma que ele não precisasse fazer nada seria uma boa. Mas se ele vai ter que internacionalizar parte da mensagem, então é natural que ele internacionalize ela toda. Digitar um pouco a mais ou um pouco a menos não é um argumento forte, ainda mais se estaremos complicando a coisa por causa disso.

não entendi a dúvida direito...

a mensagem é internacionalizada, mas a grande vantagem é que ela é padrão... para o erro do tipo required, é aquela mensagem ali... para de outro tipo é outra...

porém uma parte da mensagem é parametrizavel com uma key internacionalizada...
Isso existe para não ter que criar 10 mensagens iguais como é hoje:

- Username é um campo obrigatório.
- Senha é um campo obrigatório.
- Email é um campo obrigatório.
- etc...
(isso para cada idioma)

Então a mensagem internacionalizada é parametrizavel com um outro valor internacionalizavel... Parece redundante mas é para evitar o problema acima...
O fw primeiro internacionaliza os parametros, depois pega os valores e substitui na mensagem...

Mas não quero defender esse recurso... Só estou explicando como funciona. Avaliem a necessidade.

Entendi mais ou menos.

Então ao invés de internacionalizar as mensagens abaixo.

- Username é um campo obrigatório.
- Senha é um campo obrigatório.
- Email é um campo obrigatório.

O cara vai internacionalizar apenas:

- Username
- Senha
- Email

Entendo que evita repetição de texto dentro do arquivo i18n. Mas isso é um argumento forte?

Não sei. Pode ser que vc tenha razão. Estou pensando... Mas acho que o custo-benefício disso é muito baixo.

saoj wrote:

Então ao invés de internacionalizar as mensagens abaixo.

- Username é um campo obrigatório.
- Senha é um campo obrigatório.
- Email é um campo obrigatório.

O cara vai internacionalizar apenas:

- Username
- Senha
- Email

Mais ou menos... Na verdade eu vejo pelo lado que ele não vai internacionalizar nada, porque em um projeto normal esse Username, Senha, Email já é internacionalizado para montar a tela. Ele só vai fazer referencia (manual / automático) a uma mensagem de erro default que já existe, e a uma key de internacionalização (label) que já existe.

Mas é a questão do custo beneficio... Algo para avaliar... As vezes é pratico, mas se for dar trabalho n adianta.

Eu tenho uma sugestao.
O Mentawai é nacional, entao ele ja podia vir com as mensagens citadas acima em ingles e portugues.
Voce pode me perguntar se isso é bom ou ruim.
Te afirmo que não é.
Pois o Struts, é todo voltado para o lado americano. A conversao de datas, de moeda, de cep(codigo local?!) e etc..
Tanto que pessoas fora dos EUA tratam tudo que vem de um formulario como String, e depois fazem a conversao como a necessidade.Tem como alterar, mais ai voce perde o padrao do fw.

A minha ideia era so passar os nomes dos campos e os ID das mensagens existentes.
Code:

public void initValidator(Validator val, String innerAction) {
         if ("save".equals(innerAction)) {
             val.add("nome", new RequiredFieldRule(), CAMPO_REQUERIDO);
             val.add("nome", new StringRule(3, 100), TAMANHO_INVALIDO);
             val.add("nome", new RegexRule(NAME_PATTERN), CARACTERES_INVALIDOS);

Desse modo mensagens abaixo ja teriam no default no Mentawai.

Campo obrigatório não-preenchido!
Esse campo deve ter entre %min% e %max% caracteres!
Você digitou caracteres inválidos para esse campo!

Acho que o mais trabalhoso vai ser fazer uma enquente e perguntar qual a mensagem mais "bonitinha"(ideal)

Aí mais as vezes acho isso besteira. Pois na maioria dos casos vou ter que muda-la.
Tem projetos que sao para ontem, tem testes manuais, tem clientes/usuarios que nao esquentam e nem liga para a personalizacao. Nestes casos realmente é uma mao na roda.

[]'s

Pensando junto com tudo isso, não seria uma implementação mais fácil se permitir usar outra chave de internacionalização dentro de uma nova? algo assim:

Arquivo de Internacionalização:
Code:

 desc.obrigatorio=campo obrigatorio
 field.username=Peron %desc.obrigatorio%

Acabaria com a duplicidade de texto, e o parser seria tranquilo com uma regExpr..

poderia até deixar a leitura como permitida para arquivos separados

se eu tiver a oportunidade, posso tentar desenvolver isso pro menta, porém como sou iniciante precisarei de algumas dicas

abraços