Opiniões: Validação do Mentawai sem XML

Se a validação vai ser definida de qualquer jeito, a única diferença de se fazer em XML é que vai ser possível trocar algumas coisas sem ter que recompilar nada, além de tender a ser mais organizado dentro de um arquivo XML do que no meio de um monte de chamadas de métodos e declarações de variáveis em código.

Maurício Linhares:

vai ser possível trocar algumas coisas sem ter que recompilar nada

Mas quando vc altera o XML vc tb não tem que restartar o servidor web para as alterações fazerem efeito ???

Maurício Linhares:

além de tender a ser mais organizado dentro de um arquivo XML do que no meio de um monte de chamadas de métodos e declarações de variáveis em código.

Concordo com vc nesse ponto. Fica um pouco mais organizado e bonito de se ver.

Usar ou não usar XML é coisa de gosto. Cada um tem o seu. Eu prefiro não usar porque:

:arrow: Como eu compilo o XML para saber se tem erro? Um typo por exemplo? Quantas vezes vc já restartou a sua aplicação para descobrir que fez uma bobagem no XML?

:arrow: XML tem javadoc para eu consultar a sintaxe ??? Não dá para comparar dtd com javadoc…

:arrow: Me sinto mais confortável trabalhando com uma linguagem lógica, isto é, para programação, do que com uma linguagem de markup.

Mais uma vez, gosto é gosto. Respeito quem pensa totalmente diferente do que eu coloquei aí em cima.

Mas e aí? Ficou simples o esquema de validação?

Achei interessante, mas não gostei de ver toda a internacionalização dentro de um arquivo só, isso vai terminar virando um pesadelo pra manter. Outra coisa, você poderia usar “chaves” mais “amigáveis” pras mensagens, “1”,“2”, e “3” realmente não ficam muito bem pra um exemplo, elas não se explicam.

O Validator não é baseado em XML, como você citou lá, ele é um framework configurável, e pode ser configurado de diversas maneiras diferentes, tanto programaticamente quanto via XML.

E os erros mostrados na página realmente precisam daquela tag <x:hasErrors/>? Se colocasse só a outra tag, a <x:error/> não ia dar no mesmo não?

Dá uma formatadazinha naquela página .jsp do exemplo, que tá tudo misturado

Sim. Mas isso é muito mais facil do que ter que enviar novo war pra um cliente que precisa só mudar uma validacao.

Se tu precisa tanto dessa garantia que tal um xsd?

No caso de validacoes tu nao vai programar em XML, vai so configurar os regras de validacao, nao vejo motivos pra ter um “javadoc” pra isso.

Outra coisa, tu ja deu uma olhada nisso

]['s

Excelente os seus comentários, Maurício.

Maurício Linhares:

Achei interessante, mas não gostei de ver toda a internacionalização dentro de um arquivo só, isso vai terminar virando um pesadelo pra manter.

Eu tive a mesma sensação que vc está tendo agora, quando unifiquei tudo num arquivo só. Briguei com o designer que falou que era melhor. Falei que ele era maluco, mas aceitei. Depois de alguns meses internacionalizando um site com 4 linguas diferentes, vi que isso é muito bom. Ao invés de 4 arquivos, vc tem um, ou seja, vc corta por 4 o número de arquivos que vc precisa manter. :shock:

Vc vê alguma desvantagem prática de ter tudo num arquivo só ??? É só vc manter esse arquivo organizado. Pensa bem, o que é melhor:

HelloWorld_pt_BR.properties, HelloWorld_en_US.properties, HelloWorld_de.properties e HelloWorld_fr.properties

ou

HelloWorld.i18n

É muito mais limpo e organizado, e eu pude constatar isso na prática.

Vc tem toda razão. Vou mudar isso!

O Mentawai oferece um framework de validação sem XML, que é o que eu explico lá. Mas nada te impede de baixar o “facinho” Jakarta Commons Validator e usar.

Precisa pois essas tags são condicionais e as vezes vc vai querer suprimir algo quando não há erro, ex:

<mtw:hasError>
   ERRO: <mtw:error />
</mtw:hasError>

Se vc tira essas tags condicionais no meu exemplo, ele vai imprimir sempre a formatação da mensagem, havendo mensagem ou não, compreende?

“Maurício”:

Dá uma formatadazinha naquela página .jsp do exemplo, que tá tudo misturado

Tem razão. Vou fazer isso mesmo.

Obrigado pelas dicas!

Nada me impede de enviar apenas o meu class file também!

Não complica !!! Isso seria uma complicação a mais que espantaria 90% dos potenciais usuários.

“Fábio”:

No caso de validacoes tu nao vai programar em XML, vai so configurar os regras de validacao, nao vejo motivos pra ter um “javadoc” pra isso.

Dá onde eu tiro o entendimento disso: (isso é o Commons Validator)

<form-validation>
 <global>
  <validator 
     name="required"
     classname="org.apache.struts.util.StrutsValidator"
     method="validateRequired"
     methodparams="java.lang.Object,
                   org.apache.commons.validator.ValidatorAction,
                   org.apache.commons.validator.Field,
                   org.apache.struts.action.ActionErrors,
                   javax.servlet.http.HttpServletRequest" 
     msg="errors.required"/>
     
  <validator name="minlength"
     classname="org.apache.struts.util.StrutsValidator"
     method="validateMinLength"
     methodparams="java.lang.Object,
                   org.apache.commons.validator.ValidatorAction,
                   org.apache.commons.validator.Field,
                   org.apache.struts.action.ActionErrors,
                   javax.servlet.http.HttpServletRequest"
     depends="required"
     msg="errors.minlength"/>
 </global>
</form-validation>

<form-validation>
 <formset>
  <form name="checkoutForm">
    <field 
      property="firstName"
      depends="required">
      <arg0 key="label.firstName"/>
    </field>
         
    <field    
      property="lastName"
      depends="required">
      <arg0 key="label.lastName"/>
    </field>
  </form>
 </formset>
</form-validation>

Legal mas isso é um Rule mais genérico e poderoso. O meu é apenas um Rulezinho simples para validar campos.

saoj:

fabgp2001:

Sim. Mas isso é muito mais facil do que ter que enviar novo war pra um cliente que precisa só mudar uma validacao.

Nada me impede de enviar apenas o meu class file também!

Nada, mas terei que enviar algo pro cliente. No xml nao é preciso.

saoj:

“Fábio”:

Se tu precisa tanto dessa garantia que tal um xsd?

Não complica !!! Isso seria uma complicação a mais que espantaria 90% dos potenciais usuários.

saoj:

“Fábio”:

No caso de validacoes tu nao vai programar em XML, vai so configurar os regras de validacao, nao vejo motivos pra ter um “javadoc” pra isso.

Dá onde eu tiro o entendimento disso: (isso é o Commons Validator)

<form-validation>
 <global>
  <validator 
     name="required"
     classname="org.apache.struts.util.StrutsValidator"
     method="validateRequired"
     methodparams="java.lang.Object,
                   org.apache.commons.validator.ValidatorAction,
                   org.apache.commons.validator.Field,
                   org.apache.struts.action.ActionErrors,
                   javax.servlet.http.HttpServletRequest" 
     msg="errors.required"/>
     
  <validator name="minlength"
     classname="org.apache.struts.util.StrutsValidator"
     method="validateMinLength"
     methodparams="java.lang.Object,
                   org.apache.commons.validator.ValidatorAction,
                   org.apache.commons.validator.Field,
                   org.apache.struts.action.ActionErrors,
                   javax.servlet.http.HttpServletRequest"
     depends="required"
     msg="errors.minlength"/>
 </global>
</form-validation>

<form-validation>
 <formset>
  <form name="checkoutForm">
    <field 
      property="firstName"
      depends="required">
      <arg0 key="label.firstName"/>
    </field>
         
    <field    
      property="lastName"
      depends="required">
      <arg0 key="label.lastName"/>
    </field>
  </form>
 </formset>
</form-validation>

Das tag, pra mim esse xml é claro como a agua. EU sao precisaria ver como ele funciona e o que preciso fazer pra usar.

Mas existem implementacoes prontas ja, nao é preciso desenvolver tudo. Só adaptar.

]['s

Legal a iniciativa de vcs.
Na minha humilde opinião eu acho que vc deve manter o padrão.
Se vc faz a “configuração” dos Actions via programação então faça o resto via programação.

Seria legal vc poder ter CustomRules para validação personalizada.

jprogrammer:

Legal a iniciativa de vcs.
Na minha humilde opinião eu acho que vc deve manter o padrão.
Se vc faz a “configuração” dos Actions via programação então faça o resto via programação.

Sim, no mentawai tudo é feito com código Java.

Isso já tem. Leia o final do tutorial: Creating more rules

JForum: 17 linguas suportadas. Arquivo base (en_US.properties): 800 linhas.

Deixo a matematica para voce

Rafael

usar algo como http://www.beanshell.org pega o bom de ambos os mundo

Rafael

JForum: 17 linguas suportadas. Arquivo base (en_US.properties): 800 linhas.

Deixo a matematica para voce

Rafael

Era exatamente sobre isso que eu estava falando. Colocar tudo dentro de um arquivo só é suicídio, eu acabei de terminar um arquivo de 558 linhas pra inglês de um projeto OS de um amigo e deu trabalho pra caramba, imagina se dentro desse mesmo arquivo estivessem as traduções pra alemão, português, espanhol e italiano? Eu pirava subindo e descendo o arquivo.

Sem contar que se você tiver vários tradutores trabalhando em línguas diferentes com o mesmo arquivo, como é que você reúne tudo? Na marra? Não parece ser uma idéia muito interessante não.

Sobre o XSD que já falaram lá em cima, é pra facilitar a edição do arquivo XML, o XSD tem muito mais opções do que as DTDs.

Se a plataforma alvo é java 1.5 (deveria), experimente usar anotations, pode ficar muito mais sussinto e claro.

Validação implora por uma DSL, experimente com groovy e beanshell pra ver como um script de validação pode ser super claro e ainda ter uma linguagem de programação a mão.

De resto, acho que colocar no código fica tão dificil, senão mais que com xml (também ruim).

Já deu uma olhada nos projetos open source da Adobe? Eles tem 2 linguagens Adam e Eve para resolver isso, é super legal, mas somente para C++.

DSL é dynamic scripting language?

Quase, Domain Specific Language. Ou linguagem específica de domínio. Um bom exemplo é SQL, uma DSL para álgebra relacional.

Aaaaaaaahhhhhhh…

Então essas linguagens de script seriam linguagens específicas pra prototipação e configuração?

Não, linguagens de script são de uso geral assim como Java e C. Pelo menos eu vejo assim. Se são faceis para isso, é detalhe.

Yeap … +1. Se você tiver na sua app linguagens esdruxulas (chinês, ou alguém lembrou do Sami? eheheh) é interessante suportar encodings nos arquivos de internacionalização e isso vc não consegue tendo um só.

Acho que o ponto do Sergio, se nao me engano - e eu espero que eu nao esteja errado nessa - eh nao partir pra coisas “fora” do Java. Assim, o suporte a refactoring da IDE funciona joinha, e o compilador cuida das ocasionais burradas.

Usar uma linguagem de script, arquivo XML ou qualquer coisa que nao seja Java puro com esse objetivo estraga a brincadeira, mas vc pode talvez dar uma incrementada na expressividade da configuracao usando atributos da jdk1.5, que tao la justamente pra essas coisas que antes a gente colocava em deployment descriptor

cv:

Usar uma linguagem de script, arquivo XML ou qualquer coisa que nao seja Java puro com esse objetivo estraga a brincadeira, mas vc pode talvez dar uma incrementada na expressividade da configuracao usando atributos da jdk1.5, que tao la justamente pra essas coisas que antes a gente colocava em deployment descriptor :)

