J. Russell Smyth schrieb:
I am curious about some "construction" decisions. Is there reasoning behind making QxListView from "div" components rather than "table"? My main curiosity is we are evaluating QooxDoo for some major internal applications, and want to make sure we understand as much as possible before making a decision.
The old qooxdoo use sub-node-structures many times. This is true for tables, where you need to move the children to the desired target node, which is not the real node of the parent itself.
The new ones layout decisions use divs all over and try to create as less as DOM nodes as necessary (as they are performance critical).
One reason I ask this is we have had to deal with large tables and sorting here, and have had to do some interesting stuff to make them fast - we have at least one app with a requirement for tables containing 5000 rows with sorting capability - with IE support a must. For QooxDoo, if you load QxListView with 5k rows in the demo, it dies.. it has actually crashed my IE, and when it dosnt, it just falls asleep.. even with only a few k rows, sorting is unacceptably slow...
It really dies? What means "dies" for you? Is the loading the problem or the sorting of the data. To handle sorts of large arrays at client is a problem because the Internet Explorer has some huge performance impacts there (much bigger than Firefox). If you have many items in your list it is probably the best to do the real sorting at the server and just send the new data via AJAX to the client.
Sebastian
Thanks Russell
------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
