Opiniões: Validação

Assuntos Gerais Agile
#1

Eu não me dou bem com XML. Abaixo ilustro como o Struts faz validação com 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>

Gostaria da opinião de vcs sobre o esquema de validação do Mentawai.

http://mentawai.lohis.com.br/validation.jsp

Não é muito mais fácil ???

#2

Opa

Bom, tirando que sempre vai precisar recompilar a app pra qualquer alteração minima e que isso não tem nada de diferente da validação anterior, não achei mais fácil não, já que é pra enfiar tudo a base da marreta pra dentro do código, pelo menos coloque a coisa realmete mais simples, pq não fazer isso com anotações? Faça uma comparação dessa mesma validação com o genesis, essa vai ser boa :mrgreen:

T+

#3

Ahhh, tb é bom lembrar que com Struts e Commons Validator vc pode escolher entre fazer a validação no cliente ou no servidor… Não que essa seja a melhor alternativa, mas pode. :wink:

ps.: Esse código me fez lembrar dos ActionForm do Struts, isso vai crescendo, crescendo quando tu menos espera booom… :cry:

T+

#4

Temos opiniões conflitantes.

E isso não significa que um está certo e o outro errado. Ambos podem estar certos.

O que eu tenho a te dizer é que:

  1. Recompilar não é ruim, muito pelo contrário, te permite pegar erros cedo. Quem me dera se eu pudesse “compilar” o XML. Como não posso acabo tendo que restartar o meu servidor N vezes devido a erros bobos.

  2. Quando vc modifica o XML da maioria dos frameworks, vc precisa também restartar o servidor.

  3. XML gigante acontece no Struts, que é mundialmente conhecido como um pouco de Java no meio de muito XML.

  4. Não sei se vc percebeu, mas as validações são por formulários, logo o código não vai ficar muito grande não, pelo contrário. Vc terá um filtro de validação para cada formulário seu. Totalmente desacoplado e clean.

  5. Validação no client-side é legal mas não fundamental. Já validação no server-side é obrigatorio. Quer brincar com client-side use o AJAX.

  6. Anotações é legal, mas tem tres desvantagens sobre a solução atual: é 1.5 e requer 1.5 e nem todo mundo tem um tomcat 1.5 disponível; e apesar de legal não possui toda a flexibilidade de código Java e principalmente ACOPLA A VALIDAÇÃO numa action, não ter permitindo reutilizá-la em outra action. Pensa assim: dois formulários iguais em actions diferentes. tu vai ter que repetir as anotações em ambas. Com a minha solução basta vc reutilizar o filtro de validação.

  7. Como eu documento XML ??? Como eu consulto a documentação de XML ??? Não me venha com DTD! Código Java tem JavaDoc, e não há nada melhor do que JavaDoc.

  8. Muitas pessoas acharam a solução 10 vezes mais fácil que struts e 5 vezes mais fácil que webwork. Mas não tenho certeza disso. Se vc tem alguma sugestão para tornar esse código ainda mais fácil dê um exemplo, isto é, ajude! Esse é o bom do projeto open-source, todo mundo pode ajudar e dar opinião. Criticar é fácil, mostrar trabalho é outra coisa… :slight_smile:

#5

O Tiger vai completar um ano e ainda não aprendemos a usar os seus recursos… :roll:

#6

saoj, da uma olhada no Webwork, ele tem muitos recursos legais q talvez tu poderia tb implementar algo parecido no Mentawai. :joia:

#7

[quote=“saoj”]Temos opiniões conflitantes.

E isso não significa que um está certo e o outro errado. Ambos podem estar certos.

O que eu tenho a te dizer é que:

  1. Recompilar não é ruim, muito pelo contrário, te permite pegar erros cedo. Quem me dera se eu pudesse “compilar” o XML. Como não posso acabo tendo que restartar o meu servidor N vezes devido a erros bobos.

  2. Quando vc modifica o XML da maioria dos frameworks, vc precisa também restartar o servidor.
    [/quote]

Bom, se você recompilar aí sim vai precisar reiniciar o servidor. Mas não sei qual servidor é esse que precisa ser reiniciado se algum XML for alterado, em 80% dos casos não precisa, no máximo, reiniciar o contexto, note o contexto e não o servidor.

Isso é questão de gosto mesmo. Eu não gosto muito do Spring justamente pq ele tem XML de mais, mas acho que acabar com os XMLs não é uma idéia inteligente.

Sim, eu entendi isso, assim como no caso que eu citei, dos ActionForm, é uma validação pra cada formulário também.

É por isso que muita gente odeia o Eclipse, pois pensam: Desenhar Interface não é fundamental.

Depende, se os formulários são iguais, pq você teria dois deles e apenas uma validação? não seria melhor ter só um formulário e sua validação?

Concordo, por isso eu sugeri de você usar anotações.

[quote=“saoj”]
8) Muitas pessoas acharam a solução 10 vezes mais fácil que struts e 5 vezes mais fácil que webwork. Mas não tenho certeza disso. Se vc tem alguma sugestão para tornar esse código ainda mais fácil dê um exemplo, isto é, ajude! Esse é o bom do projeto open-source, todo mundo pode ajudar e dar opinião. Criticar é fácil, mostrar trabalho é outra coisa… :-)[/quote]

Opa, solução mais fácil que o Struts é fácil, todas. :grin:

Eu acho que você não entendeu a minha réplica a este post, você postou com um titulo de “opiniões”, eu apenas dei a minha opinião. Eu não quis descer o pau no teu projeto ou desmerecer o teu trabalho não, eu nem cheguei a ver teu projeto, eu apenas comentei sobre a sua forma de validação. E sobre projetos open source, não precisa me ensinar como trabalhar, um dia você vai ver que o legal é realmente ajudar, e não sair re-re-re-re-re-re-criando a mesma coisa.

T+

#8

Eu gosto sempre de tentar melhorar as coisas. As vezes recriar é a única solução. Como eu posso ajudar o Struts a ser melhor sem recriá-lo ??? Não dá para tirar o XML, não dá para desacoplar do container, ou seja, não dá para mudar a arquietura inicial.

Acho que eu não fui feliz quando falei que vc deveria sugerir melhoras e não só criticar. E vc tb não foi feliz com a afirmação acima.

Então ficamos quites. Bola pra frente e te convido humildemente a conhecer o projeto e se achar merecedor colaborar já que vc gosta de ajudar projetos já desenvolvidos. :wink:

#9

:hippy: :hippy: que isso Sergio, não queria que a discussão entrasse nesse mérito, acho que não estamos aqui pra discutir nossas idéias de desenvolvimento e nossas filosofias… :ypisc:

#10

voltando a falar sobre validações…
Então, eu também penso que validação por action seria melhor.
Acho mais provável uma action ter vários forms do que um form ficar trocando de action.
E sempre uma action poderá ser reaproveitada.

Quanto mais você abstrair da view as funcionalidades do sistema, melhor será, mas reaproveitável será a sua view

#11

[quote=“microfilo”]voltando a falar sobre validações…
Então, eu também penso que validação por action seria melhor.
[/quote]

Pode ser. Então quando o 1.5 já tiver se espalhado, podemos fazer alguma coisa com annotations.

Eu ainda prefiro usar um ValidationFilter para separar totalmente uma coisa da outra, ou seja, separar o modelo de negócio (action) da validação dele (filter).

#12