Há alguma versão estável do struts 2? Pergunto isso, pois as versões que venho testando (2.0.14 e 2.2.1.1) são um monte de bugs e total perda de tempo tentando corrigir esta montueira de erros o que impede o aprendizado deste framework.
Se o struts continuar por este caminho (cheio de erros) em breve será abolido por grande parte das empresas. Sinceramente, quero que este dia chegue logo! 
Usei esta mesma versão há algum tempo e nunca tive problemas.
Quais os bugs?
Que dificuldades está tendo?
Já pensou em trocar por Spring?
Estou utilizando a versão 2.0.14, de 70 arquivos .jar, apenas 5 são de fato necessário para que o struts funcione. Para que inflar o framework adicionando dependências que só servem para gerar todo tipo de exceções imáginárias e problemas possíveis.
Segui um tutorial muito didático para criar um helloworld com struts 2, porém a mensagem não é exibida na página, o que poderia estar faltando?
Segue os códigos:
JSP
[code]<%@ page language=“java” contentType=“text/html; charset=ISO-8859-1” pageEncoding=“ISO-8859-1”%>
<%@ taglib uri="/struts-tags" prefix=“s”%>
web.xml
[code]<?xml version="1.0" encoding="UTF-8"?>
struts2
struts.xml
[code]<?xml version="1.0" encoding="UTF-8"?>
[/code]
Action
[code]package action;
import com.opensymphony.xwork2.ActionSupport;
public class HelloWorld extends ActionSupport{
private static final long serialVersionUID = 1L;
private String mensagem = "Olá mundo!";
public String execute() throws Exception {
this.setMessage("HelloWorld com o Struts2!");
return "SUCCESS";
}
public String getMensagem() {
return this.mensagem;
}
public void setMessage(final String message) {
this.mensagem = message;
}
}[/code]
hello.xml
[code]<?xml version="1.0" encoding="UTF-8"?>
Olá, Marcio.
Também lhe fiz essa mesma pergunta em outro tópico (quais bugs você enfrenta?). Bug todo framework tem, mas o Struts2 (principalmente a partir da 2.1.x) está muito estável. Aqui do TJ/Pa, por exemplo a maioria dos sistemas roda em produção com esse framework sem bugs relevantes. Outros sistemas de uso nacional do poder judiciário também adotam esse framework.
Agora, uma coisa que se deve evitar é o uso do dojo plugin, esse sim é pra lá de bugado! Prefira o Jquery Plugin que não é distribuido junto da versão oficial mas é muito bom.
Claro que esse framework tem alguns problemas de produtividade por não conter ferramenta “arrasta e solta” na criação de telas e por ter uma documentação que não é das melhores.
Conforme ceomentei anteriormente, segui um tutorial bem didático para aprendizado do struts 2.
O único problema é que a mensagem não é exibida.
OBS: postei os códigos anteriormente neste mesmo post.
Alguém poderia da uma olhada e ver o que pode estar errado?
Desde já agradeço a ajuda.
O exemplo desse link está muito bom, mas poderia ficar bem menor. Várias configurações lá poderiam ter sido subtituidas pela CoC do Struts 2, dispensando inclusive o uso de quase todas as anotações.
E com relação ao teu código (de fato, feito usando a configuração mais complexa possivel com Struts2, mas não é culpa sua) para você ver a mensagem deve chamar a url:
http://sethost://HelloWorld
E no JSP seria mais fácil fazer ${mensagem} do que <s:property value=“mensagem”/> para ver sua mensagem.
Sobre
Quase todo framework quando baixado de forma “tradicional” é assim. Se for baixar via Maven, pega-se só o necessário para teu projeto.
É bom saber disso! Procuro ir melhorando os exemplos jyoshiriro, então você tem alguma referência sobre isso para me passar?
Dê uma olhada nos outros posts, qualquer crítica/sugestão sua seria muito bem vinda!
Flw! :thumbup:
Eu sugiro ler a apostila da caelum
Com eles eu aprendi Struts 2 facilmente.
Algumas dicas para reduzir o código no código do blog:
@Namespace(value = “/carro”) -> se a Action estivesse no sub pacote “carro” do mesmo pacote onde está, isso ficaria configurado automaticamente. Dai essa anotação poderia ser omitida.
@Action(value = “lista”, results = @Result(name = “ok”, location = “/carro/lista.jsp”)) -> Poderia ficar apenas @Action(“lista”)
Para tanto, teu JSP deve ficar na pasta “WEB-INF/content/carro” e se chamar “lista.jsp”. Ah, e deve botar “return SUCCESS” e não ‘return “ok”’ na Action (vide OBS abaixo)
OBS: Melhor sua classe Action estender direta ou indiretamente ActionSupport. Não ligue para os que dizem que isso não é boa prática (se for, pra que OO e herança? ¬¬’). Assim, além de métodos muito valiosos como addActionError, addActionMessagem você ganha as contantes SUCCESS, ERROR, INPUT e LOGIN. Parece bobagem, mas ajudam imensamente. Assim, ao invés de usar palavras como “ok”, “erro”, você usa as constantes, evitando assim erros de digitação.
Mas qual seria a diferença entre utilizar ${mesnsagem} e <s:property value=“mensagem”/> não teria a mesma função?
A diferença é escrever menos mesmo
Sei disso, mas acho interessante manter a anotação pois através dela o uso do namespace fica em evidência, o que pode ajudar quem não tem conhecimento muito aprofundado da ferramenta.
[quote=jyoshiriro]@Action(value = “lista”, results = @Result(name = “ok”, location = “/carro/lista.jsp”)) -> Poderia ficar apenas @Action(“lista”)
Para tanto, teu JSP deve ficar na pasta “WEB-INF/content/carro” e se chamar “lista.jsp”. Ah, e deve botar “return SUCCESS” e não ‘return “ok”’ na Action (vide OBS abaixo)[/quote]
Também cheguei a fazer dessa forma, mas não gostei; tive alguns problemas quando tentei usar essa convenção junto com a anotação, fiquei com a impressão de que é ou um ou outro. E pessoalmente, prefiro ter no código o direcionamento das ações (nas anotações), apesar de que no Struts isso é feito de forma pobre.
Costumo estender ActionSupport justamente por causa das validações, mas quando não uso, não o faço pelas constantes. Tudo bem que retornar SUCCESS faz com que seja desnecessário ter o name na anotação @Result, mas ao meu ver isso foi feito de forma muito tosca, pois ao invés dele responder apenas para essas Strings especificas, poderia simplesmente seguir como convenção que com apenas um @Result (é assim no post), não seria necessário o parâmetro name independete do retorno. E assim sendo, retornar a String se faz inútil. Como não é assim, ou você usa essas constantes e apenas elas, ou não as usa, pois se misturar o código deixa de seguir um padrão simples, então optei por não usá-las.
Mas acho que já fugi muito da discussão inicial. jyoshiriro, agradeço suas sugestões e discordo de algumas (quase todas :XD: ), não porque acho que estão erradas, mas basicamente porque mesmo escrevendo um pouco mais, creio que deixa o código mais legível e consequentemente mais simples.
Vlw! :thumbup:
Ok. O legal desse framework é justamente isso: Há várias opções.
Eu prefiro escrever o menos possível de configuração (filosofia CoC), mas se você prefere deixar as configurações mais explicitas, é uma escolha sua. É questão de gosto mesmo
Oque é CoC? :B