On 8/7/07, MootCycle <[EMAIL PROTECTED]> wrote: > > Derrell, > I really appreciate the reply. I was looking at your solution for > hidden rows, and I'm trying to decide how to proceed with our > implementation. We really need tables to be able to filter out rows, but I > am hesitant to follow the same method you have described. Since we need this > to occur in all tables and not just TreeVirtual, I would either have to > modify the Table object (I'd guess qx.ui.table.model.Simple) or create a > specialized subclass of Table with added functionality to filter records.
Yes, you'd derive a new table model from the Simple table model (or from the Abstract table model) and add the capability to that. > Our current application is already running into some performance issues in > IE6, so I'm hesitant to add another full array of data to each table object. I have sympathy. IE6 is sooooooooooooooooooo slow. My best recommendation is to not use it. (Yes, I know we can't always tell our customers that, but it's worth a try.) The IE slowness seems to be mostly in rendering, however, not in processing of javascript code, so you may find that adding another array as is done in TreeVirtual doesn't slow you down significantly beyond the normal IE slowness. > Do you think I could add something like a _hiddenArr to the > SimpleTableModel (or perhaps create a more complex table model for this). > Instead of having _hiddenArr be a duplication of the data, it could have a > length of _rowArr.length. By default, all the values would be null, and a > setRowHidden function could swap values. I assume I would have to modify > something in the rendering or data fetching to make sure the hidden rows > would be skipped when the table is rendered. I definitely don't know where > the best place to skip hidden records would be in the table code. I would > also have to make sure that _hiddenArr would stay sorted in the same way > that _rowArr is. I feel like I'd have to create more accounting to make sure > that this approach worked, but it would have a smaller memory footprint. Any > thoughts? The problem with simply marking rows as hidden is that you'll slow down the already-slow scrolling. Currently, scrolling is able to just find the number of displayed rows, and add or subtract that number from the current starting row and then render the appropriate number of rows starting at the newly-determined starting point. If some rows are hidden, you'll have to loop instead of adding/subtracting. It may be that that's not significant, but you'll have to determine that by testing. In any case, you'll still be deriving a new table model from either the Simple or Abstract table model class. Cheers, Derrell ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
