Qual a diferença do WebWork (WW2) para o Struts ?
Não trabalho com Struts e nem com o WebWork, mas pelo que andei lendo e que o pessoal anda comentando, ambos parecem fazer a mesma coisa.
O WebWork tem algum diferencial em relação ao Struts ?
Quando usar um e quando usar o outro ?
Ouvi falar a respeito do Struts que ele só seria o controller © do MVC e que ele tem algumas tag libs para o View, mas no geral o Struts só funcionaria como controller da aplicação.
Gostaria de saber até onde isso é verdade.
Quando que uma aplicação realmente segue o modelo de MVC ?
View com Velocity + Controller com Struts/WW2 + Model com Hibernate/EJB ?
Se minha aplicação utiliza-se somente jsp/html + struts usando servlet controller e classes java (java beans) para persistência e regras de negócio posso dizer que segue o modelo MVC ?
alguma alma caridosa para dar uma esclarecida ? 
valeu !
bem, teve uma discussao por icq e mensagens sobre isso, onde o CV postou sobre o webwrok e eu coloquei mais algumas vantagens que achei lega. segue:
----- cv:
O maior ponto contra o Struts, na minha opiniao, foi a decisao de arquitetura dos caras em fazer Actions recicladas em um pool. Isso caga na produtividade. Comparativo rapido:
Struts:
Voce cria a Action CadastrarUsuario, o FormBean CadastrarUsuarioBean (ou configura um xmlão pra fazer o dynaformbean), mexe no struts-config.xml.
Na sua Action, vc nao pode ter variaveis, pq ela tem que ser threadsafe, e, em teoria, o seu form bean nao deveria conter regras de negocio.
WebWork:
Voce cria a Action CadastrarUsuario, mete nela um getUsuario() que te retorna um objeto de negocio, e usando as tags do WW (ou nao) manipula ele dentro do seu Velocity, JSP, relatorio do Jasper, whatever. Mete a definicao da Action no XML, e diz quais os interceptors que vc quer ver aplicados nela (coisa que nem existe no Struts).
A cada request, uma nova instancia da sua Action vai ser criada, e ela eh, na verdade, o form bean… a diferenca eh que ela nao esta acoplada ao HTTP, nao esta acoplada à J2EE, e, pra falar a verdade, nao precisa nem estar acoplada ao teu use-case… dah pra fazer uma Action soh que serve pra um sistema inteiro, por exemplo, e dizer no XML “pra essa acao, chame o metodo String foo() throws Throwable na Action”. Dah pra ter, entao, uma action assim:
public class GerenciarUsuario extends ActionSupport implements UsuarioAware, UsuarioDAOAware {
private Usuario usuario;
private UsuarioDAO dao;
public void setUsuario(Usuario u) {
this.usuario = usuario;
}
public Usuario getUsuario() {
return usuario;
}
public void setUsuarioDAO(UsuarioDAO dao) {
this.dao = dao }
public UsuarioDAO getUsuarioDAO() {
return dao;
}
public String adicionar() throws Throwable {
try {
dao.adicionar(usuario);
return SUCCESS;
} catch(DAOException e) {
addError(getText(e.getMessage()));
return ERROR;
}
}
public String remover() throws Throwable {
try {
dao.remover(usuario);
return SUCCESS;
} catch(DAOException e) {
addError(getText(e.getMessage()));
return ERROR;
}
}
public String alterar() throws Throwable {
try {
dao.alterar(usuario);
return SUCCESS;
} catch(DAOException e) {
addError(getText(e.getMessage()));
return ERROR;
}
}
}O WebWork tem um framework de validacao e conversao de tipos que o Struts tah longe de ter ainda, e a linguagem de expressoes do WW dah um cacete na JSTL em todos os sentidos
Ah… isso sem nem falar muito na implementacao de inversao de controle do WW2… notou as interfaces UsuarioAware e UsuarioDAOAware que eu implementei? Bom, entao… advinha quem gerencia as implementacoes dessas interfaces, e chama os setters pra mim?
-----------------paulo:
Entao duas as vantagens que o Carlos citou:
1-) Inversao de controle pelos Awares
2-) As Actions sao criadas per request, o que acaba com seu problema de Thread unsafe.
Ele deu pouca atencao pro negocio que o webwork INDEPENDE totalmente de ser web. Isto eh, voce nao ve UM SOH httpservletrequest ou response. Voce soh trabalha com beans. Ateh para a session tem como voce nao colocar a mao nela!!! (eh soh usar a ivnersao de controle e setar que voce quer aquele objeto PER SESSION)
O codigo fica LINDO da sua business logic: tem o que voce precisa (setters), o que voce fornece (getters), e a logica no String execute(). Repara o codigo do Villela. Nao tinha como ser mais simples.
Eh simplesmente ANIMAL.
------continuando eu:
o que o CV quis dizer com que o struts caga na produtividade, eh que voce tem de ficar guardando as cosias em session, e toda aquela tralha que eh trabalhar diretamente com servlets acontece nas actions do struts.
tem gente que reclama que uma (ou mais) action eh sempre instanciada a cada request, falando de performance. performance de inicializacao de objetos simples eh mito em java, isso eh da epoca do java 1.2 ou anterior… a produtividade REALMENTE eh maior com o webwork, onde voce nao pensa do jeito servlet de ser…
Paulo, valeu !
em relação ao struts só funcionar como controller da aplicação, isso é correto ?
Nao, pq o Struts tb tem taglibs pra view, entre outras coisas… o Struts (e o WebWork, e o Maverick, e o …) sao frameworks MVC. Eles nao fazem, em teoria, nenhuma das partes do MVC - eles so te ajudam a fazer e separar as coisas 
thanks cv !
espera aí, deixa eu ver se eu entendi 
, vou fazer um comparativo com o struts pq nao conheço o WW.
no struts-confix.xml vc definiria actions para criar, deletar e pesquiar um usuario. Provavelmente isto seriam classes Actions diferentes…
no webwork eu uso uma classe apenas e digo:
para cadastro o ususario é o metodo X…
para deletar é o método Y…
E ele reutiliza sempre a mesma classe ? é isso?
puxa! :shock:
bem, realmente ele tem coisas que o struts nao tem. Esse lance de Interceptors é legal, e o IoC é incrível
mas… vocês também nao podem afirmar que o struts estraga a performance porque faz pool das Actions
Nao dissemos que ele estraga a performance pq faz pool de actions - mas colocar as actions num pool estraga a produtividade, pq por causa disso vc precisa de FormBeans e toda aquela papagaiada
Não sei se é isso que vc quer dizer, mais colocar vários métodos em uma Action no Struts é possível na versão 1.1 extendendo org.apache.struts.actions.DispatchAction no lugar de org.apache.struts.actions.Action e colocando no struts-config.xml o parametro “parameter” onde vc vai atribuir o nome do método que vc deseja chamar na action. exemplo:
<action attribute="funcionario"
name="manterfuncionarioForm"
parameter="acao"
scope="request"
path="/funcionario"
type="br.com.meuprojeto.struts.meumodulo.action.PreencherFuncionarioAction"
validate="false">
<forward contextRelative="true" name="cadastrar" path="page.funcionario.cadastrar"/>
<forward contextRelative="true" name="consultar" path="page.funcionario.consultar"/>
</action>Sendo assim o link funcionario.do?acao=cadastrar vai chamar um método cadastrar na minha action (é lógico que vc deve implementar esse método na sua action)
Richardson,
testei aqui o que você colocou e funcionou
bom saber!
Legal ricardolecheta :!:
O numero de Actions do projeto diminuem muito usando dessa maneira, por exemplo aqui estamos dividindo as Actions por cadastro. Para evetuar as operações de um usuário como cadastrar/editar, excluir e consultar usamos uma unica Action chamada ManterUsuarioAction com esses métodos de cadastrar , excluir e consultar. E criamos mais uma Action para ajudar na composição do formulário tanto na hora do cadastro quanto na edição, chamamos essa Actin de preenchedora, então criamos a Action PreencherUsuarioAction com os métodos necessários.
Então para cadas operação de cadastro temos 2 actions no lugar de ter um monte de EditarUsuarioAction, ExcluirUsuarioAction …
Estou procurando melhores maneiras de trabalhar com Struts, no momento é assim que estou fazendo.
OBS: Se vc quer colocar IoC no Struts da uma olhadinha nesse site http://struts.sourceforge.net/saif/index.html :!:
o que seria loC ?
eu estava procurando material sobre o webwork e achei este:
caso interessar a alguém: