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.

Turbo Grid 3

Posted by Dion Almaer at 4:36 am

2.7 rating from 38 votes


Comments feed TrackBack URI

fucking slow fat Dojo-crap..this grid crashes my OPERA every time i load it…fuck’n waste of time!

Comment by ajaxianer — March 20, 2007

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

Comment by Alex Russell — March 20, 2007

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.

Comment by anotherview — March 20, 2007

“aybe its how structured and Java like the framework is” maybe it just doesnt matter coz its fat and slow crap?

Comment by ajaxianer — March 20, 2007

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.

Comment by Adam Sanderson — March 20, 2007

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.

Comment by Dan — March 20, 2007

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.

Comment by rishson — March 20, 2007

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…

Comment by Owen — March 20, 2007

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

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.

Comment by Dylan Schiemann — March 20, 2007

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.

Comment by Colin — March 20, 2007

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.


Comment by Alex Russell — March 20, 2007

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.

Comment by Marc — March 21, 2007

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.

Comment by Robert Buffone — March 21, 2007

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

Comment by Marc — March 21, 2007

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.

Comment by Dubiousdavid — March 21, 2007

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.

Comment by Robert Buffone — March 21, 2007

Leave a comment

You must be logged in to post a comment.