Struts 2 x JSF: A Hora da Verdade

Olá Pessoal,

Eu não tenho a intenção de levantar uma discussão sobre quem prefere Struts 2 ou JSF. Mas sim propor uma discussão dirigida a alguns tópicos que considerei relevantes das duas abordagens. Por favor, sugiram outros tópicos também.

Por favor, se possível, ignorem o Struts 1 neste tópico, pois se não vamos cair nos mesmo prós e contras de discussões passadas.

  1. Como o JSF só trabalha com POST, é impressão minha ou não tem como evitar que uma tela ou formulário seja re-processado ao pressionar F5? Em frameworks MVC comuns, a gente dá um redirect após um form ser processado e evita isso. E no JSF?

  2. No JSF é nos arquivos .jsp que se define qual metodo irá processar um determinado botão por exemplo. Isso me obriga a vasculhar os arquivos .jsp para entender quem chama quem, etc. Agora, se eu olhar apenas o faces-config.xml eu não consigo saber qual “view” usa qual “managed bean”. Pode ser que não tenha muito a ver, mas pelo struts.xml eu consigo saber qual classe esta relacionada a qual JSP. Isso não seria uma vantagem do struts 2? Pois seria mais fácil um novo membro da equipe compreender a estrutura do sistema.

  3. No JSF, as validações de formulários tem que ser colocadas diretamente no arquivo .jsp. No struts 2 eu crio arquivos XML para cada formulário e tem como eu reaproveitar algumas validações, sem sair repetindo código. Mais uma vez, isso não é uma vantagem do struts 2? Pois é facilmente identificável quais são as validações de todo o sistema.

  4. Tentei fazer um simples link no JSF, e me assustei, pois os conceitos são totalmente diferentes. Ai fica um comentário: algo muito genérico e configurável, num determinado ponto pode dar flexibilidade, mas em outro pode ser diminuir a produtividade para os casos mais comuns.

  5. No JSF, se eu quiser iniciar um processamento a partir de um URL, sem ter que chamar um arquivo .jsp é possível? No struts 2 bastaria criar uma simples action.

  6. Todo mundo fala mal do struts 1. Agora o struts 2 os Actions não precisam herdar mais nenhuma classe. Não precisa se criar uma classe para cada formulário. Muito parecido com o JSF. Estou certo?

  7. O que vocês acham do futuro do struts 2? (Por favor, não confundam com o struts 1)

Bom pessoal, por favor enviem suas opiniões e me avisem se escrevi alguma besteira.

T+

Claudiney

nao é bem assim, boa parte disto é pouco conhecimento da tacnologia, da uma olhada neste post do meu blog.

Olá

[quote=ccalixto]…
7. O que vocês acham do futuro do struts 2?[/quote]

Pelo que conheço dele, acho o Struts2 muito melhor do que o Struts1. Se trabalhasse com aplicações WEB, e começasse um projeto novo, incluiria o Struts2 dentre os frameworks a avaliar para uso no projeto.

Quanto ao JSF vejo muitas vantagens mas também ainda não é o último biscoito do pacote.

[]s
Luca

Deve ter um jeito de fazer JSF trabalhar com GET. Se bem que para a maioria dos formulários, o melhor é post mesmo. No JSF vc vai dar um redirect após o processamento tb, acredito eu…

JSF é orientado a componentes, daí tem dessas coisas. Se for usar JSF porque vc quer component-based, pense em usar Wicket, Click, Rife ou Seam.

Validação em XML não é legal tb… Talvez o JSF faça isso porque a validação dele ocorre no client-side? Não sei…

Ou vc sabe BEM JSF ou vc não é produtivo. Mais complexo que JSF acho que só o Tapestry. Isso não é bom…

Esse negócio de não ter que herdar action é bobeira na minha opinião. O problema do Struts1 era FormBeans, acoplamento com servlets, mar de XML (continua no Struts2) e ausência de filtros/interceptos.

Colocar o WW como Struts2 foi uma bela jogada de marketing. Tem tudo para crescer. Pontos negativos na minha opinião: mar de XML. bagunça de annotations, documentação ruim, não-objetiva e não-clara, etc.

Para entender os pontos a cima, vc pode dar uma olhada aqui.

É difícil comparar JSF com Struts, porque são filosofias diferente. Minha opinião é que se o seu projeto tiver uma interface muito rica, usar muito AJAX e Web2.0, talvez (não tenho certeza disso mas é o que parece) vc estaria melhor de JSF do que de Struts.

O que o pessoal tem contra XML ?
Na minha opinião, o XML atende bem no que se trata de configuração.
Até mesmo pela natureza “declarativa”.

Não é por menos que a maioria dos aplications server usa XML na sua configuração, o ANT usa XML, o jasper usa XML.

[quote=okara]O que o pessoal tem contra XML ?
Na minha opinião, o XML atende bem no que se trata de configuração.
Até mesmo pela natureza “declarativa”.

Não é por menos que a maioria dos aplications server usa XML na sua configuração, o ANT usa XML, o jasper usa XML.
[/quote]

Pois é.
Agora imagina um sistema imenso, cheio desses xmls. XML pra isso, aquilo, aquilo outro… Complica.
XML é legal, mas muitas vezes o excesso acaba atrapalhando.

Olá Urubatan,

Seu blog tirou algumas dúvidas minhas, eu vi que essa parte do re-processamento com F5 era falta de conhecimento meu mesmo. Pois um simples resolveu este problema.

Quanto aos parâmetros GET, vi que o jeito que eu havia testado é a forma utilizada mesmo, basta definir no managed bean a notação

<managed-bean> ... <managed-property> <property-name>codigo</property-name> <value>#{param.codigo}</value> </managed-property> ... </managed-bean>

E depois no link informar o parâmetro

<h:commandLink action="#{meubean.metodo}" value="#{meubean.usuario.nome}"> <f:param name="codigo" value="#{meubean.usuario.codigo}" /> </h:commandLink>

Todavia, é uma forma diferente de se fazer, de início acho um tanto trabalhoso fazer isso para um simples link com parâmetros GET. Mas talvez, quando eu ganhar mais vivência com JSF eu possa entender melhor essas vantagens.

Agora, eu gostaria de saber a sua opinião a respeito dos meus comentários 2 e 3 ?

Valew :smiley:

É verdade eu acabei de descobrir isso heheheh

Na verdade eu penso em usar JSF pois estou começando um sistema novo, sem cronograma muito apertado e ele terá que ser mantido por um bom temmmmmmmmmmmmmmmmpo.

Pelo que vi as validações podem ser no lado cliente e no lado servidor. De qualquer forma, eu gostaria que alguém que conhece bem de JSF nos falasse algo sobre o motivo dessas validações ficarem no .JSP. Será que isso não fica meio misturado? (Pergunta de leigo)

Uma questão que me veio agora: e a integração do JSF com o Spring está confiável? Isso me parece algo que tornaria bem produtivo o desenvolvimento. Eu vi algumas mensagens no forum.

Realmente é muito XML. Eu passei por isso no Struts 1. Mas até que funcionava, só que realmente é uma dor de cabeça.

Agora uma coisa que ninguem comentou ainda. Pode ser falta de conhecimento meu, mas por favor o que vocês me dizem deste comentário meu:

Valew…

Bom, eu prefiro colocar a action no botão do que no form, por que em quase todas as páginas tem mais de um botão, e cada um deles vai sempre fazer uma coisa diferente, se eu não puder colocar a action no botão, vou ter que ficar fazendo IFs dentro da action para saber o que fazer …

e quanto a saber qual view usa qual managed bean, basta definir algum padrão …

da uma olhada nos meus posts sobre spring-annotation+jsf
eu criei um padrão de trabalho para JSF, onde todas as views referentes a um managed bean, ficam dentro de um diretório de mesmo nome deste managed bean …

Existem alternativas também, no spring-annotation, eu pluguei o hibernate-validator no JSF, ai eu configuro as validações com anotações nos beans.

por padrão as validações são apenas server-side, mas se por exemplo tu colocar o ajax4jsf junto, e colocar um a4j:support dentro do campo a ser validado, a validação passa a ser feita via ajax sem nenhuma linha de javascript …

bom, esta é a maneira default, mas nada impede de se fazer assim:
<h:outputLink value=“home.jsf?id=#{obj.id}”> …

funciona igual

ou então dependendo do caso (este ultimo exemplo não funciona dentro de um dataTable por exemplo, pois a EL do JSP é executada na fase “restore view” e a EL do JSF é executada na fase “render response”)
texto

cara, por causa da sua pergunta criei um tópico: Stripes
http://www.guj.com.br/posts/list/58640.java

Pessoal,

A respeito deste meu comentário, o que vocês tem a dizer?

