10 motivos para preferir JSF

e já viram alguém fazer

class ClasseDeModelo extends ActionForm ???

e depois manda essa classe pro banco

JavaEvangelist Membro desde: 28/08/2003 16:52:00 Mensagens: 452 Offline

Bela Guilherme !!!!

Por esses motivos, dei uma de louco e fiz o meu próprio framework ... nada de ActionMapping. Simplicidade, um log decente e estilo. tags bonitas e claras. e ainda funciona em pocket pc. Sem contar com o assistente, que mapeia via navegador, os campos com o banco de dados.

Estou ajustante alguns detalhes, mas toh louco pra divulgar pra galera ...

Garanto que promete !

Luiz Aguiar wrote:Pelo menos o JSF está com a Sun, e fará parte da especificação J2EE 5.0, que teoricamente as chances de continuidade são trilhões de vezes maiores do que qualquer proposta que eles possam querer fazer com o Struts.

Muito pelo contrário, o Shale é feito especificamente para trabalhar com JSF. Ele foi criado para servir de controler em uma aplicação JSF.

Luiz Aguiar wrote:
Agora, que o treco é nojento, ah isso é mesmo... huahuauha o coitado do Craig devia ta querendo se vingar de alguém e deu o Struts de presente... hehehe

Se não fosse o Struts, seria outro. Ninguém faz perfeito na primeira vez. Se não fosse pelo conhecimento que o Struts gerou (tanto nos seus acertos como nos seus erros) provavelmente não veríamos WebWork, Spring MVC, Mentawai e o diabo a quatro por aí

Maurício Linhares wrote:Se não fosse o Struts, seria outro. Ninguém faz perfeito na primeira vez. Se não fosse pelo conhecimento que o Struts gerou (tanto nos seus acertos como nos seus erros) provavelmente não veríamos WebWork, Spring MVC, Mentawai e o diabo a quatro por aí

Concordo plenamente! O problema é que devido ao fato desses frameworks serem difíceis de aprender, o cara depois não quer mudar quando algo novo e melhor aparece.

Agora se algo é fácil, simples e não-complicado, então vc pode brincar sem envolvimento emocional. E se algo melhor aparecer vc não ficará resistente a mudança.

saoj wrote:

Maurício Linhares wrote:Se não fosse o Struts, seria outro. Ninguém faz perfeito na primeira vez. Se não fosse pelo conhecimento que o Struts gerou (tanto nos seus acertos como nos seus erros) provavelmente não veríamos WebWork, Spring MVC, Mentawai e o diabo a quatro por aí

Concordo plenamente! O problema é que devido ao fato desses frameworks serem difíceis de aprender, o cara depois não quer mudar quando algo novo e melhor aparece.

Agora se algo é fácil, simples e não-complicado, então vc pode brincar sem envolvimento emocional. E se algo melhor aparecer vc não ficará resistente a mudança.

Não acho que seja só isso Sérgio, é claro que preguiça e falta de vontade pesam muito na hora de migrar uma aplicação. Em um projeto de pesquisa da universidade que eu trabalhei a mais de um ano, o pessoal ainda usava Tomcat 4.1. Dia desses me chamaram pra dar uma aulinha sobre Hibernate pra a galera que tá lá hoje e ainda usam o Tomcat 4.1, simplesmente porque o administrador disse que "não tem necessidade de mudar".

A cultura das pessoas e da empresa contam muito na hora de se fazer uma mudança dessas. Na empresa que eu estou estagiando por exemplo, eu migrei toda a persisistência que era no Hibernate 2.1.8 pra o Hibernate 3.0.5 em apenas um dia, sem causar nenhum problema a ninguém, tudo continuou funcionando normalmente. Agora estou migrando do Struts pro Spring e mais uma vez ninguém me proibiu, eles só querem a coisa funcionando

Mas eu trabalho sozinho, o código é meu e o legado também. Em uma grande empresa, com times de desenvolvimento, eu provavelmente não poderia chegar pro pessoal e dizer "vamo todo mundo atualizar tudo e migrar tudo pro Spring". A maioria das empresas tradicionais tem "metabolismo de tartaruga" e seguem na cultura de que "time que tá ganhando, ninguém mexe". Se a aplicação tá rodando beleza com o Struts, porque mudar?

Se a aplicação tá rodando beleza com o Struts, porque mudar?

Se a aplicação tá rodando legal, não se deve mudar mesmo. Tb acho isso.

O problema é começar um projeto do zero hoje usando Struts. Sei lá. Acho que a maioria concorda que existem frameworks melhores no mercado.

Mas é o que vc falou. O medo da mudança. O medo do novo. E o apego ao seguro, isto é, ao que já se dominou.

Pessoal,

