Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Martin Gregorie Newsgroups: comp.lang.java.programmer Subject: Re: How to parse an array? Date: Wed, 28 Jun 2017 21:55:56 -0000 (UTC) Organization: A noiseless patient Spider Lines: 68 Message-ID: References:

<1758ec6f-966d-44c2-bdb9-03e5d4b61619@googlegroups.com> <967dfbc4-0e58-4867-b08c-67ff910df3fe@googlegroups.com> <642c0caf-de21-4add-8f61-8b68e94b1081@googlegroups.com>

<47fa7e7a-7757-46b0-a6bb-5084529a50e2@googlegroups.com> <63f1b363-ad45-498c-857c-dd0dd9165e04@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Wed, 28 Jun 2017 21:55:56 -0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="ac55a0e561b67b4af030256fc0e27f6c"; logging-data="2512"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18k6ncw70LLwJr5kcmqNFn0pEmWDOpzoio=" User-Agent: Pan/0.141 (Tarzan's Death; 168b179 git.gnome.org/pan2) Cancel-Lock: sha1:cpA8KL7qVkDvtN4FVdbGJL8CR5I= Xref: csiph.com comp.lang.java.programmer:36759 On Wed, 28 Jun 2017 13:02:38 -0700, Eric Douglas wrote: > Now the problem is the fancy view. I have a fancy sortable table which > extends my simple table class, which adds search() methods which call > lucene to check the cell values. This currently puts the lucene row > results into an ArrayList where the keys are the view row > indices and the values are the model row indices. > OK, thats the information I was missing and explains why using a custom class instead of an ArrayList to hold the row is a bad idea. > So if I change that to a tree type (TreeMap? TreeSet?) so it can > automatically sort itself > Here's a restatement of what I was suggesting. You'd leave the ArrayList of ArrayLists alone, exactly as Lucene returned them and never modify or recreate them unless/until Lucene replaces its content with new data. Instead, the TableModel would be based on a Collection that was sorted as the TreeMap it is derived from was being built. The Treemap's key fields are the contents of whatever column you want to sort on and its values are references to the ArrayList containing the corresponding row. Setting up the TreeMap would be something like: for (int i = 0; i < rowList.size(); i++) { ArrayList row = rowList.get(i); treemap.put(row.get(keyIndex), row); } Collection sortedList = treeMap.values(); and you'd use the Collection as the basis of your TableModel subclass rather than the ArrayList you currently use and which I've referred to as rowList. The effect is that the TreeMap should act as a self-sorting list. I think it would be faster than whatever sort is currently being used since building a TreeMap only looks at a subset of the keys already in it when adding a new item: I'd certainly expect it to be get relatively faster as the number of rows in the table increases. > and the values link the MyCustomRowData objects, then it's automatically > rebuilt to filter and sort as fast as possible. > Yes. > Now, I have a TreeMap where the indices are MyCustomRowData objects and > the values are the model indices? > The treemap keys are the values from the column you're sorting on and the values are references to the ArrayLists that form the rows. > How do I write the row sorter methods convertRowIndexToView, > convertRowIndexToModel when the tree classes have > no indexOf method? > If those methods really need to use a row index, i.e. can't easily be made to work on each row as forEach() returns it, then calling Collection.toArray() will return the collection as a sorted ArrayList[]. But if it comes down to that the game would appear to be somewhat lost, unless it runs significantly faster than your current code. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |