触发器是最近的 re-detected SwingX issue :支持深度 - 即在折叠节点下,而不是仅在可见节点下,这是当前行为 - 节点搜索。
“Nichts leichter als das”我目前对 SwingWorker 的所有接触:在后台线程中遍历 TreeModel 并更新进程中的 ui,如下面的粗略片段所示。 Fest 的 EDT 检查器很满意,但它只检查重绘(这在 EDT 上很好地发生在这里)
只是……严格来说,那个后台线程必须是 EDT,因为它正在访问(通过读取)模型。所以,问题是:
- 如何正确实现搜索线程?
- 或者我们可以忍受这种风险(当然有大量记录)
特殊情况解决方案的一种可能性是使用第二个(克隆的或“相同”制作的)模型进行搜索,然后在“真实”模型中找到相应的匹配项。对于一般的搜索支持,这并不能很好地发挥作用,因为它对任何特定模型一无所知,即使它想要也无法创建克隆。另外,它必须应用所有 View 排序/过滤(将来)......
// a crude worker (match hard-coded and directly coupled to the ui)
public static class SearchWorker extends SwingWorker<Void, File> {
private Enumeration enumer;
private JXList list;
private JXTree tree;
public SearchWorker(Enumeration enumer, JXList list, JXTree tree) {
this.enumer = enumer;
this.list = list;
this.tree = tree;
}
@Override
protected Void doInBackground() throws Exception {
int count = 0;
while (enumer.hasMoreElements()) {
count++;
File file = (File) enumer.nextElement();
if (match(file)) {
publish(file);
}
if (count > 100){
count = 0;
Thread.sleep(50);
}
}
return null;
}
@Override
protected void process(List<File> chunks) {
for (File file : chunks) {
((DefaultListModel) list.getModel()).addElement(file);
TreePath path = createPathToRoot(file);
tree.addSelectionPath(path);
tree.scrollPathToVisible(path);
}
}
private TreePath createPathToRoot(File file) {
boolean result = false;
List<File> path = new LinkedList<File>();
while(!result && file != null) {
result = file.equals(tree.getModel().getRoot());
path.add(0, file);
file = file.getParentFile();
}
return new TreePath(path.toArray());
}
private boolean match(File file) {
return file.getName().startsWith("c");
}
}
// its usage in terms of SwingX test support
public void interactiveDeepSearch() {
final FileSystemModel files = new FileSystemModel(new File("."));
final JXTree tree = new JXTree(files);
tree.setCellRenderer(new DefaultTreeRenderer(IconValues.FILE_ICON, StringValues.FILE_NAME));
final JXList list = new JXList(new DefaultListModel());
list.setCellRenderer(new DefaultListRenderer(StringValues.FILE_NAME));
list.setVisibleRowCount(20);
JXFrame frame = wrapWithScrollingInFrame(tree, "search files");
frame.add(new JScrollPane(list), BorderLayout.SOUTH);
Action traverse = new AbstractAction("worker") {
@Override
public void actionPerformed(ActionEvent e) {
setEnabled(false);
Enumeration fileEnum = new PreorderModelEnumeration(files);
SwingWorker worker = new SearchWorker(fileEnum, list, tree);
PropertyChangeListener l = new PropertyChangeListener() {
@Override
public void propertyChange(PropertyChangeEvent evt) {
if (evt.getNewValue() == SwingWorker.StateValue.DONE) {
//T.imeOut("search end ");
setEnabled(true);
((SwingWorker) evt.getSource()).removePropertyChangeListener(this);
}
}
};
worker.addPropertyChangeListener(l);
// T.imeOn("starting search ... ");
worker.execute();
}
};
addAction(frame, traverse);
show(frame)
}
仅供引用:交叉发布到 OTN's Swing forum和 SwingLabs forum - 将尝试在最后发布所有输入的摘要(如果有的话:-)
附录
最后,结果证明我问错了问题(或者在错误的上下文中提出了正确的问题;-):“问题”是由假设的解决方案引起的,真正的要解决的任务是支持分层搜索算法(目前 AbstractSearchable 严重偏向于线性搜索)。
一旦解决了这个问题,下一个问题可能就是框架可以在多大程度上支持具体的分层搜索。鉴于 TreeModels 的自定义实现的多样性,这很可能只适用于最简单的。
在此处和其他论坛的讨论中提出的一些想法。在具体的上下文中,首先测量遍历是否缓慢:大多数内存中模型的遍历速度快如闪电,除了使用基本支持外不需要做任何事情。
仅当遍历是瓶颈时(如 SwingX 的 FileSystemModel 实现中的 f.i.),才需要额外的工作:
- 在真正不可变和不可修改的 TreeModel 中,我们可能会在 SwingWorker 的后台线程中进行只读访问
- 在延迟加载/删除场景中违反了不可修改的前提条件
- 可能有一个支持模型的自然自定义数据结构,它实际上与实际模型“分离”,允许同步到该支持模型(在遍历模型和 View 模型中)
- 将实际搜索传回数据库
- 在给定的 TreeModel 之上使用包装器,以保证访问 EDT 上的底层模型
- “假”后台搜索:实际上在 EDT 上以足够小的 block 执行此操作(例如在计时器中),以便用户不会注意到任何延迟
无论采用何种技术选项来解决慢速搜索,都需要解决相同的可用性问题:如何向最终用户呈现延迟?那是一个完全不同的故事,可能更依赖于上下文/需求:-)
最佳答案
SwingWorker
和 TreeModel
都应该同步访问一个公共(public)的底层 DataModel
。使共享数据量(有效地)不可变可以最大限度地减少开销。由于这高度依赖于应用程序,我不确定该 View 可以为搜索不可见节点提供多少支持。
关于java - 处理长时间运行的 EDT 任务(f.i. TreeModel 搜索),我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/9378232/