The treegrid sample is in SVN -- Wow

[durlabh]

I don't know why anyone should even require a tree w/ paging for any situation.

especially when children are being fetched lazily

Everybody's use-case is different. In our example, we have a tree of around 100,000 rows and MaximGB Tree Grid works absolutely fine with it. There are more than 5000 root rows.

[TommyMaintz]

Most of the Store based plugins will work (with some minor changes to make use of the relational store capabilities) with the future TreeStore. Although the only useful one I can think of is filtering, which will be easy to do with a TreeLoader. You could either locally filter, or send params to the Loader.

We are still internally discussing the exact relational functionality we want to add to Stores. As soon as we have a clear vision ourselves, we will definitely discuss this with the community to get feedback before we start implementing it.

With regards to the ListView, it indeed will probably be based on a single table design. Although there will need to be a div around the table, to support the scrolling of the body on other browsers then FireFox. I already have a working prototype to see how this would work, and my current finding are looking very promising. A lot of improvement in terms of rendering speed, and also new capabilities that are not really doable with the current markup. Also like I said, the TreeGrid and new ListView will be able to reuse a lot of code in areas like column hiding/showing, resizing, dragging & dropping, header menu's, sorting and probably even editting.

[durlabh]

IMO, Development/ enhancement of stores is separate from the widgets. For example, ListView might not need a relational store.

In general, what I suggest is taking advantage of the community here. Putting the test versions (may be obfuscated code) with regular builds on a site where users can test/ give feedback and plan their work around next release cycle.

[durlabh]

With regards to the ListView, it indeed will probably be based on a single table design. Although there will need to be a div around the table, to support the scrolling of the body on other browsers then FireFox. I already have a working prototype to see how this would work, and my current finding are looking very promising. A lot of improvement in terms of rendering speed, and also new capabilities that are not really doable with the current markup. Also like I said, the TreeGrid and new ListView will be able to reuse a lot of code in areas like column hiding/showing, resizing, dragging & dropping, header menu's, sorting and probably even editting.

Any news on this yet?

[mjaomaha]

I have had some thoughts about the column tree model. My project that I am working on has some pretty advanced requirements, and I think that the tree grid could be somewhat simplified if you were able to build a small component that could live in each table cell, including the header cells.

But to let you know specifically what would be really nice to have on the table grid, here are some of the things we would really be able to use...

• Multi level headers, much like the google web toolkit offers.
• Being able to dynamically add or remove a column.
• Column re-ordering.
• A good multi cell selection model.
• Being able to imbed a custom component in a table cell, that would automatically resize to it's parents size.
• Allow for a row icon or header icon for each row or column, with the ability to dynamically change it.
• column locking.
• allow for rows to have varying heights based on content, and still have the tree nodes on the left adjust appropriately.
• Customizable listeners on a per-cell basis (double click, right click menu's etc)

Thanks. I do like the tree approach, because the data structure most closely represents the primary data structure of the tree grid, and I love how you can customize a tree node with a specific look, so different types of rows display differently.

mjaomaha

[grzegorz.borkowski]

With regards to the ListView, it indeed will probably be based on a single table design. Although there will need to be a div around the table, to support the scrolling of the body on other browsers then FireFox. I already have a working prototype to see how this would work, and my current finding are looking very promising. A lot of improvement in terms of rendering speed, and also new capabilities that are not really doable with the current markup. Also like I said, the TreeGrid and new ListView will be able to reuse a lot of code in areas like column hiding/showing, resizing, dragging & dropping, header menu's, sorting and probably even editting.

I've just looked at 3.2 beta demo http://www.extjs.com/deploy/ext-3.2-...rray-grid.html and the grid still renders as an ugly mess of nested tables... is it planned to have grids rendering fixed in 3.2?

[durlabh]

After long discussions internally we decided to go for extending TreePanel, since we believe that it lies closer to what a treegrid actually is. It is a tree structure, with additional columns for each node. Also, extending TreePanel, the code is much cleaner and easier to understand, since GridView is very complex.

The reason I haven't added store capabilities is because the TreeStore will be build using the store relational functionality we have planned for 3.2.

Once we have a TreeStore, I will add more functionality to the TreeGrid, like Editors, DataWriter capability, etc.

Also in 3.2, ListView will get a big overhaul and both TreeGrid and ListView will share the same a great deal of functionality (column resizing, column dragging & dropping, sorting, column hiding/showing, column tpl's etc).

With regards to the paging capabilities, I think there would first need to be a consensus on how it will actually work. Would you page per node, from the root, how would you drag and drop nodes from one page to the other, etc etc.

Please let us know what functionality you think is missing (besides stores, paging, column d&d and editors) from the current TreeGrid, and we will do our very best to make it happen in the near future.

Is there an update on this?

[grzegorz.borkowski]

Still no comment from Ext team... Ext 3.2 is out, without fixing the grids... Can we hope to have it in 3.3? Pls, this is really important! We build the application in Ext to have it work fast, really fast compared to classic web applications. But Ext builds so heavy and coplicated DOM structure, that slower browsers (IE, FF) render the changes in UI so slowly... sometimes I have impression that if I have built the app in "classic" way and serve pages from server, it would work faster, because I would generate 10x simpler HTML than Ext builds... From time to time I have the impression that Ext development concentrates on adding new fancy gadgets, instead of focusing on fixing the existing ones. I see performance improvements in 3.2, but if you simplify the DOM Ext generates, the results would be much much better. Single-table based grid is a must. I can't understand why it was ever designed different way? It's current state it's horrible. I really hoped to have it fixed in 3.2

[joeri]

I wrote an ajax grid before I switched the front-end code out to extjs grids, so I have some experience building grids. I can tell you that scaling up a basic html table to the needs of a rich grid control is not simple. First of all, if you want to put arbitrary content in a td, and have the td clip the content when it becomes too big (possibly with scrollbars), you need to put a div inside the td. At least, I didn't find another way to do it at the time. This is what extjs does. Then, for scrolling the body independently of the header, you need two separate table tags, one for the header, one for the body. Yes, there are ways to use a thead section, but getting those to work in all cases on all browsers is not possible (that I know). Finally, the extjs grids can alternate grid rows with arbitrary content. I can imagine this is very difficult to do without making each row a div (like the extjs grid does).

Anyway, my point is: if it's so simple to reduce the grid's dom complexity without limiting its feature set, let's see some code first.

[grzegorz.borkowski]

Definitely, you need two tables for grid: one for header, one for body (it's possible to do it with one table on firefox, but it causes other problems). But not separate table for each row. One table for grid body versus one table for each row, makes BIG difference from performance and memory point of view. I can't imagine any use case for using separate tables for each row. For "alternate grid rows with arbitrary content"? well, I guess you can colspan all the TDs in one row, put DIV into it and the result is the same.
Regarding clipping the content of cells using DIVs - perhaps you right, though I'm not sure. Text-overflow should work on TDs too. But perhaps it's the silly IE6 problem in this case.