Question

Trigger is a recently re-detected SwingX issue: support deep – that is under collapsed nodes as opposed to visible nodes only, which is the current behaviour – node searching.

“Nichts leichter als das” with all my current exposure to SwingWorker: walk the TreeModel in the background thread and update the ui in process, like shown in a crude snippet below. Fest’s EDT checker is happy enough, but then it only checks on repaint (which is nicely happening on the EDT here)

Only … strictly speaking, that background thread must be the EDT as it is accessing (by reading) the model. So, the questions are:

• how to implement the search thread-correctly?
• or can we live with that risk (heavily documented, of course)

One possibility for a special case solution would be to have a second (cloned or otherwise “same”-made) model for searching and then find the corresponding matches in the “real” model. That doesn’t play overly nicely with a general searching support, as that can’t know anything about any particular model, that is can’t create a clone even if it wanted. Plus it would have to apply all the view sorting/filtering (in future) …

// 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)
 } 

FYI: cross-posted to OTN’s Swing forum and SwingLabs forum – will try to post a summary of all input at the end (if there is any 🙂

Addendum

At the end of the day, it turned out that I asked the wrong question (or right question in a wrong context ;-): the “problem” arose by an assumed solution, the real task to solve is to support a hierarchical search algorithm (right now the AbstractSearchable is heavily skewed on linear search).

Once that will solved, the next question might be how much a framework can do to support concrete hierarchical searchables. Given the variety of custom implementations of TreeModels, that’s most probably possible only for the most simple.

Some thoughts that came up in the discussions here and the other forums. In a concrete context, first measure if the traversal is slow: most in-memory models are lightning fast to traverse, nothing needs to be done except using the basic support.

Only if the traversal is the bottleneck (as f.i. in the FileSystemModel implementations of SwingX) additional work is needed:

• in a truly immutable and unmodifiable TreeModel we might get away with read-only access in a SwingWorker’s background thread
• the unmodifiable precondition is violated in lazy loading/deleting scenarios
• there might be a natural custom data structure which backs the model, which is effectively kind-of “detached” from the actual model which allows synchronization to that backing model (in both traversal and view model)
• pass the actual search back to the database
• use an wrapper on top of a given TreeModel which guarantees to access the underlying model on the EDT
• “fake” background searching: actually do so in small-enough blocks on the EDT (f.i. in a Timer) so that the user doesn’t notice any delay

Whatever the technical option to a slow search, there’s the same usability problem to solve: how to present the delay to the end user? And that’s an entirely different story, probably even more context/requirement dependent 🙂

Answer 1

Both SwingWorker and TreeModel should synchronize access to a common, underlying DataModel. Making the shared quanta of data (effectively) immutable can minimize the overhead. As this is highly application-dependent, I’m not sure how much support the view can offer for searching non-visible nodes.