10 Dec 2009 2:59 PM #21
10 Dec 2009 4:32 PM #22
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.
11 Dec 2009 10:44 AM #23
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.
12 Jan 2010 1:59 PM #24
25 Jan 2010 10:25 AM #25
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)
11 Mar 2010 6:38 AM #26
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?
12 Apr 2010 9:46 AM #27
14 Apr 2010 4:25 AM #28
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
14 Apr 2010 7:14 AM #29
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.
14 Apr 2010 7:54 AM #30
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.