[quote] 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.
Se isso for só um array de String, me desculpe, mas isso não é caso de uso. [/quote]
Conversor de entidade não vem com implementação default, mas você acha uma pilha de exemplos na internet. Fora que você faz isso uma vez na vida e usa em todo projeto(s). Não vejo grande esforço em fazer uma classe com dois métodos (no máááximo 10 minutos?) que será largamente reutilizada. Em contra-partida, se você usa um Wicket da vida você faz classe Java pra tudo, logo escrever um único conversor JSF não é para ser um sacrifício.
[quote]Prototype é uma biblioteca de suporte e Scriptaculous é uma biblioteca de efeitos, nenhum dos dois tem haver com componentes ricos, então eles não vem ao caso.
E qual dessas bibliotecas de JSF usa o Dojo? [/quote]
Scriptaculus possui componentes drag and drop, autocomplete, sliders além de outros componentes interessantes, não é apenas uma lib de efeitos, mas isso não vem ao caso… O Tomahawk e seu Sandbox tem alguma coisa de DOJO, coisa simples como o Fish-Eye e um Initializer para o toolKit. Não é nada de muito sofisticado ainda, mas a tendência é que a integração aumente (basta dar uma olhadinha no Jira do projeto).
Quanto a minha citação ao ajax4jsf vs DWR foi apenas para dizer o quanto é trivial a manipulação de ajax…
Uma aplicação de tamanho razoável não armazena conversação em sessão, aliás a própria JBoss desencoraja isso… O modelo proposto é a utilização de Statefuls, mas essa já é uma outra discussão …
Eu falei via javascript, não usando collections.[/quote]
Pelo que eu tinha entendido sobre sua pergunta (em itálico na primeira citação), era se eu removia os elementos declarados estaticamente na página via Javascript. Bom, se os elementos não são estáticos (podem ser removidos dinâmicamente), logo não há pq eu declara-los de maneira estática na página… logo, sempre serão coleções, que posso manipular dinamicamente via ajax ou request convencional.
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.
A falta de uma base decente faz com que todos os outros frameworks tenham que fazer serviço de encanadador, como os eventos de ciclo de vida de um bean, que existem em ASP desde “sempre” e em JSF foram sumariamente ignorados.
A parte de componentes do Scriptaculous é bem restrita, mas isso realmente não vem ao caso. Interessante saber que o Tomahawk está indo pra algum lugar, porque o MyFaces anda comendo poeira faz tempo pro RI.
Independente do lugar aonde eles vão ficar (não vai ser na sessão, mas vai ser na memória do servidor de qualquer forma, então o problema é o mesmo), você acha uma boa idéia usar Statefuls em um ambiente com cargas altas e mais do que uma máquina como servidor de aplicação?
Não tenho como discordar que algumas coisas deveriam vir por padrão no JSF, mas enquanto isso os componentes não standards estão cumprindo bem o papel.
Em relação ao Seam e o uso de Stateful, no ambiente que você descreveu, acho uma boa idéia como também acho a melhor situação. Os dados não ficam em memória o tempo todo como HttpSession, se o servidor precisar ele passiva o bean para atender a mais demanda, de acordo com seu algoritmo para passivação e local para store dos dados, preservando seu estado conversacional e liberando memória. Se o bean expira ele move de Passivated para DoesNotExist e encerra a conversação, caso contrário e for invocado, o bean volta ao estado ativo de Method-Read.
A replicação em um ambiente como parque de clusters, tbm não é igual a tradicional replicação stick-session de um HttpSession (já foi um dia). Os servidores de aplicação sincronizam o cache com granulariedade fina, replicando apenas o valor alterado de um atributo. Os Statefuls tem má fama devida as implementações antigas de replicação… hoje isso esta muito diferente (vide jbossCache do jBoss AS).
Implementar AJAX com JSF é algo realmente simples, hoje você consegue pegar uma aplicação JSF convencional (sem uso de AJAX) e inserir AJAX transparentemente através do Ajax4jsf, na maioria dos casos o que você mudará são algumas linhas nas páginas, e só.
DWR é na minha opinião o melhor framework AJAX para Java, isso claro se eu não estiver em uma aplicação que utilize JSF, daí sem dúvida eu vou de AJax4jsf
Se a vantagem do JSF é a gama enorme de componentes, você tem praticamente componente para quase tudo Utilizar outros componentes JSF não doi, até alivia a dor de ter que implementar um componente próprio.
Não entendo porque você critica isso, você faria o mesmo se estivesse utilizando outro framework como SpringMVC ou Struts, teria que juntar várias APIs para contornar carências de javascript e/ou css para conseguir o que os componentes JSF te proporcionam! No final seria bem mais trabalhoso!
Mesmo utilizando-se de APIs como Extjs para conseguir GUIs ricas você terá um grande problema, a enorme dificuldade em encontrar desenvolvedores que saibam realmente utilizar javascript de forma decente. A maioria só sabe utilizar javascript para criar funçõeszinhas de validação
Isso é verdade, infelizmente por JSF não contar ainda com uma padronização para AJAX nós temos algumas incompatibilidades como essa do Icefaces e outros conjuntos de componentes como Trindad, ou Richfaces ou algum proprietário, mas mesmo com as incompatibilidades eles conseguem conviver juntos no mesmo projeto. JSF 2.0 resolverá isso, sorte nossa!
Outra coisa que você tem razão e eu não discordo. Desenvolver componentes com JSF é algo sofrível, e eu acho que dificilmente vai valer a pena. Porém com Facelets e outros frameworks você consegue facilitar isso, mas ainda assim dá um trabalhinho Mas com a gama enorme de componentes você ainda acha que há tanta necessidade para reclamar disso? Eu sinceramente nunca precisei criar qualquer componente JSF, e se precisasse tentaria evitar isso até não ter mais jeito.
Alguns pontos negativos na minha experiencia com jsf.
1 - Jsf puro é tão ruim quanto struts, se vc precisa copiar algo da internet para fazer sua aplicação funcionar tem algo muito errado, a documentação deveria ser suficiente.
2 - Integração com jstl é uma piada.
3 - Problemas com CSS, relacionados aos atributos gerados pelo jsf (outra piada)
4 - Problemas com customização de js.
5 - JSF é baseado em post, então esqueçam query string.
6 - Problemas relacionados aos botões de voltar e refresh.
7 - Muito lixo (html e javascript) gerado.
8 - Tente convencer um webdesigner que algumas coisas não podem ser mudadas.
Pessoal, respeito que alguns usem o jsf e gostem de suas “features”, mas defender algo que não segue o principio do KISS e o mesmo que nao querer assumir que seguiu o caminho errado. (quantas pessoas vcs conhecem que defendem fervorosamente o struts?).
Existem soluções melhores, mas claro que o jsf “funciona”. Porém, a maneira que o pessoal anda defendendo o jsf me parece que ele é a unica solução e deve ser utilizado independente dos milhoes de problemas.
Atualmente para mim, o jsf é algo promissor, porém fica nisso.
[quote]
1 - Jsf puro é tão ruim quanto struts, se vc precisa copiar algo da internet para fazer sua aplicação funcionar tem algo muito errado, a documentação deveria ser suficiente. [/quote]
Tirando o primeiro item que eu não entendi, os demais não são problemas hoje com JSF1.2 e alguns já tinham soluções mesmo com JSF1.1
JSF é bem simples, talvez a única coisa complicada dele seja a construção de componentes, fora isso não há complicações. Além do mais ter que criar um componente novo é algo difícil de acontencer, mas não improvável claro.
[quote]
Existem soluções melhores, mas claro que o jsf “funciona”. Porém, a maneira que o pessoal anda defendendo o jsf me parece que ele é a unica solução e deve ser utilizado independente dos milhoes de problemas.[/quote]
Assim como Java não é a solução para tudo JSF também não o é Nesse caso não é problema da tecnologia em si, mas sim de quem decidiu utiliza-la.
Se um dia escrever um artigo sobre Frameworks Web, o título seria o seguinte: “1001 Motivos para NÃO USAR JSF”[/quote]
Poderia começar citando 10 dos seus 1001?
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.
Ah, quer dizer que fazer componentes em JSF é tão difícil que eu tenho que usar uma engine de templates externa, que anda praticamente morta, pra poder fazer eles de forma produtiva?
E não vamos esquecer que um "componente" criado usando o Facelets só funciona com Facelets, não é um componente JSF padrão
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?
mata qualquer um do coração! meu deus, alguém me ajude. Realmente acho que a penúria deve ser em estudar…
e novamente
[quote]
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.[/quote]
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
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
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.
mata qualquer um do coração! meu deus, alguém me ajude. Realmente acho que a penúria deve ser em estudar…[/quote]
Você é cego ou está ignorando a afirmação sobre [size=24][color=red]sem usar o Seam[/color][/size] de propósito?
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[/quote]
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.
[quote=Mauricio Linhares]
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. [/quote]
Isso se vc usar websession no lugar de SFSB … como já citado …
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!
