> 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.

I am not able to understand what you are saying here, other than old qooxdoo
used tables?

>
> 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).

Yes, I understand that creating fewer dom nodes if possible is an advantage, but
do you not also discard all of the formatting capaiblities built natively into
table structure?

Dont get me wrong, in part I see the elegance of using div's and your own layout
mechanism where possible, but question the value in tabular data?

> > 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?

Well, as I stated, it somtimes crashes IE. Other times it will just
spin CPU cycles at about 99% for very long periods of time (10-20
seconds for 5k rows)

> Is the loading the problem or
> the sorting of the data.

each additional 1k items takes progressively longer, so loading is
also a problem - somewhere around 15 seconds to load

But the real problem is sorting. And yes, it is MUCH worse in IE.

> 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.

doing this server side is not an option for at least one of the
applications. I myself dont
belive that 5k rows of data is human consumable, and displaying data
in this format to me
is incorrect, but that is the requirement.

Unfortunately, there is an existing in-house custom table component
that is able to sort 5k rows in IE on a moderatly powered pc (sub what
my test machine is) in sub second time, so
I wont be able to sell that it is too slow because of ie :)

If I can find ways to improve this, based on our in house solution, I
will gladly submit a patch.

Thank you for your information!
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_idv37&alloc_id865&op=click
_______________________________________________
Qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Reply via email to