Estou com dúvida se devo criar uma Action para cada formulário.
Na verdade preciso fazer um cadastro em duas tabelas. Por exemplo, suponha que preciso cadastrar caminhões e em outro momento pessoas. Eu poderia criar uma Action default, por exemplo Add.java, que poderia identificar o ActionForm e fazer o seu trabalho. Está certo fazer assim ou crio uma Action para cada cadastro? Qual a maneira correta, mais “limpa”?
Depende da complexidade dos seus formulários…mas nada impede de vc receber algo do seu form q identifique qual ação será tomada pela Action e delegar tal ação para uma outra classe que retorne pra vc o ActionForward correto depois de ter processado tudo…
vc pode em vez de sua action extender action, extender DispatchAction,
com isso vc pode passar como parametro na url o metodo a ser executado, não precisando testar p/ saber.
mas como se trata de casos bem diferentes, acho o ideal criar duas actions.
de uma olhada na doc doc struts sobre DispatchAction, p/ ver se te atende.
Estou aprendendo Struts e gostaria de saber se é normal criar várias Actions, encher meu struts-config.xml de <action>… não sei, acho isso um pouco redundante, desorganizado. Na verdade é q gosto de enxugar as coisas.
A propósito esse post acima foi eu q postei, saiu anonymous pq deve ter vencido minha sessão e simplesmente postou.
[quote=Luiz Henrique Coura]Estou aprendendo Struts e gostaria de saber se é normal criar várias Actions, encher meu struts-config.xml de <action>… não sei, acho isso um pouco redundante, desorganizado. Na verdade é q gosto de enxugar as coisas.
A propósito esse post acima foi eu q postei, saiu anonymous pq deve ter vencido minha sessão e simplesmente postou.
[/quote]
particularmente eu prefiro separar, principalmente se se referem a entidades diferentes.
p/ mim uma action generica, mas com 30 if’s, não é legal, fica dificil de manter e extender funcionalidades.
acho mais facil manter o struts-config.xml com 50 actions do que uma action cheia de condições, o xml é mais organizado.
mas é uma questão pessoal de quem modela o sistema.