Mais um voto pra atributos :mrgreen:

O povo pediu, agora tem que usar e botar a coisa pra funcionar né.

Mas, como ficaria a implementação de um validador usando atributos? Como é que o sistema ia identificar qual validador ele deveria chamar? Ele testaria tudo pra saber? Iria usar um esquema de AOP dinâmico pra inserir a validação dentro do objeto a partir dos atributos?

Com código fica mais divertido, sem perder a flexibilidade. Ainda não me deparei com alguma situação de validação que não pode ser resolvida elegantemente com BasicRule, que valida um campo apenas, e CrossRule, que compara campos diferentes para a validação.

Muita coisa vc pode fazer herdando de RegexRule.

E se aparecer essa situação, nada te impede de extender a interface base Rule para implementá-la.

Com Java a coisa fica natural para quem conhece Java.

Não podemos esquecer de que a missão desse framework é ser o mais simples possível para o cara que está começando agora e sabe só o básico, por isso quero evitar ao máximo soluções poderosas e não tão simples de entender e assimilar.

Código Java
+ Maior velocidade de aprendizado para usuários super leigos. (aqueles que só Java e não sabem o que é XML)
+ Reaproveitamento de toda a infra-estrutura existente para edição de arquivos Java sem necessidade de criar plugins de suporte à
framework. Ou seja, refactory, geração automática de código, auto completar, mensagens de erro, depuração, cores e tudo mais que as IDEs oferecem.
+ “Configuração Configurável”. Ou seja alguns parâmetros podem ser alterados em tempo de execução
+ Muitos erros de configuração podem ser descobertos em tempo de compilação.
+ Mais simplicidade no projeto da framework
+ Se você precisa passar uma classe, ao invés de passar “meu.grande.e.maravilhoso.pacote.MinhaClasse” você poderia passar MinhaClasse.Class, o que deixa
o código ainda mais legível.

