JTable + TableModel 缓存获取事件以进行延迟实例化？
场景：
您正在使用带有自定义 TableModel 的 JTable 来查看位于数据库或网络或其他位置的某些集合的内容。
完成这项工作的强力方法是立即加载整个集合。假设由于所需资源的原因，这是不切实际的。
解决该问题的简单方法是在 JTable 呈现每一行时按需获取行，一次一行，并调用 TableModel.getValueAt()；根据需要缓存。但这会导致数据库受到大量点击。
有没有办法监听 JTable 的滚动/视口事件，以确定在渲染每个单元格之前它将显示哪些行？如果是这样，我想拦截并导致我的自定义TableModel 一次预取一页。
编辑：只是澄清一下，这里的重点是能够批量获取一组可见表行的内容，而不是必须单独获取每一行的内容。
Scenario:
you are using a JTable with a custom TableModel to view the contents of some collection located in a database or on the network or whatever.
The brute force way to make this work is to load the whole collection at once. Let's say that isn't practical because of the resources needed.
The simple way around that problem is to fetch rows on demand, one row at a time, as the JTable renders each row, and calls TableModel.getValueAt(); cache as necessary. This causes a lot of hits to the database, though.
Is there a way to listen to scroll/viewport events for a JTable, to figure out what rows it is going to display before it renders each cell? If so, I would like to intercept and cause my custom TableModel to prefetch one page at a time.
edit: just to clarify, the point here is to be able to fetch the contents of a group of visible table rows in one batch, rather than having to fetch the contents of each row by itself.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
看看 http://www.javaworld.com/javaworld/javatips/ jw-javatip137.html 文章。在本文中，有一个自定义 TableModel 能够从数据库检索行的“块” 该
场景的另一种解决方案（尽管不完全是您正在寻找的）是延迟加载每一行而不是预取。请参阅我自己的帖子（在 google 中搜索“JTable 绑定到具有延迟加载的数据库”）了解如何执行此操作。这个想法是，当表模型被要求提供未缓存/加载的行时，它将为每列返回“wait..retriving”字符串（假设所有列都是字符串）。同时它将在另一个线程中安排任务（使用 ExecutorService）。然后该任务将从数据库中检索数据并更新数据模型。在我的文章中，我实际上使用了 Beans 绑定，因此使用自定义列表而不是自定义表模型。但我相信你可以推断出这个想法。
Take a look at http://www.javaworld.com/javaworld/javatips/jw-javatip137.html article. In this article there is a custom TableModel that is able to retrieve "chunks" of rows from the database
Another solution to the scenario although is not exactly what you are looking for would be lazy load each row instead of prefetch. See my own post (search google for "JTable bound to a database with lazy loading") on how to do it. The idea is that when the tablemodel is asked for a row that is not cached/loaded it will return "wait..retrieving" string for each column (assuming that all columns are strings). and at the same time it will schedule a task in another thread (using an ExecutorService). Then the task will retrieve the data from the database and update the datamodel. In my post I actually used Beans bindings so instead of a custom tablemodel y used a custom list. But I'm sure you can extrapolate the idea.
实际上，这正是 JTable 所允许的。 AFAIK
如果 getRowCount() 方法准确反映了有多少条记录，
然后当绘制单元格时，仅查询可见部分。
我不认为通过监听视口来预取会更快。
您可以等待所有 getvalue 请求。记录这些，返回“null”或已经缓存的值。然后在 20 毫秒内没有调用 getvalue 后，对所有记录的单元格执行实际请求。并在模型上触发 rowUpdated 事件，以便 JTable 再次重新绘制。
**[编辑]**您可以维护模型上查询的最后记录的列表。您的列表不需要比屏幕上可见的行数长。在几毫秒内没有查询 getValue() 后，您可以向后端执行此异步批量请求。
这里唯一的问题是排序/过滤算法。
当您查询视口并让数据依赖于它时，就会有一个
数据和视图之间的 1-1 关系。 JTable 本身没有的东西。
但我想没有办法解决这个问题。
我将使 IDE 调试器能够挖掘 sun 代码。然后看看他们的渲染实现如何找出要重新绘制的行。我心里不知道。
In effect, that is exactly what JTable allows. afaik
if the getRowCount() method reflects exactly how many records there are,
then when the cells are painted, only the visible part is queried.
I don't think prefetching by listening on the viewport would be any faster.
you could wait for all getvalue requests. record those, return "null" or the already cached value. then after a getvalue isn't called for say 20 ms do the actual request for all the recorded cells. and fire rowUpdated events on the model so JTable repaints again.
**[edit]**You could maintain a list of the last records queried on the model. your list doesn't need to be any longer than the amount of rows visible on the screen. after getValue() isn't queried for a few ms, you could perform this async bulk request to the back-end
The only catch here is the sorting/filtering algorithm.
When you query the viewport and let the data depend on that, then there is a
1-1 relation between your data and the view. Something which JTable itself doesn't have.
But i guess there is no way around that.
I would enable the IDE debugger to dig through sun code. and then see how their rendering implementation finds out which rows to repaint. i don't know by heart.