Desculpem pela minha ignorancia, mas não encontrei muita coisa à respeito de desempenho sobre este assunto (pode ser que eu não tenha procurado nos lugares certos).
Eu estou com uma dúvida sobre componentes ajax e seu desempenho. Gostaria de saber se eu implementasse uma paginação em demanda utilizando por exemplo, algum componente do primefaces ou richfaces (<p:datatable>, rich:dataTable…), para um portal de noticias, onde o sistema iria armazenar muitos dados (milhares) e que tivesse muitos acessos por dia (milhares) , eu teria sucesso ( nao teria problemas em desempenho como, alto consumo de memoria ou algo do tipo) com estes metodos? eu digo isso pelo uso do AJAX.
Será bem vindo sugestões e dicas.
Agradeço desde ja!
Obs: foi citado acima o <p:datatable> e o rich:datatable pois encontrei codigos prontos sobre paginação em demanda.
Na paginação do primefaces você carrega toda a lista de registros na memória e ele faz a paginação gerando os links para ir e voltar. Com muitos registros é inviável, você pode usar o Lazy loading mas também tem seus problemas com contexto de bean (Session, Request), não trabalha muito bem com Request principalmente mas funciona com perfeição no Session e ViewScoped. No lazy você passaria uma query trazendo de dez em dez por exemplo e teria que setar o total de registros separadamente para o primefaces. É a única maneira viável de usar a paginação do primefaces com uma quantidade muito grande de registros. Quanto ao richfaces confesso que nunca trabalhei muito com ele. Era compatível com o JSF 1.1 e 1.2 e mais recentemente lançaram uma versão compatível com o JSF 2.0 mas nunca cheguei a usar com 2.0.
Creio que a solução do colega fnandos é mesmo a mais adequada, carregando o datatable de maneira lazy. Só há esse detalhe problemático do escopo do bean…uma vez que esses dados precisam estar na sessão já complica.
Eu sugiro você fazer algumas provas de conceito, mas eu partiria pra desenvolver um componente próprio.
[quote=jakefrog]Não sei c chega a vale a pena criar um dataTable próprio se já tem esse tanto a mostra, quando o tempo não está sobrando.
Bastaria utilizar um dataTable do primefaces como lazy e o scope como View.
Creio que seria um bom “combo” e sem precisar criar um novo componente.[/quote]
Sim, concordo…eu já criei várias taglibs no JSF 1.2 e perdi uns bons cabelos com isso hehe, com a quantidade de componentes disponíveis só recomendaria mesmo em um ultimo caso (embora isso tenha ficado muito mais simples no JSF 2). Como eu disse, uma prova de conceito seria ideal antes de qualquer aventura. Mas o ViewScoped persiste o bean mantendo-o na sessão, correto? Dependendo dos requisitos da aplicação isso pode ser ruim e embora facilite muito o desenvolvimento pode complicar pra escalar a aplicação depois, dado que são esperados alguns bons milhares de acessos. Claro que é possível contornar essas situações mas dá um bom trabalho…
[quote=alias]Mas o ViewScoped persiste o bean mantendo-o na sessão, correto? Dependendo dos requisitos da aplicação isso pode ser ruim e embora facilite muito o desenvolvimento pode complicar pra escalar a aplicação depois, dado que são esperados alguns bons milhares de acessos. Claro que é possível contornar essas situações mas dá um bom trabalho…[/quote]Mantém na sessão enquanto o usuário estiver lá, uma vez que ele navegue os dados voam.
O ideal mesmo seria o RequestScope que é possível também. Tendo em mente que todo objeto que for exibido na tela com a possibilidade da seleção, tem que ser manter o id do mesmo como hidden.
Impossível não é, da um pouco de trabalho mas você mantem a memória do teu servidor livre. [=
[quote=jakefrog][quote=alias]Mas o ViewScoped persiste o bean mantendo-o na sessão, correto? Dependendo dos requisitos da aplicação isso pode ser ruim e embora facilite muito o desenvolvimento pode complicar pra escalar a aplicação depois, dado que são esperados alguns bons milhares de acessos. Claro que é possível contornar essas situações mas dá um bom trabalho…[/quote]Mantém na sessão enquanto o usuário estiver lá, uma vez que ele navegue os dados voam.
O ideal mesmo seria o RequestScope que é possível também. Tendo em mente que todo objeto que for exibido na tela com a possibilidade da seleção, tem que ser manter o id do mesmo como hidden.
Impossível não é, da um pouco de trabalho mas você mantem a memória do teu servidor livre. [=[/quote]
Desculpe, foi o que quis dizer, que o ViewScoped mantem os dados na sessão apenas durante a exibição da página. Não entendi sua sugestao a respeito do id
O problema do request scope é que se a pessoa selecionar um item na tela, você deve saber qual ela selecionou correto? Aí geralmente utilizamos o view ou o session scope pois ele já tem esse objeto guardadinho pra gente. É só trabalhar com esse cara para ser feliz.
Para utilizar como request, o dataTable teria que guardar toda informação necessário para que o objeto selecionado seja identificado, geralmente o ID.
Olha soh um exemplo bobo abaixo:[code]
#{msgs.loginHello}: #{userMB.user.name} ||
<h:messages />
<h:dataTable value="#{dogMB.allDogs}" var="dog" styleClass="table" headerClass="tableColumnsHeader" rowClasses="tableFirstLine,tableNextLine" >
<h:column>
<f:facet name="header">
#{msgs.dogName}
</f:facet>
#{dog.name}
</h:column>
<h:column>
<f:facet name="header">
#{msgs.dogWeight}
</f:facet>
#{dog.weight}
</h:column>
<h:column>
<h:panelGrid columns="2">
<!-- Always save the id as hidden when you use a request scope MB -->
<h:inputHidden value="#{dog.id}" />
<h:commandButton action="#{dogMB.updateDogStart()}" value="#{msgs.update}" rendered="#{userMB.userAdmin}" >
<f:setPropertyActionListener target="#{dogMB.dog}" value="#{dog}" />
</h:commandButton>
<h:commandButton action="#{dogMB.deleteDogStart()}" value="#{msgs.delete}" rendered="#{userMB.userAdmin}" >
<f:setPropertyActionListener target="#{dogMB.dog}" value="#{dog}" />
</h:commandButton>
</h:panelGrid>
</h:column>
</h:dataTable>
<!-- This button is displayed to the user, just to you see the error msg -->
<h:commandButton action="createDog" value="#{msgs.create} #{msgs.dog}" />
</h:form>
</h:body>
[/code] Para enviar esse objeto como selecionado no caso do update/delete/detail ele precisar ir com o ID para nossa aplicar poder trabalhar com ele de modo correto.
Para isso o id foi colocado como hidden: <h:inputHidden value="#{dog.id}" />
Desse modo aí, seria possível possível ter um datatable lazy com requestScope MB. Eu tirei esse exemplo daqui: http://uaihebert.com/?p=836&page=9 Mas não está utilizando datatable lazy, não era a intenção do post. Mas pode ser utilizado para tal fim. [=
[quote=jakefrog]Mas alias eu concordo com o que você disse tá? Só estou falando como outras opções.
Tudo também depende do que foi solicitado na tarefa. =D[/quote]
Na boa mano, até se discordasse não teria problema nenhum né . Mas me perdoe a ignorancia, na real não entendi qual a função do id ali. Voce já está até passando o objeto inteiro com o f:setPropertyActionListener. Qual o porque do id?
[quote=alias][quote=jakefrog]Mas alias eu concordo com o que você disse tá? Só estou falando como outras opções.
Tudo também depende do que foi solicitado na tarefa. =D[/quote]
Na boa mano, até se discordasse não teria problema nenhum né . Mas me perdoe a ignorancia, na real não entendi qual a função do id ali. Voce já está até passando o objeto inteiro com o f:setPropertyActionListener. Qual o porque do id?[/quote]Se você utilizar um RequestScope você não iria ter o id do objeto sacou? Essa abordagem é útil nesse caso.
Se fosse Session ou View você não iria precisar fazer isso, mas aí iria ocupar a memória do servidor com a sessão.
[quote=alias][quote=jakefrog]
Se você utilizar um RequestScope você não iria ter o id do objeto sacou? Essa abordagem é útil nesse caso.
[/quote]
Bom, na verdade não saquei nao :lol: . Você já não está passando o objeto inteiro o setPropertyActionListener? Ainda nao entendi o porque do id…[/quote]Como você está usando RequestScope você só passa oq está na página. No exemplo acima, se você não passar o ID quando o JSF for popular o dog ele não teria de onde tirar o id. Se lembre que estou falando de um RequesScope, que os dados voam logo após a resposta ser enviada ao usuário. [=
[quote=jakefrog][quote=alias][quote=jakefrog]
Se você utilizar um RequestScope você não iria ter o id do objeto sacou? Essa abordagem é útil nesse caso.
[/quote]
Bom, na verdade não saquei nao :lol: . Você já não está passando o objeto inteiro o setPropertyActionListener? Ainda nao entendi o porque do id…[/quote]Como você está usando RequestScope você só passa oq está na página. No exemplo acima, se você não passar o ID quando o JSF for popular o dog ele não teria de onde tirar o id. Se lembre que estou falando de um RequesScope, que os dados voam logo após a resposta ser enviada ao usuário. [=[/quote]
ah, entendi…na requisição que vai ser disparada no click do botão o id que está no input hidden vai pro objeto que será passado no setPropertyActionListener, correto? Legal!
Mas será que rolava no caso do datatable? Seriam os atributos desse componente que ficariam nos hiddens?
[quote=alias][quote=jakefrog][quote=alias][quote=jakefrog]
Se você utilizar um RequestScope você não iria ter o id do objeto sacou? Essa abordagem é útil nesse caso.
[/quote]
Bom, na verdade não saquei nao :lol: . Você já não está passando o objeto inteiro o setPropertyActionListener? Ainda nao entendi o porque do id…[/quote]Como você está usando RequestScope você só passa oq está na página. No exemplo acima, se você não passar o ID quando o JSF for popular o dog ele não teria de onde tirar o id. Se lembre que estou falando de um RequesScope, que os dados voam logo após a resposta ser enviada ao usuário. [=[/quote]
ah, entendi…na requisição que vai ser disparada no click do botão o id que está no input hidden vai pro objeto que será passado no setPropertyActionListener, correto? Legal!
Mas será que rolava no caso do datatable? Seriam os atributos desse componente que ficariam nos hiddens?[/quote]Exato. [=
Não vejo pq não funcionaria em um datatable lazy com paginação.
Depois eu tento, mas só queria colocar como uma opção tb. [=
Estarei procurando sobre ferramentas que me ajudem pra testes. Pois mesmo com este refoço com ideias (RequestScoped e Lazy) não estou muito seguro sobre o desempenho.
Teria outra opção para resolver este problema (Portal de Notícias)? Ou so a implementação de um componente customizado?
[quote=silviasaint]Teria outra opção para resolver este problema (Portal de Notícias)? Ou so a implementação de um componente customizado?
[/quote]Se o Prime+Lazy não funcionar, teria que ser um customizado. Ou até mesmo outra tecnologia ao invés de JSF.
Esse tema de JSF aqui é bem polêmico pois muita gente o odeia. Pelo fato de ser orientado a componente e você ter muitas ações para uma simples chamada web.
Com isso você poderia ver outros frameworks como VRator, Playframework e tals.
. Mas me perdoe a ignorancia, na real não entendi qual a função do id ali. Voce já está até passando o objeto inteiro com o f:setPropertyActionListener. Qual o porque do id?