XML
+ Maior independência de implementação da framework
+ Não exigem que a pessoa que for configurar conheça Java. (Lembre-se novamente dos coitados dos programadores novatos, programadores de outras liguagens, e dos webdesigners!)
- Muito verboso

Anotações
+ Menos verboso
+ Aprendizado rápido
- O código fica “sujo” com a configuração. Ou seja, não é possível ter duas configurações diferentes para o mesmo código.
Isso mata a reutilização!

Conclusão
TENHA DÓ DE SI MESMO! NÃO-CAIA-EM-MODISMOS! Não é por que XML é usado para configurar uma framework que todas as demais devem proceder da mesma forma. Anotações são um recurso a mais. Mas não deveriam se tornar configuradores universais!

vamorim:

Conclusão
TENHA DÓ DE SI MESMO! NÃO-CAIA-EM-MODISMOS! Não é por que XML é usado para configurar uma framework que todas as demais
devem proceder da mesma forma. Anotações são um recurso a mais. Mas não deveriam se tornar configuradores universais!

Cara, só não entendi se vc aprovou ou não o Mentawai? :lol:

Gostou do esquema de ActionManager então?

Arquivos XML também podem ser muito fáceis de editar, basta ter uma DTD ou esquema bem feito com muitos comentários. Se você pegar um bom editor de XML e carregar a DTD do Hibernate 3 ou a do Struts vai ver que praticamente todos os nós tem um comentário, tem um valor default e até mesmo os possíveis valores que aquele nó pode assumir.

É óbvio que não é a mesma coisa de usar o analizador léxico do Eclipse, mas é toma lá da cá, você ganha em não ter que compilar e perde em ser mais fácil fazer uma coisa errada.

Sobre o caso das anotações poderem não ser reutilizadas, é realmente um problema, mas será que depois que o cara botas todas as anotations pra usar o Hibernate e o sistema estiver funcionando, ele vai trocar tudo pro iBatis? Eu duvido muito. Já a validação tem que levar um bocado de coisas em consideração, ela vai validar os objetos de negócio? Vai ter um “objeto form” como no Struts e ele vai ser validado?

Porque se a validação estiver nos objetos de negócio, temos um problema. O que aconteceria se o sistema tiver que ser portado pra desktop?

saoj:

vamorim:

Conclusão
TENHA DÓ DE SI MESMO! NÃO-CAIA-EM-MODISMOS! Não é por que XML é usado para configurar uma framework que todas as demais
devem proceder da mesma forma. Anotações são um recurso a mais. Mas não deveriam se tornar configuradores universais!

Cara, só não entendi se vc aprovou ou não o Mentawai? :lol:

Gostou do esquema de ActionManager então?

Oops! O alerta não foi prá vc.

Foi para a galera em geral lembrar que ainda não existe um Configurator Tabajara que resolve todos nossos problemas.

Então quando usar qual :?:

Na minha opinião, se o que é configurável só faz sentido para programadores Java, use Java. Exemplo, frameworks MVC.

Se o que vai ser configurado é de mais alto nível, use XML. Exemplo, uma tabela com nomes e emails dos desenvolvedores do sistema (para ser usada na área de créditos) …

Se a classe que vai vai ser configurada só faz sentido para a framework em questão, use Anotações. Exemplo: PrevalentSystem (ou o equivalente no Space4J :mrgreen: ).

No caso do Mentawai, acho que o ideal é usar Java mesmo, já que o foco são os usuários iniciantes.

