Qual o problema do JSF?

Há...... E detalhe....

Se um dia escrever um artigo sobre Frameworks Web, o título seria o seguinte: "1001 Motivos para NÃO USAR JSF"

JWizard Membro desde: 23/02/2007 15:52:55 Mensagens: 2034 Offline

Acabei achando JSFUnit que talvez possa ajudar, alguém já usou??

dders wrote:Há...... E detalhe....

Se um dia escrever um artigo sobre Frameworks Web, o título seria o seguinte: "1001 Motivos para NÃO USAR JSF"

Poderia começar citando 10 dos seus 1001?

Oi galera.

Pelos comentarios notei que alguns de vocês tem bastante conhecimento e experiencia em JSF.

Estou estudando e tenho algumas dúvidas sobre a aplicação prática deste framework.

Gostaria de saber se vocês desenvolvem as páginas na "unha" ou estão utilizando os recursos drag and drop das IDEs.

Sou do tipo que gosta de fazer as coisas na unha mas as vezes esse negócio de arrastar e soltar me chama atenção por parecer mais produtivo.

No caso do JSF drag and drop vale a pena?

Olá Maurício, tudo bem?

Acho que temos que levantar alguns pontos que pelo visto tu não conhece... Antes de eu começar a argumentar, gostaria de saber: há quanto tempo tu trabalha com JSF? Tu já trabalhou com JSF 1.1 e JSF 1.2? Sabe a "real" da existência do MyFaces IMPL? E do Tomahawk/Sandbox/Trinidad/Tobago? E ajax4JSF? E principalmente, Facelets?

