dmbaggett wrote:
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.
Thanks. That should help me :)
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.)
I'm manually clearing selection before setting new data, so it's ok now :)
in the row data and then using the matched rows in a separate array for the
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.
Yes, O(n) beats O(n lg n) anyday :)
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.
I've got only the All view and a single smart view based on a single
search field. I think the default All view can be hidden and can be used
when the search field(s) are all empty. And when the data is initially
fetched, it compares each row/column against all the view, but in my
case, the search field is still empty, so it's meaningless to search for
empty string in all the rows, so it can also be avoided, no?
And thanks for the great work. It's a neat idea :)
cheers,
skar.
--
--
The life so short, the craft so long to learn.
------------------------------------------------------------------------------
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