Só lembrando de outras possibilidades para configuração, dependendo do caso:
:arrow: Linguagens de Script (Groovy, BeanShell, etc…)
:arrow: Banco de dados
:arrow: Prolog (maravilhoso para regras de negócio complexas e mutáveis!)
:arrow: Criar uma nova linguagem e um novo compilador ou interpretador.

Esse “vc ganha em não ter que compilar” me incomoda. Vc não tem que restartar o web server para as mudanças no XML fazerem efeito ??? Caso positivo então dá no mesmo!

Pode validar o que vc quiser, já que vc está no controle, e com o Java como arma. Quer validar num pau só um objeto Profile, crie um ProfileRule e faça a festa. Só fiquei aqui pensando em como seria a mensagem de erro: uma só para o objeto não validado ou uma para cada atributo do objeto não validado ??? Como o Struts faz ??? Depois tenho que ver isso!

“Maurício”:

Porque se a validação estiver nos objetos de negócio, temos um problema. O que aconteceria se o sistema tiver que ser portado pra desktop?

A validação é totalmente desacoplada num filtro a parte!

saoj:

Maurício Linhares:

É óbvio que não é a mesma coisa de usar o analizador léxico do Eclipse, mas é toma lá da cá, você ganha em não ter que compilar e perde em ser mais fácil fazer uma coisa errada.

Esse “vc ganha em não ter que compilar” me incomoda. Vc não tem que restartar o web server para as mudanças no XML fazerem efeito ??? Caso positivo então dá no mesmo!

Hoje, com Struts, WebWork, Tapestry e todos os outros frameworks que eu testei, sim, voce precisa pelo menos reiniciar o contexto pra que a configuracao seja recarregada.

Nada te impede, no entanto, de bolar um servletzinho do tipo /app/mentawai/reloadConfiguration que fica la durante o desenvolvimento (e sai de cena quando a app vai pra producao).

Foi um errinho ou existe diferenciação entre os conceitos de desenvolvimento e produção?

Uma sugestão:

Mudar o ValidationFilter para:

ValidationFilter<T extends Enum>

E seu arquivo assim:

Vinci, vc nao quer gente na internet inteira mandando o seu framework recarregando a configuracao, quer?

Existe uma diferenca enorme entre ambientes de desenvolvimento e ambientes de producao na maioria dos projetos que eu vejo por aqui - enquanto qualquer um pode chegar no console e reiniciar a maquina de desenvolvimento, fazer isso nas de producao provavelmente garante a sua demissa. As configuracoes do SO e do application server sao bem diferentes tambem (para dar enfase a performance ao inves dos logs e relatorios de erros ou debugging)

Foi um errinho ou existe diferenciação entre os conceitos de desenvolvimento e produção?

O tratamento de uma aplicação em desenvolvimento não é diferente do tratamento de uma aplicação em produção não?

vamorim:

Uma sugestão:

Mudar o ValidationFilter para:

ValidationFilter<T extends Enum>

E seu arquivo assim:

Vinci, to por fora de generics. Como ficaria a classe HelloValidationFilter.java usando esse esquema que vc propos?

enum V {
    FIELD_REQUIRED_ERROR,
    INVALID_USERNAME_LENGTH,
    INVALID_AGE,
    INVALID_PASSWORD_LENGTH,
    PASSWORD_DOES_NOT_MATCH;       
}

public class HelloWorldValidator extends ValidationFilter<V>{
    public void initValidator() {
        
        add("username", new RequiredFieldRule(), V.FIELD_REQUIRED_ERROR);
        add("username", new StringRule(6, 30), V.INVALID_USERNAME_LENGTH);

        add("age", new RequiredFieldRule(), V.FIELD_REQUIRED_ERROR);
        add("age", new IntegerRule(18, 50), V.INVALID_AGE);

        add("password", new RequiredFieldRule(), V.FIELD_REQUIRED_ERROR);
        add("password", new StringRule(4, 20), V.INVALID_PASSWORD_LENGTH);
        add("password", new EqualRule("password", "passconf"), V.PASSWORD_DOES_NOT_MATCH);

        add("passconf", new RequiredFieldRule(), V.FIELD_REQUIRED_ERROR);    }
}

Para um HelloWorld, parece até que assim não melhora muito. Mas que for usar no dia a dia certamente nota a diferença.