Arquivo Discussoes de Programacao e Tecnologia Olá amigos,
Tenho usado o WebWork e dado uma olhada em outros frameworks mvc, e, apenas por curiosidade, queria saber porque o Struts requer que eu mapeie os campos do formulário que eu quero usar com os DynActionForms.
Eu não vi o porque isso precisa ser feito…
Valeu pessoal!
A pergunta é, porque isso não deveria ser feito? O que é que tem de errado?
Quer pq quer. Pq nao injeta os dados diretamente. Sabe-se lá pq não fizeram assim…
Pra que ser simples se pode ser complicado? :mrgreen:
Vai dizer que o jeito que o webwork faz (injetando os dados) não é mais facin, simplezin, docin e deixa a criançada mais feliz? 
Quer pq quer. Pq nao injeta os dados diretamente. Sabe-se lá pq não fizeram assim…
Pra que ser simples se pode ser complicado? :mrgreen:
Vai dizer que o jeito que o webwork faz (injetando os dados) não é mais facin, simplezin, docin e deixa a criançada mais feliz? :D
Olha, se ele não quer “mapear” usando DynaActionForm, é só colocar um Map pra receber todas as propriedades. Não vai ter que descrever nada no XML.
Ainda não vejo qual é o problema de se definir as propriedades do DynaActionForm.
O problema é que poderia ser feito de um jeito mais fácil, mais simples.
Como disse o Zeh, é bem mais simples no ww, e em outros frameworks também…
Bem, então o Struts requer que eu mapeie os dynactionforms simplesmente por opção, e não por alguma necessidade?
tsc tsc
Ele requer que você mapeie porque se não mapear, como é que o sistema vai saber quais são as propriedades do DynaBean? Ele vai adivinhar?
Se o seu ponto é criticar o Struts por isso ou por aquilo, diga logo, não enrole não, mas arranje outro motivo, porque esse tá furado :mrgreen:
Exemplifique, cite trechos de código onde isso seria simplificado pra gente…
Bem, então o Struts requer que eu mapeie os dynactionforms simplesmente por opção, e não por alguma necessidade?tsc tsc
A questão não criticar, mas sim aprender, pois estou desenvolvendo um framework mvc.
De qualquer forma, valeu pelas participações
O problema é que poderia ser feito de um jeito mais fácil, mais simples.
Como disse o Zeh, é bem mais simples no ww, e em outros frameworks também…
Exemplifique, cite trechos de código onde isso seria simplificado pra gente…
No WW nao é preciso isso, mas tem que manter o padrao de nome na view pra ele se achar.
Mas com certeza eu prefiro criar um input com name “usuario.nome” e na minha action ter um getUsuario e no usuario um setNome do que ter que ficar mapeando.
Na boa o pessoal so ve a facilidade quando usar. Experimente WW por 2 horas, so nao me culpe se depois disso resolver jogar o Struts longe :mrgreen:
]['s
Uau! Quer dizer que você tem um getUsuario() na sua Action? E que o Usuario que ele retorna tem um getNome()? Uau!
Você pelo menos imagina o que venha a ser um ActionForm no Struts companheiro?
Ou melhor, você sabe o que é um DynaBean?
Acho que estamos com um sério problema de comunicação aqui. Um DynaBean, é um objeto que recebe os atributos em tempo de execução, quando você fizer um set(“nome”,“nome”) nele, ele ganha um atributo “nome”, que se você tentar acessar usando a classe PropertyUtils, não vai dar uma “java.lang.NoSuchMethodException”. Quando você coloca a propriedade lá, é como se ele virasse uma classe com um getNome() e um setNome().
Como o Struts não tem como adivinhar quais são as propriedades do objeto (assim como o WebWork não adivinha), você tem que dizer quais são as propriedades do DynaBean pra que ele possa colocar elas lá.
Agora, se você não quer usar um DynaBean, pode usar um ActionForm normal, e colocar nele as propriedades que você quizer e elas não vão ter que ser mapeadas no arquivo de configuraçlão do Struts.
Eu digo denovo, antes de falar, pelo menos saiba do que você está falando.
Maurício,
O que vc achou do VOFilter do Mentawai? Dá uma olhada em: http://mentawai.lohis.com.br/filters.jsp
Não consegue a mesma coisa com muito mais simplicidade ???
Não estou afirmando não! Se vc discorda me dá umas dicas para eu melhorar a coisa lá… 
Era essa a simplicidade que eu tava procurando… :shock:
:mrgreen:
Maurício,O que vc achou do VOFilter do Mentawai? Dá uma olhada em: http://mentawai.lohis.com.br/filters.jsp
Não consegue a mesma coisa com muito mais simplicidade ???
Não estou afirmando não! Se vc discorda me dá umas dicas para eu melhorar a coisa lá…
Não tô conseguindo abrir a página não :shock:
E sobre a simplicidade Zeh, leia o resto ou veja a documentação que você vai entender. Os DynaBeans servem pra você não ter que compilar uma nova classe só pra “carregar” dados, você define as propriedades dela no XML e a validação também no XML, sem escrever nenhuma linha de código.
Mais simples do que isso, só se o Struts advinhasse as propriedades pra você :lol:
Olá,
Uau! Quer dizer que você tem um getUsuario() na sua Action? E que o Usuario que ele retorna tem um getNome()? Uau!
Tu sabe pra que serve isso? Esse comentario realmente era necessário?
Eu falei do atributo na action pois no WW nao precisa de mapeamento, este é feito diretamente na view, ou seja, no nome do input.
<input type="text" name="usuario.nome" />
Quando tu executar tua action:
....
public class UsuarioAction extends ActionSupport {
Usuario usuario;
public String getUsuario() {
return usuario;
}
public String setUsuario(Usuario usuario) {
this.usuario = usuario;
}
public String execute() throws Exception {
System.out.println("Nome "+ usuario.getNome());
return SUCCESS;
}
}
Teu atributo nome da classe usuario ja vai estar preenchido, nao precisando de mapeamento adicional.
Sobre o restante dos comentarios, tu perdeu uma otima oportunidade de ficar em silencio. :wink:
Eu digo denovo, antes de falar, pelo menos saiba do que você está falando.
Eu tambem te pergunto isso, tu entendeu o que eu queria dizer quando dei o exemplo do WW?
]['s
Kd o CV pra catequizar mais um? :mrgreen:
]['s
Kd o CV pra catequizar mais um? :mrgreen:
]['s
Precisa não, já conheço o WebWork, só não uso porque a documentação ainda é terrível, a validação do lado cliente ainda dá muito trabalho e os caras ainda não resolveram como é que ela vai ficar. Tô esperando o 2.2 pra ver como é que tudo vai andar.
O problema aqui é que os dois frameworks tem uma abordagem difernente para os formulários HTML. Um action form do Struts não é um objeto de negócio, como esse usuário que está no Action do WW, ele é “o formulário” HTML e é ele que o Struts vai validar. É por isso que existe o DynaBeanActionForm, pra que você não tenha que criar uma classe só pra “carregar” as informações de um lado pro outro.
São abordagens diferentes para o mesmo problema.
Na minha opiniao a ducmentacao ja foi terrivel, nao é otima, mas ja é suficiente. O wiki ajuda muito tambem.
Verdade, acho que validacao no lado do cliente so veio com a versao 2.1.7, apesar que até agora eu nao tive problemas com ela. Bom a 2.2 sem comentarios, pelo que ta por vir ja da pra imaginar que sera uma a mudanca.
O problema aqui é que os dois frameworks tem uma abordagem difernente para os formulários HTML. Um action form do Struts não é um objeto de negócio, como esse usuário que está no Action do WW, ele é “o formulário” HTML e é ele que o Struts vai validar. É por isso que existe o DynaBeanActionForm, pra que você não tenha que criar uma classe só pra “carregar” as informações de um lado pro outro.São abordagens diferentes para o mesmo problema.
Com certeza, mas como eu prefiro a simplicidade, sou mais WW. Nao so pelo maneira do mapeamento que tem uma quantidade menor de XML para manter e configurar, mas principalmente pela integracao dele com Velocity e pela facilidade de TTD, alem de outras coisinhas que ajudam muito.
Bom eu conheco Struts, no trabalho usamos Oracle ADF que usa Struts, mas fora isso ja parei de matar foquinhas. :mrgreen:
]['s
Eu só queria que a documentação do WebWork fosse sequencial, eu já tentei começar a ler o PDF duas vezes e nas duas vezes tive que ficar correndo de um lado pro outro, porque eles começam em um canto e vão terminar em outra página que não tem “nadas haver”.
Vai fazer um ano que eu comecei a estudar Java (quando estava pagando Orientação a objetos aqui na faculdade) e já fazem uns seis meses que eu comecei a mexer com o Struts, não me arrependo nem um pouco, sempre me serviu muito bem no que era o serviço dele. Hoje estou começando a integrar ele com o Spring e se eu mudar, provavelmente vai ser pro Spring MVC mesmo, que parece estar dando passos mais largos que o WW, principalmente porque o pessoal está pensando muito na integração com Faces.
Eu realmente fico com um pé atrás pro WW por causa desse “relacionamento” com o Velocity. Eu uso muito o Velocity pra fazer geração de templates pra emails, newsletters e essas coisas, mas não gosto de colocar eles no lugar de JSPs não, prefiro usar JSPs e to começando a mexer com o FreeMarker, que até agora está parecendo ser até melhor do que os JSPs, especialmente por dar suporte a EL e taglibs.
Mas você falou duma coisa, a quantidade de arquivos XML pra manter, em alguns exemplos do WW, o pessoal citava um arquivo XML pra validar cada Action, isso não vai dar um monte de arquivos XML não?
Pois é. Eu nunca parei pra ler a documentacao, sempre estudei pelos exemplos, prefiro estudar por codigo a ler um pdf inteiro.
Claro que ele atende, assim como servelts puro tambem atende e assim como JSP fazendo a parte de action tb atende, o problema é o como eles atendem.
Ainda nao parei pra estudar o MVC do Spring.
Eu realmente fico com um pé atrás pro WW por causa desse “relacionamento” com o Velocity. Eu uso muito o Velocity pra fazer geração de templates pra emails, newsletters e essas coisas, mas não gosto de colocar eles no lugar de JSPs não, prefiro usar JSPs e to começando a mexer com o FreeMarker, que até agora está parecendo ser até melhor do que os JSPs, especialmente por dar suporte a EL e taglibs.
Velocity é mais rapido que JSP pra renderizar. 
Tb estou vendo o freemaker, mas ainda nao comecei a usar.
Sim, mas sao arquivos de validacao, assim como tem os arquivos de i18n, nao seriam arquivos de configuracao e mapeamento de beans.
]['s
O site voltou! Tenta lá agora e me diz o que tu achou do VOFilter:
Não tô conseguindo abrir a página não
O site voltou! Tenta lá agora e me diz o que tu achou do VOFilter:
Gostei, é bem parecido com o que o WebWork faz, mas você poderia automatizar essa parte de preencher o objeto, tipo criando um filtro e pelas chaves do form ele já populasse o objeto com os parâmetros e executasse a validação, se fosse necessário.
Pois é, o seu argumento de menos arquivos XML não colou, pra usar o Struts com o Validator e o Tiles, eu só preciso de três arquivos. Os arquivos de validação do WebWork não contêm configuração? E eles contém o que?
Essa história de o Velocity ser mais rápido do que o JSP eu nunca vi ninguém comprovar e acho até difícil de acreditar, porque se o JSP é, na verdade, um Servlet, que é o nível “mais baixo” de uma aplicação web em Java, como é que o Velocity, que ainda vai ter que usar o Servlet pra poder enviar as informações vai ser mais rápido do que um JSP, que já é um servlet? Estranho isso.
E eu não vou nem comentar sobre a sua comparação do Struts com Servlets e JSP fazendo tudo.
Me explique qual é a mágica que faz o WebWork tão melhor do que todos os outros, porque eu vi o tópico do CV, assisti a apresentação de slides, li uns pedaços da documentação do WebWork e ainda não vi ele fazer nenhuma mágica, tem um mecanismo rudimentar de IoC (eu prefiro o Spring) e tem a ONGL, que realmente é muito interessante, especialmente pra definir a validação fora do código Java.
Acho que a única coisa que o WebWork tem que me chama atenção, é a possibilidade de fazer testes unitários nos actions fora do container, mas no fim termina não fazendo nem tanta falta assim, porque a lógica não fica dentro dos Actions do Struts mesmo, ele só faz reunir as informações e chamar os objetos responsáveis por executar ela e esses objetos podem ser testados fora do container normalmente.
Talvez, testar a validação fosse uma coisa interessante de se fazer, mas dá pra testar a validação do WebWork fora do container?
1 - Nunca subestime um bom cache
2 - Esse tipo de coisa so da pra saber fazendo testes de performance
3 - A view dificilmente vai ser o seu problema de performance de qqer forma 
A logica de negocios nao fica no controller. Ok, mas e os testes da logica de controle?
Hmm, nao sei - acho que da, mas pra ser sincero nunca usei a validacao do WW2. Smotaaaaaaaaaaaaaaa!
O VOFilter tenta pegar os parametros e injetar num objeto qualquer via reflection e setters. Logo se vc quer pegar um objeto User dos parametros de input vc usa new VOFilter(User.class). Dessa maneira a action vai receber um value object User devidamente preenchido pelo container/filtro. O VOFilter já vem com o mentawai no pacote org.mentawai.filter.
Uma outra possibilidade seria criar um InjectionFilter, para injetar esses parametros diretamente na action, como o WW faz. Vc definiria os parametros na action e criaria setters para eles. Daí esse filtro injetaria direto ali via reflection, sem problemas. Vou criar esse InjectionFilter e meter no pacote org.mentawai.filter.
O legal disso tudo é que vc pode criar filtros a vontade sem poluir a sua classe principal que é a action. Dessa maneira vc desacopla validação e um monte de outras coisas da sua action que fica limpinha.
Uma sequencia legal de filtros seria.
AuthenticationFilter :arrow: ValidationFilter :arrow: InjectionFilter or VOFilter :arrow: DBConnFilter :arrow: (Qualquer outro filtro)
O DBConnFilter tb é outro que é bem interessante: Ele se encarrega de abrir (ou pegar do pool) uma Connection de DB, disponibiliza para a Action e depois que action é executada ele fecha (ou retorna pro pool) essa conexão. Os filtros são mais legais ainda pois podem modificar uma action antes e após a sua execução. Com o DBConnFilter vc não tem mais que se preocupar em esquecer uma Connection aberta no seu código. O Filtro se encarrega de tudo e te entrega uma conexão limpinha como input.
Esse esquema de filtros (interceptors no WW) é realmente muito poderoso pois desacopla tudo no teu framework.
Estou estudando o esquema de validação com annotations. Parece legal, mas vejo dois problemas:
:arrow: É 1.5 e nem todos os servidores web já utilizam 1.5, o que limitaria o framework
:arrow: (Principal) Ele acopla a validação a uma action específica!
Usando um filtro para validação, vc pode usar esse mesmo filtro para actions diferentes, ou seja, se vc tem uma outra action no seu site que utiliza o mesmo formulário, vc pode usar o mesmo filtro, sem necessidade de duplicar o código. Se o seu formulário tem um campinho a mais, nada te impede de extender esse filtro para adicionar esse campo, ou criar um novo filtro de validação apenas com esse campo e encadear com o outro.
Pra concluir: To achando esse esquema de filtros maravilhoso !!!
O ValidationFilter vai validar diretamente o que vai vir pelo formulário HTML? Porque senão ele ia ter que ficar depois do InjectionFilter. Outra coisa que você deveria levar em consideração é a “transformação” de Strings em outros tipos simples, como Integers, Booleans e essas coisas, uma boa é usar os property editors, como o Spring:
http://java.sun.com/j2se/1.5.0/docs/api/java/beans/PropertyEditor.html
E mais uma coisa, eu to achando esse DbFilter meio “solto” por aí, especialmente porque lá na página do framework você diz que ele não vai fazer tudo. Eu, por exemplo, não usaria esse filtro, porque esse trabalho ficaria pra o meu framework de mapeamento objeto/relacional e eu provavelmente criaria um Filter (da API de servlets) pra fechar as conexões usando ThreadLocal, quando isso fosse necessário. Eu não acho que isso devesse estar aí não, ou pelo menos não como uma coisa “comum” do framework.
Maurício, sempre leio as suas defesas em pró do struts, hehe, eu uso ele ainda em alguns projetos, mas estou com um pé no WW, pq gostei muito da forma de se trabalhar, mas isso não vem ao caso.
Esse tópico está totalmente OFF-TOPIC já, então pq não fazer uma pergunta totalmente fora também? Eu vi vc falando que o WW tem um arquivo para validar cada action, no struts nós definimos tudo no validator.xml, cara, o meu tá enorme, tá difícil de mexer nele, tudo bem vc vai me dizer para modularizar tudo, mesmo assim eu teria alguns arquivos com mais ou menos uns 10 actionforms para serem validados, vc usa alguma ferramenta pra te ajudar a “se encontrar” no seu validator.xml ou modulariza até mesmo os módulos? sério cara, eu to me perdendo no meu struts-config e no validation… =o(
Eduardo,
O que vc achou do esquema de validação do Mentawai (http://mentawai.lohis.com.br/validation.jsp) sem XML e usando Java puro?
Maurício, sempre leio as suas defesas em pró do struts, hehe, eu uso ele ainda em alguns projetos, mas estou com um pé no WW, pq gostei muito da forma de se trabalhar, mas isso não vem ao caso.Esse tópico está totalmente OFF-TOPIC já, então pq não fazer uma pergunta totalmente fora também? Eu vi vc falando que o WW tem um arquivo para validar cada action, no struts nós definimos tudo no validator.xml, cara, o meu tá enorme, tá difícil de mexer nele, tudo bem vc vai me dizer para modularizar tudo, mesmo assim eu teria alguns arquivos com mais ou menos uns 10 actionforms para serem validados, vc usa alguma ferramenta pra te ajudar a “se encontrar” no seu validator.xml ou modulariza até mesmo os módulos? sério cara, eu to me perdendo no meu struts-config e no validation… =o(
Num tem muito jeito não :lol:
Eu não uso uma “ferramenta” pra me ajudar não, na verdade eu baixei novo Exadel Studio e vou começar a mexer nele agora, pelas features, ele faz um bocado de coisas, mesmo sendo gratuito.
Eu faço tudo usando o editor de XML do Eclipse mesmo e as vezes da muito trabalho de encontrar as coisas mesmo. Pra resolver isso, eu tenho o validation.xml (de cada módulo) cheio de comentários, tipo “ActionForms da administração de notícias”, “ActionForms do controle de usuários” e assim eu vou me achando dentro do arquivo. Mas eu realmente gostaria de poder dividir isso também, dentro de cada módulo.
Tá aí, vou pedir essa feature pro pessoal do Struts :mrgreen:
Sérgio, achei legal as tags no jsp, muito simples de entender, o esquema de validação está muito bom também, mas acredito que pra vc agradar a todos deveria possibilitar fazermos a validação em arquivos xml também, eu particularmente, apesar de estar achando ruim me encontrar no struts validator, por causa do tamanho do arquivo, gostei do esquema do WW que é um arquivo xml para cada action.
Eu já venho acompanhando as discussões sobre o seu esquema de validação e eu gosto de fazer isso em xml, porque posso mudar uma regra sem ter que compilar novamente, e ao meu ver, quando se trata de um sistema na web, a recompilação se torna um problema, por causa do deploy que temos que fazer com o arquivo .war
Mesmo assim, achei muito simples como a validação é feita no mentawai, simples no sentido de ser fácil para o desenvolvedor .
[]'s
Obrigado pelo comentário Eduardo!
Só não consigo assimilar a vantagem que vc alega para o XML.
Com XML tb temos que restartar o web server quando alteramos o XML, logo dá no mesmo. Com Java vc além de restartar tb é obrigado a recompilar. MAS COMPILAR É ALGO MARAVILHOSO. Te permite pegar erros cedo, concorda?
Quanto ao war, com XML vc tb não precisaria regerar o war ??? Claro que não, pois vc pode ir direto no XML e alterá-lo. Com Java tb! Vc pode ir direto na classe, alterá-la e recompilar apenas ela. O único pormenor que vejo é se suas classes estiverem dentro de um jar. Daí vc teria que regerar o Jar. Mas não sei se nesse caso tb os seus XML estariam dentro do mesmo jar, o que no final das contas daria no mesmo.
Concorda que esse argumento de “ter que recompilar o Java” não é muito forte? Sei lá, apenas a minha opinião. Se achar diferente tudo bem.
Hmm, nao sei - acho que da, mas pra ser sincero nunca usei a validacao do WW2. Smotaaaaaaaaaaaaaaa!
opa … dá sim, 100% e sem problemas. Os validadores são uma implementação de uma interface beeem simples. mais…
Posso ter perdido alguma coisa aqui … mas é possível fazer o gerenciamento para recarregar as configurações do XML quando o arquivo for atualizado, não é? (é sim :? )
Usando classes fica mais xarope pq vc suja a mão com os class loaders.
Verdade sérgio, é que eu não gosto de trocar apenas as classes que foram alteradas, acho que a chance de erro é grande, talvez por causa de uma dependencia a uma classe que não existia na outra, mas cada caso é um caso.
XML, vamos lá, eu poderia deixar para o carinha que faz os JSPs realizar as validações num arquivo XML, coisa que ele não iria conseguir trabalhando numa classe Java, ou até mesmo levar o software a uma reunião com o usuário e num certo momento ele perceber que um certo campo deveria possuir uma validação, coisa que ele não havia previsto anteriormente, isso é comum, poderia alterar facilmente, até mesmo o analista de sistemas, e demonstrar para o usuário no ato, e várias outras alternativas, eu ainda acho válida a idéia de realizar as validações no XML e não em classes.
Como alguem faz isso com WW ou Struts ??? É algo simples e fornecido pelo framework ou requer alguma pirueta do desenvolvedor?