Infelizmente, qualquer conjunto extra de componentes JSF hoje em dia tem muito bug. Creio que a RI, que nao tem nada extra, é o que temos de mais maduro.
IceFaces, MyFaces, Tomahawk e outros chegam a tirar a paciencia do desenvolvedor: javascripts gigantes sao gerados e acionados, html quebrado, etc. O RichFaces, apesar de nao ser perfeito, pra mim parece ser o que há de melhor hoje em dia.
mas fazer esses componentes por contra própria teria muito mais bugs 
Alguns componentes da versão anterior não são compativeis, por exemplo o modalPanel.
Antes era assim:
<rich:modalPanel id="mpLogon" autosized="true">
<f:facet name="header"><h:outputText value="Entrar" /></f:facet>
<f:facet name="controls">
<h:graphicImage value="/images/default/action_delete.gif" style="cursor:pointer" onclick="Richfaces.hideModalPanel('mpLogon')" />
</f:facet>
</rich:modalPanel>agora ficou assim
<rich:modalPanel id="panel" width="350" height="100">
<f:facet name="header">
<h:panelGroup>
<h:outputText value="Entrar" />
</h:panelGroup>
</f:facet>
<f:facet name="controls">
<h:panelGroup>
<h:graphicImage value="/images/default/action_delete.gif" style="cursor:pointer" id="hidelink"/>
<rich:componentControl for="panel" attachTo="hidelink" operation="hide" event="onclick"/>
</h:panelGroup>
</f:facet>
</rich:modalPanel>O autosize ja era, porem o comando para fechar a janela ficou mais clean.
Esta dando um trabalho danado para ajustar todos os modelPanel da aplicação :?
galera, o fileupload é simplesmente mágico. Semana passada um outro analista q trabalha aqui perdeu um tempão para implementar este componente da bib. do WebGalileo. Mostrei este file upload do Rich funfando pra ele e ele quase chorou...rsrsrsrsrsrskkkkkkkkkkkkkkkkkkkkkkkkkk[quote=Paulo Silveira]Infelizmente, qualquer conjunto extra de componentes JSF hoje em dia tem muito bug. Creio que a RI, que nao tem nada extra, é o que temos de mais maduro.
IceFaces, MyFaces, Tomahawk e outros chegam a tirar a paciencia do desenvolvedor: javascripts gigantes sao gerados e acionados, html quebrado, etc. O RichFaces, apesar de nao ser perfeito, pra mim parece ser o que há de melhor hoje em dia.[/quote]
Mas que problemas tu vê nisso? Para os componentes funcionarem, os Javascripts são mais que necessários. Talvez alguma revisão de código seja necessária pra otimizar isso, mas eu sinceramente não consigo ver bugs no Tomahawk por exemplo, muit menos problemas com javascrip.
Desculpe a ignorância, mas o que seria um “html quebrado” nesse contexto?
Eu ja uso o richfaces para atualizar para a nova versao como devo proceder?e so trocar os jar’s do projeto?
As IDE possuem plugin ou funcionalidade para arrastar e soltar estes componentes na tela ou tenho que editar JSP com taglibs?
O JBoss Tools ajuda bastante, mas está anos luz de ser um “arrastar/soltar” estilo matisse.
YES! viva o FileUpload!!!
Muito bom lançamento! 
Renan
[quote=Leozin]Mas que problemas tu vê nisso? Para os componentes funcionarem, os Javascripts são mais que necessários. Talvez alguma revisão de código seja necessária pra otimizar isso, mas eu sinceramente não consigo ver bugs no Tomahawk por exemplo, muit menos problemas com javascrip.
Desculpe a ignorância, mas o que seria um “html quebrado” nesse contexto?[/quote]
Veja o HTML gerado pelo JSF e chore. Simplesmente isso. Obviamente o Javascript é necessário, mas do jeito que está implementado é gambiarra. E feia!
[quote=David][quote=Leozin]Mas que problemas tu vê nisso? Para os componentes funcionarem, os Javascripts são mais que necessários. Talvez alguma revisão de código seja necessária pra otimizar isso, mas eu sinceramente não consigo ver bugs no Tomahawk por exemplo, muit menos problemas com javascrip.
Desculpe a ignorância, mas o que seria um “html quebrado” nesse contexto?[/quote]
Veja o HTML gerado pelo JSF e chore. Simplesmente isso. Obviamente o Javascript é necessário, mas do jeito que está implementado é gambiarra. E feia! ;)[/quote]
Ai acho que cabe analisar o quão é importante pro seu projeto que o html cuspido pelo framework seja “bonito”.
A solução seria fazer esses componentes na mão por exemplo? eu passo, prefiro 500k a mais numa pagina do que 2 semanas a mais de desenvolvimento e dor de cabeça (manutenção) pro resto do projeto.
O grande problema de suites de componentes JSF com Ajax “embutido” é o desempenho… Para sites pequenos, com pouco acesso concorrente, você pode até ignorar essa carga e o conteúdo gerado por ela, mas quando o seu nível de acesso concorrente sobe para a casa dos 500-1000 usuários (muitos deles simultâneos…), passa a fazer bastante diferença.
Este é o caso do projeto onde trabalho atualmente. E eu uso o Seam + RichFaces. Das suites/frameworks no mercado, estas me parecem as melhores, e têm atendido essa nossa carga de usuários adequadamente. Mas eu passei dias otimizando glassfish e aplicação web para conseguir esse nível de desempenho. Foi uma experiência para a qual eu estava psicologicamente preparado, imaginava que teria de me empenhar nisso - mas espero nunca mais ter de repetir 
Enfim, resumindo, acho que essas suites de componentes JSF poderiam sim frear um pouquinho o desenvolvimento de novas features e componentes e investir mais tempo em desempenho para aplicação de alta potencial de escalabilidade. Use plugins como o firebug + YSlow no seu firefox e veja o que algumas tabs, data-tables e modal panels fazem com a requisição HTTP
Sim, é so atualizar os jar do richfaces
bom, como atualizar é preciso, já comecei aqui e como eu não esperava que fosse diferente já deu pau no que funcionava.
O problema foi num datascroller, ele está acusando que o metodo org.richfaces.component.UIDatascroller.setupFirstRowValue não existe, como eu não chamei este metodo, baixei o fonte do rf 3.2 e o metodo está lá bonitinho do jeito que tem que ser. Vai entender…vou brigar aqui com o fonte e ver se descubro o que é. qq coisa eu posto aí pro pessoal.
Lmebrem-se que a versão 3.2.0 implementa JSF 1.2, não suportando mais 1.1, sendo assim é bem provavel que alguns componentes tenham algumas alterações ou novas opções também, vale dar uma olhada com calma nas mudanças e documentações disponíveis no site.
http://jboss.com/index.html?module=bb&op=viewtopic&t=132562
[quote]Is 3.2.0 backward compatible with previous versions? How it is save to upgrade?
The major point is dropping support with JSF 1.1. So, if you still use it - do not upgrade. The backward compatibility in the rest parts should not be broken. However, how smoothly your concrete project can be upgraded depends of how thickly you use undocumented features and/or workarounds in JSF and RichFaces. If you face the problems during the upgrade, report them to the forum. The core RichFaces team is going to monitor the forum on permanent bases just after the release to detect and solve the potential problems.[/quote]
Eu conheço JSF
por que você não mostra soluções mais elegantes do que as que são geradas? Eu sinceramente não ví nenhuma gambiarra (ai meu deus, não é w3c compliance?), e html eu não preciso ficar fuçando em código, ainda mais que o destino final é o usuário e não um desenvolvedor que vai ter um analizador de “html bonito”. É estranho esse tipo de crítica, sinceramente…
[quote=Luiz Aguiar] Ai acho que cabe analisar o quão é importante pro seu projeto que o html cuspido pelo framework seja “bonito”.
A solução seria fazer esses componentes na mão por exemplo? eu passo, prefiro 500k a mais numa pagina do que 2 semanas a mais de desenvolvimento e dor de cabeça (manutenção) pro resto do projeto. [/quote]
Exatamente. Se tão achando tão ruim assim, faz os componentes e as chamadas ajax tudo na mão, é rapidinho né? pelamor
[quote=javaBeats ]O grande problema de suites de componentes JSF com Ajax “embutido” é o desempenho… Para sites pequenos, com pouco acesso concorrente, você pode até ignorar essa carga e o conteúdo gerado por ela, mas quando o seu nível de acesso concorrente sobe para a casa dos 500-1000 usuários (muitos deles simultâneos…), passa a fazer bastante diferença.
Este é o caso do projeto onde trabalho atualmente. E eu uso o Seam + RichFaces. Das suites/frameworks no mercado, estas me parecem as melhores, e têm atendido essa nossa carga de usuários adequadamente. Mas eu passei dias otimizando glassfish e aplicação web para conseguir esse nível de desempenho. Foi uma experiência para a qual eu estava psicologicamente preparado, imaginava que teria de me empenhar nisso - mas espero nunca mais ter de repetir
Enfim, resumindo, acho que essas suites de componentes JSF poderiam sim frear um pouquinho o desenvolvimento de novas features e componentes e investir mais tempo em desempenho para aplicação de alta potencial de escalabilidade. Use plugins como o firebug + YSlow no seu firefox e veja o que algumas tabs, data-tables e modal panels fazem com a requisição HTTP [/quote]
Na verdade em qualquer sistema com 500-1000 usuários simultâneos precisa de otimização, ou pelo menos, algumas cautelas pra evitar crashes aleatórios
Se você ver o debug do a4j tu consegue ver o tamanho das respostas que ele envia. Mas se você simplesmente cuspir código na tela, você realmente vê cabeçalhos http grandes. Existem várias formas de otimizar isso, desde usando regions até single-requests, sugiro a você estudar um pouco mais sobre os frameworks e ver que as otimizações são possível, de várias maneiras, e que faz com que o sistema aguente toda essa demanda que você cita aí.
Oi Luiz, blz né?? Sim, estou usando a implementação 1.2 da JSF. Tanto que o meu problema foi só com o datascroller. O resto funfou.
[quote=Leozin]Eu conheço JSF
por que você não mostra soluções mais elegantes do que as que são geradas? Eu sinceramente não ví nenhuma gambiarra (ai meu deus, não é w3c compliance?), e html eu não preciso ficar fuçando em código, ainda mais que o destino final é o usuário e não um desenvolvedor que vai ter um analizador de “html bonito”. É estranho esse tipo de crítica, sinceramente…
[/quote]
Bem, isso aqui é um commandLink:
Pra quem gosta de Javascript isso é ridículo, sinceramente…