bom dia galera.
Tenho uma dúvida a respeito das JTable, é possível paginar uma jtable?
por exemplo, a cada dez registro cria uma outra table.
Não encontrei na documentação da Sun.
Obrigado atenciosamente.
Camarada, você precisa reler a documentação toda.
A JTable é apenas um elemento que permtie exibir conteúdo, não é responsável (diretamente) por tratar o mesmo.
Isso você deve fazer na camada de controle, que tratará os dados que preenchem a JTable, controlam o limite de linhas e em quantas páginas será dividido o conteúdo.
Desde que você implemente a sua propria paginação sim.
JTable recebe uma coleção de dados pronta.
O que você poderia fazer é o component que extenda JTable que contenha botões de navegação e receba uma query com a clausula LIMIT. Assim os botões de paginação mudam o valor da variavel que controle o LIMIT da query re-popula o table e faz o update na UI do seu novo componente.
Nunca houvi falar que componente pronto em Swing.
[quote=Rafael_Leal]Desde que você implemente a sua propria paginação sim.
JTable recebe uma coleção de dados pronta.
O que você poderia fazer é o component que extenda JTable que contenha botões de navegação e receba uma query com a clausula LIMIT. Assim os botões de paginação mudam o valor da variavel que controle o LIMIT da query re-popula o table e faz o update na UI do seu novo componente.
Nunca houvi falar que componente pronto em Swing.[/quote]
Tudo que estende JTable não deve, nunca, receber um query. JTable tem como função exibir dados, não realizar ou controlar consultas.
Talvez voce possa fazer tratamento de alguns AbstractTableModel ?
E tratar da sua maneira
[quote=drsmachado][quote=Rafael_Leal]Desde que você implemente a sua propria paginação sim.
JTable recebe uma coleção de dados pronta.
O que você poderia fazer é o component que extenda JTable que contenha botões de navegação e receba uma query com a clausula LIMIT. Assim os botões de paginação mudam o valor da variavel que controle o LIMIT da query re-popula o table e faz o update na UI do seu novo componente.
Nunca ouvi falar que componente pronto em Swing.[/quote]
Tudo que estende JTable não deve, nunca, receber um query. JTable tem como função exibir dados, não realizar ou controlar consultas.[/quote]
Há uma diferença entre NUNCA e NÃO É ACONSELHAVEL.
E também ele não precisa por um objeto query como propriedade do Objeto estendido de JTable. E sim um STRING com o conteudo sql/hql para assim a instância X esse JTable estendido sempre saber qual é a consulta dele.
Sim, mas pode/deveria haver um Listener que escute os eventos de paginação e esse sim executar as consultas. Neste caso não faz sentido extender JTable se você não criar um componente mais robusto que resolva o problema e sim ficar criando camadas e camadas que deixam o código complicado e/ou ilegivel… NA MINHA OPNIÃO.
Em alguns casos não dá para ser produtivo (pode gerar disperdicio) se seguir a risca todos os padrões. Principalmente com Swing.
[quote=Rafael_Leal][quote=drsmachado][quote=Rafael_Leal]Desde que você implemente a sua propria paginação sim.
JTable recebe uma coleção de dados pronta.
O que você poderia fazer é o component que extenda JTable que contenha botões de navegação e receba uma query com a clausula LIMIT. Assim os botões de paginação mudam o valor da variavel que controle o LIMIT da query re-popula o table e faz o update na UI do seu novo componente.
Nunca ouvi falar que componente pronto em Swing.[/quote]
Tudo que estende JTable não deve, nunca, receber um query. JTable tem como função exibir dados, não realizar ou controlar consultas.[/quote]
Há uma diferença entre NUNCA e NÃO É ACONSELHAVEL.
E também ele não precisa por um objeto query como propriedade do Objeto estendido de JTable. E sim um STRING com o conteudo sql/hql para assim a instância X esse JTable estendido sempre saber qual é a consulta dele.
Sim, mas pode/deveria haver um Listener que escute os eventos de paginação e esse sim executar as consultas. Neste caso não faz sentido extender JTable se você não criar um componente mais robusto que resolva o problema e sim ficar criando camadas e camadas que deixam o código complicado e/ou ilegivel… NA MINHA OPNIÃO.
Em alguns casos não dá para ser produtivo (pode gerar disperdicio) se seguir a risca todos os padrões. Principalmente com Swing.[/quote]
Legibilidade é manter afastado código que vai ir ao banco e código de apresentação.
na minha OPINIÃO, o DESPERDÍCIO é pensar que fazendo de um modo não adequado está se ganhando tempo. E se tiver que trocar a interface desktop por web? Todo o retrabalho será muito grande.
[quote=drsmachado][quote=Rafael_Leal][quote=drsmachado][quote=Rafael_Leal]Desde que você implemente a sua propria paginação sim.
JTable recebe uma coleção de dados pronta.
O que você poderia fazer é o component que extenda JTable que contenha botões de navegação e receba uma query com a clausula LIMIT. Assim os botões de paginação mudam o valor da variavel que controle o LIMIT da query re-popula o table e faz o update na UI do seu novo componente.
Nunca ouvi falar que componente pronto em Swing.[/quote]
Tudo que estende JTable não deve, nunca, receber um query. JTable tem como função exibir dados, não realizar ou controlar consultas.[/quote]
Há uma diferença entre NUNCA e NÃO É ACONSELHAVEL.
E também ele não precisa por um objeto query como propriedade do Objeto estendido de JTable. E sim um STRING com o conteudo sql/hql para assim a instância X esse JTable estendido sempre saber qual é a consulta dele.
Sim, mas pode/deveria haver um Listener que escute os eventos de paginação e esse sim executar as consultas. Neste caso não faz sentido extender JTable se você não criar um componente mais robusto que resolva o problema e sim ficar criando camadas e camadas que deixam o código complicado e/ou ilegivel… NA MINHA OPNIÃO.
Em alguns casos não dá para ser produtivo (pode gerar disperdicio) se seguir a risca todos os padrões. Principalmente com Swing.[/quote]
Legibilidade é manter afastado código que vai ir ao banco e código de apresentação.
na minha OPINIÃO, o DESPERDÍCIO é pensar que fazendo de um modo não adequado está se ganhando tempo. E se tiver que trocar a interface desktop por web? Todo o retrabalho será muito grande.[/quote]
Legibilidade é a capacidade de absorver e transmitir conhecimento e entendimento através do código e sua arquitetura.
Existem linguagens que não suportam MVC e na sua definição seriam códigos ilegíveis. (seguir padrões facilita a legibilidade e não a promove)
Isso eu não vou te convencer do contrário.
Outra… como eu disse, o Listener que vai fazer a comunicação banco… quem é elegível a virar um BackingBean no Swing é o Listener… Se pegarmos o inverso então, nunca mais na programação Web ninguém vai usar Ajax e componentes ricos… por certas operações estarem na view e não no controler.
A partir do momento que ele precisa fazer uma paginação em Swing o projeto em si perde a escalabilidade para Web. A única coisa que se aproveita em projetos híbridos são os serviços…
Se fosse tão pragmático assim. Tomcat cairia e desuso e tudo seria na base de soluções alá Servidores de Aplicação e EBJs, mas sempre tem hora que não dá para lapidar diamantes com a marreta.
Eu não pretendo aprofundar nessa linha de discussão. Até porque provavelmente eu sei bem menos que você sobre o assunto. E o objetivo da thread é resolver o problema do rapáz que abriu o tópico. Dei minha solução… onde eu a aprendi num projeto de uma ERP em swing.