Setting the page size dynamically might be the best solution for my situation.
I have lots of top-level nodes (thousands) and some of them... maybe 5% will have 2-8 children nodes. Nodes are never more than 1 child deep. I need paging, but don't want to adjust what page an item is on due to opening or closing nodes. I will look into setting the page size dynamically... Daniel, please let me know if you get a chance to test this and how it goes. Thanks! -Brad On Nov 25, 7:43 am, dflorey <[EMAIL PROTECTED]> wrote: > Another option would be to set the page size dynamically to the number > of visible children of the opened root node. I'll give it a try and > see if it makes navigation more intuitive. > If you end up with many many child nodes you'll see that paging is not > the worst possible solution (as rendering times will not esceed a > certain level) ;-) > > On 25 Nov., 14:34, Brad Larson <[EMAIL PROTECTED]> wrote: > > > I've been following this patch because the app I'm working on will > > really benefit from it. > > > Ideally, I do not want children to fall off the list to the next > > page. My table will start with all children collapsed. When the user > > opens a node, I would like for new rows to show up on the table. My > > table will already have a vertical scroll bar, so I'd like the nodes > > below to just scroll down a bit. I don't want to move what pages in > > the table items appear on because of opening/closing of nodes. > > > Not all use-cases will be like this, but that is what would be best > > for my app. Maybe a setting could be added to define the paging > > behavior when nodes are opened? > > > Daniel - great work on this patch. I'm very excited to pull it into > > my project! > > > Thanks! > > -Brad > > > On Nov 25, 7:10 am, Bruce Johnson <[EMAIL PROTECTED]> wrote: > > > > Looks cool, Daniel. I do have a question about its basic usability, > > > though. > > > It seems that the combination of tree + paging is a recipe for end-user > > > confusion. When you open a tree item with lots of children then advance to > > > the next page, you see the children, but lose context on what its parents > > > are. > > > Anyone have thoughts on how we could address that? > > > > On Mon, Nov 24, 2008 at 7:09 AM, dflorey <[EMAIL PROTECTED]> wrote: > > > > > Hi, > > > > I've put together a live demo for the TreeTable stuff in my branch. > > > > You can find the demo link in the wiki page that I've created > > > > containing a minimalistic tutorial: > > > > >http://code.google.com/p/google-web-toolkit-incubator/wiki/TreeTable > > > > > As you can see from the demo I've simplified the table creation by > > > > adding header information to the column definitions, providing typed > > > > column definitions with proper filtering, sorting and editing. > > > > The tables can now handle implicit data and header table creation, so > > > > creating a TreeTable is now as simple as can be. > > > > I've migrated the ImageBundles to ImmutableResourceBundle, localized > > > > the strings by using i18n Messages and used CssResource for styling. > > > > I've moved all classes required both on client and server side to the > > > > share subpackage and added an ant task to create the gwt-incubator- > > > > servlet.jar containing these classes. > > > > > Any feedback is welcome! --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
