Tuesday, March 20th, 2007
Turbo Grid version 3
Category: Announcements
, Component, Dojo
TurboAjax Group is proud to announce the release of the TurboGrid 3 beta version. This long awaited release supports virtual scrolling, column sizing, compound rows, variable row height, dynamic sizing of columns and grid, fixed columns, tons of events, and much more.
TurboGrid is currently available for download for evaluation purposes. Additional licensing options will be available shortly. Please go to TurboAjax for more information of check out a demo and read the docs.
The Grid is built on top of Dojo.
2.7 rating from 33 votes
fucking slow fat Dojo-crap..this grid crashes my OPERA every time i load it…fuck’n waste of time!
It works fine on Opera9/Mac for me.
/me tries on windows too
Yep, works just great there too.
Sounds like “ajaxianer” is just special that way ;-)
Though, I don’t like all the namespace stuff you have to do in Dojo, I do respect them. They must be doing something right when loads of companies jump onboard. Maybe its how structured and Java like the framework is.
“aybe its how structured and Java like the framework is” maybe it just doesnt matter coz its fat and slow crap?
The controls themselves are fine, and the data is loaded asynchronously, so it will catch up. The only thing that looked slow was the master/detail view, but that was pretty cool in its own right. Ignore ajaxianer, and take a look for yourselves, it only takes a minute or so to play around with.
No, I think ajaxianer might have a point.
It is slow. And dojo is too large to even consider any more, no matter how much exclusion you can do.
Works fine for me in FF and IE. Lets not forget what is being offered here - an ajax grid that can do scrolling of 100,000 records and child/parent relationships as well as nice column resizing etc. Displaying this type (tabular) and magnitude (100,000s) of data is not easy and is not aimed at the rounded-corner generation. You are not going to add it to your occasionally updated blog site (unless you have a burning desire to list the contact details of all the dodgy lurkers you have met on myspace - and boy are you *popular*). It would seem to be aimed at the web application market and evaluation should center around this. AFAIK, only rico does infinite scrolling and it does not offer this level of features. EXT might do this now as well?
As for the dojo comments especially the erudite phrasings of Mr. ajaxianer esq, may I suggest that /. be a more suitable place for blatant trolling. Ajaxians are an altogether more boring bunch and your comments will only usually be met with reasoned, researched and polite reponses.
I completely disagree that this is too slow… it isn’t fast by any stretch of the imagination… but it is also incorporating a lot of features not found in other libraries… i was most impressed personally with the flexibility in display… the ability to insert things like buttons and re-organize row data out of the box really touches on the needs to developers for this type of tool… having a “details” view particularly with inline editing greatly improves the possibilities of this product…
my vote personally is still for Ext because its a more packaged solution at first glance… but i’m comfortable with this solution as well… it works well on FF/IE win… and frankly for a web application framework I have never agreed with the explicit need for support of auxiliary browsers… its nice… but unnecessary… as long as a user of a Mac or a PC can view it equally well in some form it serves its function properly…
Dan, we’re working to resolve the exact issues you mention, as noted in the blog post below. We expect that it will not be possible to make such claims about Dojo performance out of the box with the very next version of Dojo to be released in 2-3 months (with alpha and beta versions coming between now and then).
http://blog.dojotoolkit.org/2007/02/15/dojo-042-and-beyond
1. dojo core will consist of a tightly constrained set of lower-level APIs that make JavaScript better as a language and make DOM manipulation easier. All code in the core (and its widget-focused sister project, dijit) will be required to meet stringent quality, testing, and documentation standards. Most of the code currently in Dojo’s utility namespaces is being pored over and most will be either discarded outright or moved to dojox. The resulting core will be very lean, stable, and fast. I will continue to be the project lead for the core effort.
2. dijit is the new home for the “official†widget set. Not all of the current widgets will make the cut for Dijit and only those that are accessible, internationalized, themed, tuned for performance, and agreed to be generally useful will be part of Dijit. The widget system is being significantly streamlined to support this effort. APIs for base widgets are being rationalized, the inheritance hierarchy drastically simplified, and the page parsing infrastructure scrapped in favor of a much higher performance approach demoed at 3D2. Bill Keese, the uber-capable and dedicated module owner for the widget system, will become project lead for Dijit.
3. dojox will carry on Dojo’s strong tradition of invention. Many of the most important Dojo modules push the edges of what’s possible and have helped to bring the theoretical into the plausible over the last 2 years they will be allowed to thrive in dojox without the restrictions placed on core and Dijit code. Dojox will impose fewer restrictions and regulations on projects developed there. Far from being a second-class code ghetto, dojox will be home to important modules like dojo.storage, dojo.gfx, and dojo.charting.
Dylan, 0.4.2 sounds like a major revamp of the code in the right direction, can we expect new, complete and helpful documentation as well? When I researched dojo I found it’s documentation leaving me clueless as to how to actually use the framework as a whole effectively.. It is very different from the typical JS library and I think some common practices and general usage guidelines would make it’s adoption much easier.
Hey Colin,
0.4.2 is a small maintenance release for 0.4.1, but 0.9 is the beginning of a fairly drastic overhaul of all of Dojo.
And yes, you can expect overhauled docs. We’re almost done w/ a new website which will move everything into a single structure so it will be much easier to follow.
Regards
Nice set of feature - the ‘feel’ could perhaps be improved on a little.
Check out the IT Mill Toolkit Table as well - the one in the ‘Features’ demo app (Feature Browser -> Table) is, as the name indicates, more of a pure table than a grid, but it has some neat features, works well, and looks great. Scrolling 100000 rows is no problem, although the demo only sports 300 rows (download and try - I have, and it works great) - it lazy-loads rows, pre-caching some for smooth operation.
I am not sure how people can claim a table actually 100,000 of row when it really only supports 100. The “infinite” scrollbar is a nice trick, but it really doesn’t mean you locally have 100,000 items in the table at once. I picture doctor evil saying “My table support 100 billion rows”. This claim wouldn’t be anymore of a stretch than 100,000
If the data was coming from a complex query that took some time to complete, it would degrade the performance of the table to be almost unusable.
I do like the table though.
Actually, not having 100000 rows ‘locally’ is the point of these tables - anyone can shove 100000 rows into a html table in a scrolling div, but that’s not going to work very well either, is it?
What these tables do is actually solving your complex query -issue: you can’t speed up the query, but you can speed up the result viewing significantly; once the query has completed you can for instance use cursors to retrieve just the rows you need - the query won’t be run over and over again. So if the user estimates that the row he’s looking for is almost at the end of the result (and guesstimating can be much quicker that running an even more complex query), he can scroll down those 99900 rows just as quickly as scrolling 100 rows, and only the (say) 50 rows actually needed to be retrieved and transmitted over the network.
That’s the point of supporting 100000 rows (or 100 billion, if your application can handle it.)
Personally I don’t care for these infinitely scrollable type interfaces. I think Yahoo! does it best with their mail app, but even then it’s too easy to get lost. I much prefer a paginated view, with a search as you type input box above. I use this on all my listing pages.
I completely agree with “Dubiousdavid”, this technique is not very intuitive.
* No reference of where you are
* Not standard UI practice
* No way to get back to the last set of view data.
* Hard to control where to go
* Very chatty
Pagination would be a better way to go about it doing paging.