Paginar uma JTable

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.

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.

Talvez voce possa fazer tratamento de alguns AbstractTableModel ?
E tratar da sua maneira

drsmachado:

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.

Tudo que estende JTable não deve, nunca, receber um query. JTable tem como função exibir dados, não realizar ou controlar consultas.

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.

Rafael_Leal:

drsmachado:

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.

Tudo que estende JTable não deve, nunca, receber um query. JTable tem como função exibir dados, não realizar ou controlar consultas.

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.

drsmachado:

Rafael_Leal:

drsmachado:

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.

Tudo que estende JTable não deve, nunca, receber um query. JTable tem como função exibir dados, não realizar ou controlar consultas.

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.

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.

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.