Antes de tudo, também queria dizer que acho que o JSF é limitado (o RI), tendo em vista que é a "primeira" versão dele. Quando o JSF saiu, até mesmo a SUN dizia que o RI servia somente como referencia mesmo, e que a melhor maneira de aproveitar o mesmo era utilizando suas impls (vide MyFaces) ou sua extesões (daí vem aquela porrada: richfaces, icefaces, adf faces, tomahawk (e outras impls do capeta que me esqueci o nome hehhe).

sobre as extensões (ajax e afins), tu pode ver que vários componentes do JSF já implementam isso automaticamente. Se você olhar por exemplo o Richfaces, ele facilitar um monte a tua criação de efeitos. Você não precisa tocar em Javascript pra fazer, por exemplo, um fade do script.aculo.us. Sandbox já implementa DOJO, só ver por exemplo o ModalPanel e o richtext edit.

Como citado anteriormente, parece que vocês estão julgando o framework como se ele fosse simplesmente ser como ele foi na primeira versão. JSF saiu por meados de 2002, 2003, não lembro, essa API do facelets não server somente para templating e no final das contas é um utilitário. Struts teve o tiles também, né? Tapestry desde que saiu teve templating? Spring-MVC também?

sobre isso:

Cadê ele mostrando o código do bean aonde essas capitais são transformadas em um array de SelectItem? Cadê o converter que vai transformar essas "capitais" em um objeto de negócio lá na aplicação? Ele não mostrou código nenhum ali, ele está é vendendo gato por lebre.

posso responder com isso

Fazer um <select> em JSF sem o Seam é uma penúria tão grande que eu não desejaria nem ao meu pior inimigo.

caramba, fazer isso

mata qualquer um do coração! meu deus, alguém me ajude. Realmente acho que a penúria deve ser em estudar...

e novamente

Programador ruim faz porcaria em qualquer lugar, mas o Seam incita o programador ruim a ser pior ainda, guardando informação demais na sessão, o que mata a escalabilidade de qualquer aplicação de tamanho razoável.

lhe sugiro a ler novamente a documentação do Seam e ver que a maneira que ele guarda as coisas na sessão não é uma maneira comum, já é otimizado e, além disso, você guarda na sessão se quiser. Não entendi a parte que tu cita que incita o programador ruim a guardar coisas na sessão. Dá uma lida aqui http://docs.jboss.com/seam/2.0.1.GA/reference/en/html/pr01.html que ele fala desse gerenciamento de estados e contextos que ele o fazer

mas uma coisa eu concordo contigo

Igual a tag do Seam, diga-se de passagem. De qualquer forma, não é padrão, mas deveria ser, praticamente tudo em JSF "puro" é sofrível.

também acho que falta algumas coisas, mas eu discordo complemanete que deveria vim tudo duma vez só. Não sei se você quis dizer isso, mas por exemplo, eu sou completamente a favor que haja várias implementações de bibliotecas porque muitas podem ser usadas pra aplicações específicas, cujo qual não haveria necessidade de ter quilos e quilos de componentes, efeitos ou novas operações. E sim, tudo no JSF puro é ruim, mas

Hoje em dia ninguém mais usa outra implementação de RI do JSF 1.2. Não há mais necessidade. Na época do JSF 1.1. o MyFaces se mostrava superior à impl do 1.1 (basta ver os erros de messages e afins), mas no JSF 1.2, basta usar as outras component suites que já faz com que o trabalho seja interessante, sem muitos erros e nem stress =D

Leozin wrote:Como citado anteriormente, parece que vocês estão julgando o framework como se ele fosse simplesmente ser como ele foi na primeira versão. JSF saiu por meados de 2002, 2003, não lembro, essa API do facelets não server somente para templating e no final das contas é um utilitário. Struts teve o tiles também, né? Tapestry desde que saiu teve templating? Spring-MVC também?

Tapestry tem templates desde sempre, o Sprinng MVC é view-agnostic, então você sempre pode usar tudo com ele (como freemarker, velocity, JSP puro, JSP com tiles ou qualquer um dos anteriores com Sitemesh). A falta de uma engine de templates padrão no JSF é uma briga muito antiga.

O maior problema do Facelets é que você não pode simplesmente chegar lá e colocar ele na sua aplicação, você tem que ter certeza de que todos os componentes que você está usando tem a configuração contendo os mapeamentos do Facelets, o que já foi um pé no saco logo quando o Facelets começou e só o Tomahawk tinha taglib.

Leozin wrote:

Cadê ele mostrando o código do bean aonde essas capitais são transformadas em um array de SelectItem? Cadê o converter que vai transformar essas "capitais" em um objeto de negócio lá na aplicação? Ele não mostrou código nenhum ali, ele está é vendendo gato por lebre.

posso responder com isso

Fazer um <select> em JSF sem o Seam é uma penúria tão grande que eu não desejaria nem ao meu pior inimigo.

caramba, fazer isso

<h:selectOneMenu value="#{person.continent}" required="true"> <s:selectItems value="#{continents.resultList}" var="continent" label="#{continent.name}" noSelectionLabel="Please Select..."/> <s:convertEntity /> </h:selectOneMenu>

mata qualquer um do coração! meu deus, alguém me ajude. Realmente acho que a penúria deve ser em estudar...

Você é cego ou está ignorando a afirmação sobre sem usar o Seam de propósito?

Leozin wrote:

Programador ruim faz porcaria em qualquer lugar, mas o Seam incita o programador ruim a ser pior ainda, guardando informação demais na sessão, o que mata a escalabilidade de qualquer aplicação de tamanho razoável.

lhe sugiro a ler novamente a documentação do Seam e ver que a maneira que ele guarda as coisas na sessão não é uma maneira comum, já é otimizado e, além disso, você guarda na sessão se quiser. Não entendi a parte que tu cita que incita o programador ruim a guardar coisas na sessão. Dá uma lida aqui http://docs.jboss.com/seam/2.0.1.GA/reference/en/html/pr01.html que ele fala desse gerenciamento de estados e contextos que ele o fazer

Uma maneira otimizada? Otimizada em quê? Ele faz compressão dos objetos?

Não há otimização nenhuma, ele bota na memória e pronto. O máximo que você vai ter é session passivation/activation se as aplicações estiverem em cluster (e o servidor tiver caído gracefully, o que na maioria das vezes não é o caso) e quem já usou sessões em cluster sabe que é muito melhor não usar isso. Se pra você isso não faz diferença, ótimo, mas eu já escrevi aplicações grandes o suficiente pra saber que guardar estado de usuário demais na memória do servidor é uma péssima idéia.

ah perdão, eu achava que tu tava se referindo ao seam

sobre o facelets, pelo que eu ví ele só tem problema com alguns poucos componentes do tomahawk. Com richfaces não tem nada por exemplo

Virtual Machine Man Membro desde: 21/01/2004 14:12:54 Mensagens: 719 Offline

Mauricio Linhares wrote:
Não há otimização nenhuma, ele bota na memória e pronto. O máximo que você vai ter é session passivation/activation se as aplicações estiverem em cluster (e o servidor tiver caído gracefully, o que na maioria das vezes não é o caso) e quem já usou sessões em cluster sabe que é muito melhor não usar isso. Se pra você isso não faz diferença, ótimo, mas eu já escrevi aplicações grandes o suficiente pra saber que guardar estado de usuário demais na memória do servidor é uma péssima idéia.

Isso se vc usar websession no lugar de SFSB ... como já citado ...

JavaGuru Membro desde: 18/09/2006 15:26:48 Mensagens: 226 Offline

Oba! Esta discussão está (ou estava) bonita!

Cheguei um pouco atrasado, mas surgiram algumas dúvidas...

Para o time do JSF (é só uma brincadeira):
Estou pensando em iniciar o desenvolvimento de uma aplicação utilizando JSF com RichFaces + a4j + Facelets + Spring + JPA (hibernate + hibernate validator)
Será uma aplicação cliente servidor com um volume de acessos entre baixo a médio.

O que acham dessa idéia?

E para o time do anti-JSF (Repito, é só uma brincadeira!):
Para a camada de view, algo como Dojo + JSP ficaria legal? Têm outras idéias legais?

E pra todo mundo... colocar o JavaFx nessa história seria prudente? Ou ainda é muito verde pra se pensar?

Desculpem se falei besteira e, por favor, me ajudem a desfazer esse nó na mente do iniciante!

[]s

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