Hmmm...
It's a pity, that the TreeGrid is Tree-based. I think it would be better to have a tree, based on a normal grid and store (instead of a loader) with filtering and so on. So I will use MaximTreeGrid in Future, because of it's store/grid-based technology :-(
I felt the same! I'm going with MaximTreeGrid as well.
Jay: Kind Bump...Originally Posted by jgarcia@tdg-i.com
its a real shame it doesnt use a store
+1 for maximtreegrid
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.
It is good that you want to publicly discuss this now. However, it'll be really helpful if you can first share the re-factoring planned for ListView. I hope that it'll be based on Single Table (or Dual Table) architecture similar to TableView created by Animal. If that's the case, it'll be really helpful.
As for paging of child nodes, I propose 2 things:
1. Customizable icon that indicates on a node level that it is paged
2. 2 Paging bars. 1 for the root nodes and 2nd one to be configurable to be floating or in top bar/ bottom bar.
On a side note, we were disappointed with TreeGrid because it means none of the Grid extensions will work for it as it is not Store based. It can be worked around. However, you can take full advantage of the community by discussions or at-least sharing more info. about these things on the planning stages itself. I know it may be impossible to come to a consensus but you can get some creative ideas before everything is frozen.
Looking forward to the TreeStore!
I've managed to work around the fact that it's not store based, and after a couple small bugfixes that Tommy was kind enough to take care of, it's working quite well in my project now.
Big thanks to Tommy and the Ext team for a great component!
Sorry tommy, just one other thing:
You are only creating the Ext.ux.tree namespace in TreeGridSorter.js.. this has caused problems on certain browsers (namely Firefox on Mac and Linux) where the files are being loaded in a different order.
Very interesting to hear about the TreeStore roadmap. I wonder if you could expand a bit more about what the relational store functionality would actually entail. Is this just the ability to have row relationships, or is it a full-blown pseudo-SQL construct?
Wrt paging, I don't think you will get a truly usable UI design for that. The best I can think of is having a bounding box around the child nodes with a paging bar integrated into it. I would place more value in a buffered tree view, that only renders the visible nodes. Combined with livegrid-like smart loading, this should be sufficient to scale to even the largest trees.
I don't know why anyone should even require a tree w/ paging for any situation.
especially when children are being fetched lazily
Posting Permissions
Reply With Quote
