Actions do WebWork - como voce faz?

Front-end
#1

E ai pessoal,

No WebWork os dados que serao exibidos na view ficam como atributos da Action (ModelDriven ou nao), certo? Se eu quiser mapear diversas actions para uma mesma classe Action com metodos diferentes eu vou jogar tudo como atributos da Action mesmo?

Exemplo:

[code]public class AlunoAction extends ActionSupport {

/** Lista utilizada pelo metodo list(). */
private List list;

/** Modelo utilizado para visualizar/salvar dados. */
private Aluno aluno;

/** Carrega a listagem de alunos. */
public String list() {
    ...
}

/** Carrega os dados de um aluno. */
public String load() {
    ...
}

/** Salva os dados de um aluno. */
public String save() {
    ...
}

}
[/code]

Como voces fazem? Existe outra forma de fazer isso? Ou a maneira mais elegante eh separar em classes Actions diferentes?

Marcio Kuchma

#2

eu faço bem assim mesmo…, operações para salvar, deletar, listar tudo numa Action…

Quando for Actions mais complexas, ai separa as coisas…

ModelDriven é opção sua, eu particularmente não uso…

#3

So resista a tentacao de deixar toda a logica de negocio nas Actions :wink:

Rafael

#4

Siga o conselho do Rafael. Não fiz isso 6 meses atrás e me arrependo amargamente hoje :expressionless:

#5

[quote=Rafael Steil]So resista a tentacao de deixar toda a logica de negocio nas Actions :wink:

Rafael[/quote]

com certeza :slight_smile:

#6

Ueba, vamos la…

[quote=ricardolecheta]eu faço bem assim mesmo…, operações para salvar, deletar, listar tudo numa Action…

Quando for Actions mais complexas, ai separa as coisas… [/quote]

Entao. Isso que eu estava vendo. Acho que fica “poluido” fazer isso no WebWork. No Struts ficava tudo restrito ao metodo em questao (pois o proprio programador tem que jogar os dados na request). Ja no WebWork fica mais simples, porem nesse caso nao acho legal. Se eu fizer uma Action CRUD para uma determinada entidade vou ter uma lista, um Integer (id), uma classe de modelo e sei la mais o que, como atributos da Action. :smiley:

Por enquanto estou inclinado a fazer Actions pequenas e dividir em mais pacotes.

A unica vantagem do ModelDriven eh nao precisar referenciar o nome completo do atributo na view? Se eu posso colocar um bean na Action com os gets/sets certinhos e utilizar bean.at1, bean.at2, etc, na view, existe alguma vantagem adicional para usar ModelDriven?

Marcio Kuchma

#7

Opa, relate sua experiencia negativa para podermos debochar, ops, aprender com ela. :mrgreen:

Rolou uma discussao interessante ha um tempo atras sobre isso por aqui, a respeito de utilizar Actions do WebWork como camada de negocios (claro, isso em sistemas simples). Alguem ai guardou o link?

Marcio Kuchma

#8

modelDriven é mais para sintaxe, para ficar mais bonito sei la… é como vc disse, acessa direto o attributo e pronto…

a única diferença é na hora da validação… no Action-validation… vc nao faz mais: user.nome is required… talvez model.nome is required ?? mas ai fica feio…

Entao vc propaga a validação para o model, tipo User-validatin.xml e faz “nome is required”…

e na Action-validation.xml vc só chama a validação do model:

    <field name="model">
        <field-validator type="visitor">
            <param name="appendPrefix">false</param>
            <message />
        </field-validator>
    </field>
#9

Me arrependo amargamente pois, quando formos mudar o framework mvc, imagine a pequena dor de cabeça de refatorar todas as actions :expressionless:

“Ah, mas a action é como se fosse uma classe qualquer.”

Não concordo com isso. A classe que conversa diretamente com a view sempre tem alguns vários detalhes que um Comando qualquer não teria.

#10

Eu nao tenho nada a adicionar no topico, entao vou fazer o de sempre: desviar ele do assunto. :mrgreen:

Pra discutir melhor a ideia de como vcs estruturam as Actions, como vcs TESTAM as malditas? Eu costumo fazer assim:

public void testUserActionShouldListUsers() { // inventa um mock DAO que sempre retorna 2 ou 3 usuarios // executa a action.list() passando o DAO // verifica que ela tacou 3 usuarios no request }

public void testUserActionShouldChangeUserPassword() { // inventa um mock DAO que retorna um usuario qualquer por ID // executa a action.changePassword() passando o DAO // verifica que ela mudou a senha do benedito }

and so on, and so forth… e voces? :smiley:

#11

faço assim tb, mas eu não sou tão criativo…

gostei do retorna 2 ou 3… eu fazia com o proprio DAO, ai retorna tudo da base… ou teria que usar algo como dbunit e uma base vazia, pra popular os testes antes…

mas usar um mock dao que só retorna o que vc quer tb nao é nada ruim… :smiley:

#12