Hi skar, Thanks for trying out the smart table model. You should certainly be able to set zero rows of data without getting an error. I'll take a look at that.
In terms of the selection, the smart model makes the assumption that you want to preserve the selection across table operations. In some cases, this is probably confusing to the user. So as Fritz said, you should be able to explicitly clear the selection using table.clearSelection(). I am not sure how this interacts with indexed selection, though, so I'll take a look at that as well. (Indexed selection means that the model tracks the selection in terms of the values in a particular column. Imagine having a unique ID for each row in the table; under indexed selection, the model "knows" the ID of each selected row, and when rows move around, it will find the selected rows by ID and keep them selected for you.) In terms of your other question: >Also, how much faster Smart Table is, instead of searching for the string in the row data and then using the matched rows in a separate array for the table model? Could you elaborate on this a bit? I'm not sure what you mean by this. I'll try to give you some detail on the smart model's performance. (Probably more than you wanted.) :) The smart table model really is "smarter" about some kinds of table changes than the simple model, and that means that making changes to big tables should be relatively faster. However, it's also preserving various properties, like sorting, across table operations -- something that the simple model doesn't do. (As far as I recall, when you make a modification to a simple model, you have to re-sort the whole table.) To help with this, the smart model maintains an index of all the rows. The index is just an associative array where the keys are row IDs and the values are row references. This allows it to instantly find any row without searching. It exports this capability to users via the locate method. If you need this capability -- e.g., the items in your table are subject to frequent modifications -- then the smart model will be vastly more efficient even for small tables. If you don't use the capabilities implied by the index, then maintaining the index is just extra overhead, and will probably be slower for small tables. The smart model also tries to be clever about the algorithms it uses. For example, if the table is sorted by column A, and the user clicks the label for column A, the smart model doesn't re-sort the table; it just reverses the order of the rows. Obviously if you are just inverting the sort, you don't need to do anything other than that, and that's a difference of O(N) operations vs O(N lg N) operations. For a 1000 row table, that's 1000 operations vs 10,000 operations. Similarly, because the smart model keeps the rows sorted, adding new rows can be made more efficient. Instead of adding the rows and then re-sorting the whole table, all you need to do is sort the rows to be added, and then merge these rows with the (already sorted) table. (See http://en.wikipedia.org/wiki/Merge_sort for more about merge sorting.) Consider the difference: if you add 1000 rows to a 1000 row table, then you're going to do 1000 lg 1000 operations to sort the new rows and then ~2000 opertions to merge the new rows with the (already sorted) table, for a total of ~12,000 operations. In contrast, re-sorting from scratch will cost 2000 lg 2000 operations, for a total of ~22,000 operations. And as the table sizes grow, the difference becomes more significant; in other words, the smart model scales better. The real question is how this theoretical analysis carries over to the real world. There's a bit of overhead in doing things "smarter", for example, and JavaScript performance is heavily influenced by how much you can use calls into native code vs JavaScript code. A call to sort(...), while theoretically O(n lg n), is doing very different operations than a sort routine written in JavaScript, because those O(n lg n) operations are happening in native code in the browser, which is probably 10-1000 times faster than JavaScript code. So I think we just have to see how the current smart model fares in practice, and make adjustments over time... and potentially add dynamic performance tuning so that it will tailor itself to the particular browser it's running in. The smart model scales badly, though, when you have a lot of different views, because it maintains all these views as you modify the table. On the other hand, this allows instant switching between views. At some point I'll add a "lazy view" option to address this if it becomes a problem in practice. So far I haven't seen an issue in tables with a dozen or so views. Dave -- View this message in context: http://www.nabble.com/smart-table-selection-problem--tp25766263p25768170.html Sent from the qooxdoo-devel mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