Eu nem sei se com desenvolvimento via JSF isso é preciso, mas isso era muito comum em aplicações MVC tradicionais. Primeiro chama-se uma URL que faz um processamento e depois define que JSP será exibido. Pensem que esta URL seria a entrada do sistema. :?:

Uma outra coisa, qual implementação do JSF vocês tem utilizado? MyFaces? 8)

Valew

T+++

Um coisa que colocaria tambem como discussao é as ferramentas para trabalhar com Struts2 e JSF . Pelo que sei, até agora não existe nenhum plugin/extension para usar o struts2, mas para jsf existem várias opçoes, não é ? quais voces utilizam e recomendam ?

Herrera

[quote]Um coisa que colocaria tambem como discussao é as ferramentas para trabalhar com Struts2 e JSF . Pelo que sei, até agora não existe nenhum plugin/extension para usar o struts2, mas para jsf existem várias opçoes, não é ? quais voces utilizam e recomendam ?
[/quote] Na questão de extension para trabalhar com o Struts 2.0.6 GA ele ainda está em processo de merge, mais já existem plugins “beta” em desenvolvimento tanto para o Eclipse como para o NetBeans e no atual estágio dos frameworks o desgaste e a preocupação maior é no processo de DI, modelo e controle de transações no blog do Urubatan Jardim, tem uma discussão sobre produtividade bem interessante.
Se vc. usar o " Eclipse -SDK 3.3M6 + WTP 2.0M6" ou do outro lado o NetBeans 5.5.1 Beta + alguns modules , vc. já tem como trabalhar e bem com o JSF ou Struts 2.0.6 GA. Acho que estamos esquecendo que um framework é completamente diferente um do outro a comecar pelas actions/managed-bean, isso sem contar que se vc. criar seus templates de maneira organizada ira ter mais produtividade que um monte de parafernalia que em sua maioria somente cerve para atrapalhar .
sds.

PS…[quote]criar seus templates de maneira organizada ira ter mais produtividade que um monte de parafernalia que em sua maioria somente cerve para atrapalhar . [/quote]Criar seus próprios templates de maneira organizada vc. tera mais produtividade que um monte de parafernalia que em sua maioria somente serve para atrapalhar .

[quote=WilliamSilva][quote]Na questão de extension para trabalhar com o Struts 2.0.6 GA ele ainda está em processo de merge, mais já existem plugins “beta” em desenvolvimento tanto para o Eclipse como para o NetBeans …
[/quote]

onde é possivel encontrar esses plugins ‘beta’ para eclipse ?

Herrera

Quanto ao futuro do struts 2, é difícil dizer, mas acho que já é uma das alternativas ao jsf que têm maior visibilidade. Não estou com isso dizendo que é melhor do que outras: echo, stripes, tapestry, wicket são todos grandes frameworks. BTW vc deve ter reparado que eu citei esses frameworks em ordem alfabética, para não revelar outras preferências e melindrar alguns :wink: É impressionante como as pessoas valorizam essa questão de frameworks web!

Quanto ao uso de xml, embora eu tenha começado a estudar o struts 2 agora, posso dizer que ele também permite o uso de convenções em lugar de configuração, o que torna o uso do xml quase irrelevante, sem que para isso tenhamos que usar annotations para casos triviais. Ah, e a validação pode ser feita em classes, como já era feita no webwork (também achei horrível usar xml para validação).

Quanto ao apoio de ferramentas, ainda vou avaliar esses plugins. Não estou com tanta pressa assim pois, ainda que reconheça sua eficiência para desenvolvimento rápido de sistemas de baixa complexidade, sinceramente tenho dúvidas se elas apresentam a melhor abordagem para o desenvolvimento de sistemas em geral. Mas essa é uma outra discussão …

Há diversas maneiras de se fazer a mesma coisa no struts 2, que parece um canivete suisso :wink: Isso é indicado pelo pessoal do struts como sua grande força mas é ao meu ver sua principal fraqueza, pois dificulta a compreensão do framework, ainda mais se considerarmos a baixa qualidade da documentação. E certamente esse estilo do pessoal que veio do webwork deve assustar o pessoal acostumado ao antigo struts.

Um colega meu no trabalho, com grande experiência em webwork, está fazendo algumas experiências bem interessantes com o struts 2, e está bastante entusiasmado. A única coisa que ele tem notado é que o uso do ajax torna a questão da arquitetura mais complexa.