aproveitando essa discussao, e como vou comecar um novo projeto. Queria saber se vocês aconselham utilizar o webwork ao invés do Struts? O projeto é pequeno, sao 2 analistas e 1 programador, que vai durar uns 3 meses(previsto).

A equipe já conhece struts e pela complexidade não tem necessidade de usar nada parecido com o Spring. A idéia é usar ou o Struts (ou outro) talvez o ww, juntamente com o hibernate.

Moderador Membro desde: 21/02/2003 16:19:19 Mensagens: 1647 Offline

Fabrício Cozer Martins wrote:sao 2 analistas e 1 programador, que vai durar uns 3 meses(previsto).

O problema de projetos de software não é sua duracao durante o desenvolvimento e sim sua manutencao.

Usar struts é um tiro no pé na manutencao, dificil de manter com testes, propenso a ter lixo ao inves do codigo. etc. etc.

Fabrício Cozer Martins wrote:Pessoal,

aproveitando essa discussao, e como vou comecar um novo projeto. Queria saber se vocês aconselham utilizar o webwork ao invés do Struts? O projeto é pequeno, sao 2 analistas e 1 programador, que vai durar uns 3 meses(previsto).

A equipe já conhece struts e pela complexidade não tem necessidade de usar nada parecido com o Spring. A idéia é usar ou o Struts (ou outro) talvez o ww, juntamente com o hibernate.

Porque não tem necessidade de usar "nada parecido com o Spring"?

Spring e Hibernate são um casamento perfeito

Pra uma olhadinha no Spring MVC tem esse tutorial simplíssimo: Spring MVC Step-by-step

This message was edited 3 times. Last update was at 17/08/2005 23:29:19

Ah, um exemplo bem besta de um DAO que eu tenho aqui:

Não abri nem fechei sessões nem transações aqui, tudo é resolvido pelo próprio Spring e as transações são definidas declarativamente, não no código

A resposta eh: nao tem resposta

Todos os frameworks fazem a mesma coisa. Ate mesmo o struts se dominado vai ter a mesma complexidade de manutencao que outros.(arrisquei agora hein.,...)

O negocio eh escolher um framework que voces estejam dispostos a aprender. Aprendam em uma semana o basico e decida se vai utilizar ele....

Que tal?

ps: trabalhar com object eh coisa feia... .cade generics daniel?

java 5 tae....

Alias sobre essa historia toda de mudanca, a palestra da Linda Rising esse fds sera sobre esse assunto. COmo mudar o padrao tartaruga das empresas

Do mesmo jeito que muita gente prefere pagar uma cópia do Windows por preguiça (medo) de tentar usar o Linux, com os frameworks é a mesma coisa... é difícil fazer muitas vezes quem conseguiu se dar bem com o Struts, tentar ver além do horizonte... mesmo que saiba que existem opções "melhores".

Como o Guilherme disse, fazer todos fazem... mas toda tecnologia se aprimora e avança... e isso, nem todos conseguem seguir.

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

SAOJ wrote: Se a aplicação tá rodando legal, não se deve mudar mesmo. Tb acho isso.

Será mesmo? Se eu tivesse tempo disponível, e o código estivesse uma porcaria, eu mecheria! Os testes unitários estão ai para estes tipos de situações!

Guilherme Silveira wrote:Ate mesmo o struts se dominado vai ter a mesma complexidade de manutencao que outros.(arrisquei agora hein.,...)

Essa realmente vc arriscou! Acho que sempre é válido dominar bém o framework que vc está trabalhando, mas a colocação do smota já mostra o principal motivo que faz com que o Struts não seja manutenível como os outros frameworks...

smota wrote: Usar struts é um tiro no pé na manutencao, dificil de manter com testes, propenso a ter lixo ao inves do codigo. etc. etc.

IMHO, testar as actions do webwork é fácil pacas, enquanto no struts a complexidade é pelo menos 2x maior!

Abraços!
Thiago

saoj wrote:

Se a aplicação tá rodando beleza com o Struts, porque mudar?

Se a aplicação tá rodando legal, não se deve mudar mesmo. Tb acho isso.

Ela está funcionando agora, mas quem garante que ela vai continuar a funcionar quando houver uma grande mudança nas regras de negócio pra se fazer?

Se você não tem confiança no que está fazendo (por falta de testes automatizados) e anda escrevendo gambiarras pra lidar com falhas da sua ferramenta (como são os Entity Beans e CMP na especificação EJB), mesmo que a coisa "funcione", a migração deve ser um caminho certo, porque um dia a bomba estoura.

E como já diria Murphy:

Uma das várias leis de Murphy wrote:Se várias coisas podem dar errado, elas vão dar errado na pior hora e na pior sequencia possível

Acresentando um roteiro que sobre a tecnologia

http://www.jspolympus.com/JSF/JavaServerFaces.jsp

Notícias, artigos e o maior fórum brasileiro sobre Java