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.
[quote=Leozin]
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í.[/quote]
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
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 
[quote=rdantas] 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.[/quote]
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.
++
[quote=David]Bem, isso aqui é um commandLink:
Pra quem gosta de Javascript isso é ridículo, sinceramente…[/quote]
David não consegui entender qual foi sua intenção em mostrar isso, pode nos explicar melhor?
[quote=David]
Bem, isso aqui é um commandLink:
Pra quem gosta de Javascript isso é ridículo, sinceramente…[/quote]
Seguindo essa tua lógica, quem usa Prototype, Dojo, scriptaculous ou algo do gênero deve odiar javascript também, porque os código-fonte são seguindo esse nível
mas, antes de tudo, você tem alguma solução melhor que essa para efetuar A MESMA OPERAÇÃO?
e também, o que há de tão ruim com Javascript? Você nem encosta, quem faz isso é o JSF, não sei porque o stress. Vale lembrar que esses component-based apps sempre vão gerar javascripts malucos. Você já mexeu com asp.NET? Já viu o que ele gera?
a propósito, esse números malucos que aparecem provavelmente é de algum desenvolvedor amador que não conhece boas práticas. Esses números são gerados porque o usuário não colocou um id para o form e um id para o commandLink. Se esse mesmo desenvolvedor reclama de “muitos javascripts”, ele é um tanto quanto hipócrita, porque ele simplesmente “cospe” código na tela da maneira que lhe convém sem nenhum conhecimento de boas práticas, ao ponto de reclamar de javascript como se fosse “algo não-bonito”
Não me leve a mal hehehe é que esses argumentos realmente não “estão descendo”, por mais que o código gerado possa ser tosco, porque devemos nos importar? Se pensar assim também, o código que o netbeans gera pra criar telas do swing é HORRÍVEL, muito pior do que qualquer javascript que o jsf gera
Ps.: eu não acho o código gerado tosco, pelo contrário, é suficiente e funcional tendo em vista o leque de opções que o JSF + a4j + rich faces nos dão
Eu concordo plenamente,
Não entendo porque essa birra toda uai, quem preferir fazer tudo na mão, que fique uma semana tentando descobrir pq o código funciona no FF mas não funfa no IE rs
[quote]eu não acho o código gerado tosco, pelo contrário, é suficiente e funcional tendo em vista o leque de opções que o JSF + a4j + rich faces nos dão
[/quote]
Concordo. Se for para reclamar do código javascript gerado, tem que reclamar também do SQL gerado pelo hibernate com base no HQL, acho que esse tipo de discursão não tem sentido.
Concluindo, acho que quem não tá satisfeito com o código gerado do RichFaces ou Hibernate que faça um framework que gere um código javascript “bonito” ou um framework que gere um SQL apresentável.
[quote=foxpv][quote]
eu não acho o código gerado tosco, pelo contrário, é suficiente e funcional tendo em vista o leque de opções que o JSF + a4j + rich faces nos dão
[/quote]
Eu concordo plenamente,
Não entendo porque essa birra toda uai, quem preferir fazer tudo na mão, que fique uma semana tentando descobrir pq o código funciona no FF mas não funfa no IE rs
[/quote]
Mas alguém ainda faz na “unha”?
Afe, tem tantos frameworks legais, como o Ext JS, Dojo Toolkit, YUI, jQuery (esse é muito bom e leve), Prototype e etc…
Eu acho o RichFaces sensacional. Principalmente pq é um framework que funciona bem no JSF. O resto, nossa, só quem trabalha sempre com JSF sabe o que é sofrer. E mais, fazer um que rode bem no JSF num é moleza.
Opa, que é isso, parecido com aquilo ali? Onde você viu isso? E eu não gosto mesmo do prototype ou script.aculo.us, prefiro jQuery.
Bem, primeiro, um simples link não deveria precisar de Javascript. Cadê a acessibilidade? Se você usar um pocket com internet explorer não vai poder acessar um sistema feito com JSF por que o browser não suporta Javascript. Sobre a solução, eu falo já.
Eu adoro Javascript, gosto MUITO mesmo. Mas quem disse que frameworks component-based precisam de javascript? Já viu como o Wicket (http://wicket.apache.org/examples.html) funciona, por exemplo? Tá ai uma solução muito melhor.
Eu não reclamei dos números loucos, como você falou. Reclamei da forma como o javascript foi gerado para criar um link.
De jeito nenhum eu vou levar a mal. Estamos apenas discutindo idéias. E, assim como você não se importa com o Javascript gerado, eu não me importo com o código que o Netbeans gera porque eu não uso Netbeans.
[quote=foxpv] Eu concordo plenamente,
Não entendo porque essa birra toda uai, quem preferir fazer tudo na mão, que fique uma semana tentando descobrir pq o código funciona no FF mas não funfa no IE rs[/quote]
Mas quem falou em fazer na mão? Eu falei que o framework deveria fazer isso de uma forma diferente, e não que a gente deveria fazer na mão.
E vc acha que uma pessoa com navegador sem suporte a javascript realmente consegue navegar na maioria dos sites? isso pq vc ama javascript, imagine se odiasse. Aliás, usar javascript não está na especificação JSF. (Se não me engano o MyFaces tem a opção de não utilizar javascript, mas ninguem usa isso pq é um retrocesso)
Você acha que os caras envolvidos nisso não sabem programar em java script? ha ha ha… Existem motivos para cada uma dessas coisas que você critica, pode ter certeza.
E são vários motivos. JSF e sua árvore de componentes não é algo que nasceu para ser manipulado com javascript; Além disso, otimizações como compressão de javascript e pre-processing do código também devem rolar (não consigo confirmar, mas o código cuspido pelos componentes indica isso). Enfim, não é trabalho fácil, ou que possa ser orientado pelos preceitos do desenvolvimento tradicional em javascript.
O que eu queria defender quando postei pela primeira vez era um modo “plain”, de recursos mais magros. O CSS no RichFaces já funciona assim, você pode desabilitar os skins para que os componentes se adaptem com mais facilidade a uma estilização existente (e como isso ajuda, quem trabalha com designers de departamento de marketing sabe do que eu estou falando). Talvez fosse possível (e aí fica aberta a discussão), que ao invés de usar frameworks javascript de terceiros (scriptaculous, prototype), alguns componentes pudessem se beneficiar de javascript otimizado para páginas dinâmicas (JSF, Facelets, whatever…)
E dai? Se existe a possibilidade de você oferecer um mínimo de recursos, você vai optar por não oferecer nada a esse pessoal? Entendam que eu não estou falando dos componentes do RichFaces, estou falando de um simples link. Obviamente, pra se usar componentes mais complexos eu preciso de Javascript, mas você quer dizer que usar um link sem Javascript é um retrocesso? Outra coisa, porque eu “amo” javascript, quer dizer que eu tenho que usar em todo canto? :roll:
Bem, um dos motivos para se usar javascript em tudo no JSF é que ele trabalha com POST, já que é necessário enviar o viewstate salvo no cliente para o servidor, e essa informação normalmente é muito grande para ser enviada através de uma URL. Então, qualquer link tem que dar um submit em um formulário por causa disso. Mas e nos casos em que salvamos o viewstate no servidor? Isso continua sendo necessário? Se não for, por que não dar uma alternativa ao desenvolvedor?
Esse tipo de coisa dificulta a utilização de JSF em sistemas que necessitam de urls amigáveis, “bookmarkable pages” (não encontrei uma tradução boa), etc. Não é possível fazer isso com JSF sem utilizar o suporte de uma outra ferramenta como o RestFaces, por exemplo, ou sem escrever uma porrada de código num PhaseListener…
E dai? Se existe a possibilidade de você oferecer um mínimo de recursos, você vai optar por não oferecer nada a esse pessoal? Entendam que eu não estou falando dos componentes do RichFaces, estou falando de um simples link. Obviamente, pra se usar componentes mais complexos eu preciso de Javascript, mas você quer dizer que usar um link sem Javascript é um retrocesso? Outra coisa, porque eu “amo” javascript, quer dizer que eu tenho que usar em todo canto? :roll: [/quote]
esse é o problema, você está olhando apenas para o link… isso no faces é um componente, como vários outros.
só uma pergunta: como que eu faço pra submeter um form através de um link sem usar javascript?
Sem usar javascript, não sei, mas se servir via AJAX… vc pode ter um a4j:form com a propriedade ajaxSubmit=“true” reRender=“seus, componentes, que, devem, re-renderizar, no, submit, separados, por, virgula”
Sem usar javascript, não sei, mas se servir via AJAX… vc pode ter um a4j:form com a propriedade ajaxSubmit=“true” reRender=“seus, componentes, que, devem, re-renderizar, no, submit, separados, por, virgula”[/quote]
…
acho que você não entendeu a minha pergunta e a ironia também hehe
eu quero saber como submeter um form POR HTML, sem usar jsf, struts ou qualquer outra coisa, puro, sem usar NADA de javascript
leia os posts anterior que acho que você vai entender melhor o por que da minha pergunta 
Sem usar javascript, não sei, mas se servir via AJAX… vc pode ter um a4j:form com a propriedade ajaxSubmit=“true” reRender=“seus, componentes, que, devem, re-renderizar, no, submit, separados, por, virgula”[/quote]
Asynchronous JavaScript and XML)
Ou seja, se você submete um form via ajax, você também esta o fazendo via Javascript.