[SWINGX-1233] TreeSearchable: enhance to allow searching below collapsed nodes Created: 01/Dec/09  Updated: 10/Dec/12

Status: Open
Project: swingx
Component/s: Search
Affects Version/s: 1.6.1
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: kleopatra Assignee: kleopatra
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Duplicate
is duplicated by SWINGX-1482 JXTree: support deep search as an option Resolved
Related
is related to SWINGX-1483 JXTree: nextMatch must respect string... Resolved
Issuezilla Id: 1,233

 Description   

title says it all: currently it searches by rows, that is visible/expanded nodes only.
Reasons:

  • pre-getStringAt api was a bit weakly defined
  • walking subtrees might be costly

now the first should be fine, how about the second?

Jeanette



 Comments   
Comment by kleopatra [ 01/Dec/09 ]

.

Comment by kleopatra [ 15/Feb/12 ]

hmm ... now have correct duplication direction?

Comment by kleopatra [ 22/Feb/12 ]

relevant discussions

on java.net
http://www.java.net/forum/topic/javadesktop/java-desktop-technologies/swinglabs/handle-long-running-edt-tasks-fi-treemodel-searching

on OTN
https://forums.oracle.com/forums/thread.jspa?threadID=2350136

on SO
http://stackoverflow.com/questions/9378232/handle-long-running-edt-tasks-f-i-treemodel-searching

Interesting input in all of them, will sumarize in the end

Comment by kleopatra [ 08/Mar/12 ]

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

Comment by kleopatra [ 10/Dec/12 ]

postpone

Generated at Tue Mar 31 07:23:22 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.