I know there are plans to rewrite GridBox in 1.3 so I use this to make some wishes.
1) Caching of the rows on the client side. This would allow to do sorting and filtering without having to retransmit all data and layout information again and again.
2a) Sorting should only transmit the new order (row-id) of the rows. Currently the full information for all rows is retransmitted.
2b) Adding to a sorted grid should preserve the sort order and insert the new row on the location according to the sort order. Currently the sort indicator gets lost and the new row is added to the end and resorting again causes the retransmitting of the full information of all rows.
May be by setting a flag like setSortedAppending(true/false) with the old behaviour if set to false (default)
or a new method addSorted(Object) which behaves like now if the GridBox is unsorted.
2c) Caching would allow a three state sorting: unsorted -> ascending -> descending -> unsorted (and so on) without extra cost.
3) The caching would allow to hide / unhide specific rows by only transmiting the row-id of the effected rows. Currently you have to retransmit the full information of all rows again and again if the filter changes the count of visible rows especially if you have to unhide rows.
I realy like thinwire, but working with huge GridBoxes (10.000 rows or more) is a pain.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As my point of view, this may be a great improvment.
But working with 10000 rows on the client side is the most likely design bug :(
Regards,
Oleksandr
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2008-02-15
You are right that this is an extreme example and not a daily one, but my experience is that this situations happens even if not intendet. And even some hundred rows - which can easely be reached (and wanted) in a search about 100000 product-numbers - currently are felt cumbersome when you have to work with as user.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Several hundred rows do not cause big problems even now (from my and my users experience).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2008-03-11
I did some time recordings and it looks like that the gridbox is not to blame (so much) but that the tablelayout which I used as replacement introduced the realy huge time consumption. The numbers (in milliseconds and rouded):
fetching 200 objects from database: 2000 ms (there is space for improvement but thats another story)
showing 200 rows in a gridbox: 300 ms (which is/was more or less ok)
showing 200 rows with more complex layout in a tablelayout: 6000 ms
reshowing the 200 rows in tablelayout after resorting: 600 ms
The key seams to be that with the tablelayout the transmitted layout information grows high by a factor of 20 compared with the gridbox variant. One row is composed of a panel seperated with its own tablelayout into six areas (5 labels and one textarea). I think this presumtion is confirmed with the time that is needed to reshow the results. For reshowing I do not clear and rebuild the tablelayout but "only" change the text of all components via the setText method which saves time by a factor of 10 compared with the initial building of the tablelayout.
When I guess that the text information is 2 or 3 times more than in the gridbox variant that relation makes sense.
So if there is a way to reduce (repetition of) layout information it will make thinwire faster in general and especially in cases like this where the layout information is the same for all rows (except for the first row which holds buttons for selecting the sort order).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2008-03-11
FYI: Some guys venture to affirm that they can handle 1000000 rows at <http://www.treegrid.com/TreeGrid5_0/Html/Example1M.html>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Appreciate the suggestions, but what we're actually going to do is implement a data-view for the GridBox in 1.3. In such a design, the client will only contain and display a small "view" (200 rows or so) of the actual data set. The whole set will remain on the server and it'll be sent as needed to the client, as you scroll through the Grid. If you sort, the sort will take place on the server and again, just a small view will be presented on the client with the result of the new sort.
The problem with trying to keep all 10,000 rows on the client is that browsers really start to slow down once so many UI elements have been created (even if they are not visible). ThinWire tries to be super light on it's feet already, but no Grid implementation in any Ajax framework can handle 10,000 rows well. In fact, from what I've seen, ThinWire can handle many fold more rows then the Grids offered by other vendors. The only Grids that perform better are those that implement a data-view model for thier Grids like we are planning for 1.3
-Josh <G>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2008-02-15
I am glad to hear that you are implementing a model that is more advanced than my suggestion ;-) I thought of something like this but did not venture to talk about because I think this is a realy challenge to implement such a desing. But if it succeeds it can be a highlight. I am curious to see it working.
gerhard
ps: After the response of Oleksandr I refuse rearches with more than 1000 search result and require more exact search criterias ;-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2008-02-15
By the way:
1) Will this new data-view design being limited to GridBox or will it be possible to use it with hand-made table-layout too?
The reason for the question:
I had to display a list were one row consists of a more complex design than one line of information. So according to some threads on this list I faked this by dynamic usage of table layout.
One row has following design (I hope this ascii art shows what I try to explain, when displayed with a non-proportional font):
******************************************
* textarea for | book author *
* book-title with |---------------*
* multiple lines | editor *
* -----------------------+---------------*
* worktype | publisher | year | id *
******************************************
2) Or will the new GridBox cells accapt all thinwire components so that self-made table-layout handling is not neccessary?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2008-02-15
******************************************
* textarea for ......... | book author . *
* book-title with ...... |---------------*
* multiple lines ....... | editor ...... *
* -----------------------+---------------*
* worktype | publisher . | . year . | id *
******************************************
No comments about handling of multiple blanks in html please ;-))
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I know there are plans to rewrite GridBox in 1.3 so I use this to make some wishes.
1) Caching of the rows on the client side. This would allow to do sorting and filtering without having to retransmit all data and layout information again and again.
2a) Sorting should only transmit the new order (row-id) of the rows. Currently the full information for all rows is retransmitted.
2b) Adding to a sorted grid should preserve the sort order and insert the new row on the location according to the sort order. Currently the sort indicator gets lost and the new row is added to the end and resorting again causes the retransmitting of the full information of all rows.
May be by setting a flag like setSortedAppending(true/false) with the old behaviour if set to false (default)
or a new method addSorted(Object) which behaves like now if the GridBox is unsorted.
2c) Caching would allow a three state sorting: unsorted -> ascending -> descending -> unsorted (and so on) without extra cost.
3) The caching would allow to hide / unhide specific rows by only transmiting the row-id of the effected rows. Currently you have to retransmit the full information of all rows again and again if the filter changes the count of visible rows especially if you have to unhide rows.
I realy like thinwire, but working with huge GridBoxes (10.000 rows or more) is a pain.
As my point of view, this may be a great improvment.
But working with 10000 rows on the client side is the most likely design bug :(
Regards,
Oleksandr
You are right that this is an extreme example and not a daily one, but my experience is that this situations happens even if not intendet. And even some hundred rows - which can easely be reached (and wanted) in a search about 100000 product-numbers - currently are felt cumbersome when you have to work with as user.
Several hundred rows do not cause big problems even now (from my and my users experience).
I did some time recordings and it looks like that the gridbox is not to blame (so much) but that the tablelayout which I used as replacement introduced the realy huge time consumption. The numbers (in milliseconds and rouded):
fetching 200 objects from database: 2000 ms (there is space for improvement but thats another story)
showing 200 rows in a gridbox: 300 ms (which is/was more or less ok)
showing 200 rows with more complex layout in a tablelayout: 6000 ms
reshowing the 200 rows in tablelayout after resorting: 600 ms
The key seams to be that with the tablelayout the transmitted layout information grows high by a factor of 20 compared with the gridbox variant. One row is composed of a panel seperated with its own tablelayout into six areas (5 labels and one textarea). I think this presumtion is confirmed with the time that is needed to reshow the results. For reshowing I do not clear and rebuild the tablelayout but "only" change the text of all components via the setText method which saves time by a factor of 10 compared with the initial building of the tablelayout.
When I guess that the text information is 2 or 3 times more than in the gridbox variant that relation makes sense.
So if there is a way to reduce (repetition of) layout information it will make thinwire faster in general and especially in cases like this where the layout information is the same for all rows (except for the first row which holds buttons for selecting the sort order).
FYI: Some guys venture to affirm that they can handle 1000000 rows at <http://www.treegrid.com/TreeGrid5_0/Html/Example1M.html>
Very, very impressive. There are some bugs (not all features work as documented), but anyway. The only problem is licensing.
Appreciate the suggestions, but what we're actually going to do is implement a data-view for the GridBox in 1.3. In such a design, the client will only contain and display a small "view" (200 rows or so) of the actual data set. The whole set will remain on the server and it'll be sent as needed to the client, as you scroll through the Grid. If you sort, the sort will take place on the server and again, just a small view will be presented on the client with the result of the new sort.
The problem with trying to keep all 10,000 rows on the client is that browsers really start to slow down once so many UI elements have been created (even if they are not visible). ThinWire tries to be super light on it's feet already, but no Grid implementation in any Ajax framework can handle 10,000 rows well. In fact, from what I've seen, ThinWire can handle many fold more rows then the Grids offered by other vendors. The only Grids that perform better are those that implement a data-view model for thier Grids like we are planning for 1.3
-Josh <G>
I am glad to hear that you are implementing a model that is more advanced than my suggestion ;-) I thought of something like this but did not venture to talk about because I think this is a realy challenge to implement such a desing. But if it succeeds it can be a highlight. I am curious to see it working.
gerhard
ps: After the response of Oleksandr I refuse rearches with more than 1000 search result and require more exact search criterias ;-)
By the way:
1) Will this new data-view design being limited to GridBox or will it be possible to use it with hand-made table-layout too?
The reason for the question:
I had to display a list were one row consists of a more complex design than one line of information. So according to some threads on this list I faked this by dynamic usage of table layout.
One row has following design (I hope this ascii art shows what I try to explain, when displayed with a non-proportional font):
******************************************
* textarea for | book author *
* book-title with |---------------*
* multiple lines | editor *
* -----------------------+---------------*
* worktype | publisher | year | id *
******************************************
2) Or will the new GridBox cells accapt all thinwire components so that self-made table-layout handling is not neccessary?
******************************************
* textarea for ......... | book author . *
* book-title with ...... |---------------*
* multiple lines ....... | editor ...... *
* -----------------------+---------------*
* worktype | publisher . | . year . | id *
******************************************
No comments about handling of multiple blanks in html please ;-))