No Struts, por que tem que mapear os campos do formulário num xml, quando uso DynActionForms?

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? :smiley:

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[/quote]

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…

[quote=carneiro]
Bem, então o Struts requer que eu mapeie os dynactionforms simplesmente por opção, e não por alguma necessidade?

tsc tsc[/quote]
Não precisa mapear dynaactionforms, pode usar actionforms

A questão não criticar, mas sim aprender, pois estou desenvolvendo um framework mvc.

De qualquer forma, valeu pelas participações

[quote=LuizAvila][quote=carneiro]

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…
[/quote]

Exemplifique, cite trechos de código onde isso seria simplificado pra gente…[/quote]

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á… :slight_smile:

Era essa a simplicidade que eu tava procurando… :shock:

:mrgreen:

[quote=saoj]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á… :slight_smile:

[/quote]

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á,

[quote=Maurício Linhares]
Uau! Quer dizer que você tem um getUsuario() na sua Action? E que o Usuario que ele retorna tem um getNome()? Uau![/quote]

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:

[code]

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; 
} 

}[/code]

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 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[/quote]

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.

[quote=Maurício Linhares]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.[/quote]

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.

[quote=Maurício Linhares]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.
[/quote]

Velocity é mais rapido que JSP pra renderizar. :stuck_out_tongue:
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:

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