Lançado JBoss Richfaces 3.2.0

Leozin wrote: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?

Veja o HTML gerado pelo JSF e chore. Simplesmente isso. Obviamente o Javascript é necessário, mas do jeito que está implementado é gambiarra. E feia!

David wrote:

Leozin wrote: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?

Veja o HTML gerado pelo JSF e chore. Simplesmente isso. Obviamente o Javascript é necessário, mas do jeito que está implementado é gambiarra. E feia!

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.

Java Ninja Membro desde: 27/01/2005 11:41:47 Mensagens: 296 Offline

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

lgweb wrote:Eu ja uso o richfaces para atualizar para a nova versao como devo proceder?e so trocar os jar's do projeto?

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

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.

This message was edited 1 time. Last update was at 02/04/2008 08:55:15

David wrote:Veja o HTML gerado pelo JSF e chore. Simplesmente isso. Obviamente o Javascript é necessário, mas do jeito que está implementado é gambiarra. E feia!

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...

Luiz Aguiar wrote: 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.

Exatamente. Se tão achando tão ruim assim, faz os componentes e as chamadas ajax tudo na mão, é rapidinho né? pelamor

javaBeats wrote: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

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í.

Luiz Aguiar wrote: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.

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.

Leozin wrote: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...

Bem, isso aqui é um commandLink:

Pra quem gosta de Javascript isso é ridículo, sinceramente...

Thread.start() Membro desde: 09/07/2006 23:19:22 Mensagens: 41 Offline

Aqui na empresa usamos, aprovamos e recomendamos, baseados nas experiências anteriores com IceFaces.
Em relação a performance não tenho o que reclamar, o código gerado satisfaz a necessidade na maioria das vezes. Não discordo, o código poderia ser melhor, mas será que o codigo melhor produziria uma mudança perceptível, gritante? Existem alguns bugs sim, mas o comprometimento do projeto para com os usuários é inegável. Agora, com esses novos componentes, ficou ainda melhor.

Java Ninja Membro desde: 27/01/2005 11:41:47 Mensagens: 296 Offline

Leozin wrote:
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í.

Exatamente. É isso que fizemos, desde o primeiro dia de desenvolvimento, e felizmente o desempenho é bom e estamos "aguentando" toda essa demanda sem maiores problemas. Usamos regions, limitToList, e tudo o mais que está disponível no A4J/RichFaces, mas também foi necessário otimizar o glassfish, e configurações específicas de JSF - o web.xml está lotado de comentários

O que eu quero argumentar é - embora tenha performance aceitável, e seja uma das melhores (se não a melhor) suíte de componentes disponível na comunidade hoje, o renderização poderia ser melhor sim. Mas eu não consigo fazer melhor, nem tenho a menor predisposição de re-escrever componentes, então para mim está bom, obrigado

Java Ninja Membro desde: 27/01/2005 11:41:47 Mensagens: 296 Offline

E aproveitando a deixa, eu quero fazer um elogio para o Glassfish

Aguenta esta carga toda aí, sem crashes, no máximo lentidões aleatórias em poucas requisições (considerando o volume...). O pessoal de QA usa e abusa do JMeter para testar a carga sobre a aplicação, e os resultados são ótimos. Ponto para o Glassfish

rdantas wrote: 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.

Abri um novo tópico com detalhes do problema: http://www.guj.com.br/posts/list/0/86576.java#463039

Caso alguem esteja passando pelo mesmo problema, ou tenha alguma idéia.

Abraços,
Rodrigo.

Leozin wrote:Existem várias formas de otimizar isso, desde usando regions até single-requests

++

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