Did you consider trying to vertical-align <div>s within each Cell so that a CellTree looks like it has columns? (similar to how the unread-message-counts are right-aligned in the trees in the left-hand side panel of Google Groups)
As a side-note, I've always been uncomfortable with column-sorting of tree-ish data, as in the screenshot you provided as example (and clearly the rows are not *all* sorted on the Total column, apparently only the root items). This is one reason why there's no TreeTable in GWT (there was a poll some time back, before TableBuilder was introduced, whether there was a real need for a TreeTable widget, and it appeared subrows in a CellTable, as in the Showcase, would be enough for most people, and others could use GXT or similar third-party widgets, or were already using them anyway; IIRC) On Monday, January 28, 2013 3:45:36 AM UTC+1, Andrew Done wrote: > > An update: I've spent a fair chunk of time looking at this now and know a > little bit more about the problem. > > Firstly, I now understand that by convention this widget is known as a > "TreeTable". There has been much discussion about a way that it could be > done and there are a few example of people that have tried to do it, but, > broadly, I think my original options are more-or-less valid. > > I've also spiked up what I can and hopefully have a reasonable > approximation of the suitability of each. > > For posterity, here are my notes: > > *(Note: I've deliberately excluded the option of using a composite cell > and a CellTable as its just not what I'm looking for. It would be worth > looking into though as an alternative to #1 above for simple use cases.)* > > *1) CellTable/TableBuilder based approach.* This seems to be the leading > example for use within CV. > The idea here is to use a bespoke TableBuilder to render the children of a > node and its surprisingly easy and efficient to get this to work. Their is > a good example of this technique in the Showcase and it essentially breaks > down to: > > - The TableBuilder, when given the opportunity to render a row, will > render itself differently depending on some state. In the example this is > a > list of open nodes. For the uninitiated, many rows can be added that > correspond to a single value (i.e. element in the provided data). > - Add a widget to the table that alters that state and forces the > redraw of the row. > > This would be a good and clean approach for a simple use-case like the > showcase example but gets complicated quickly for anything more difficult. > In my example, I needed to get data of arbitrary depth asynchronously, so I > used the expand/contract widget to call off for data and then #redrawRow(i) > on success. The issues here are: a) you're left managing data on your own; > and b) due to the flyweight nature of the CV system its difficult -- for > good reason -- to divorce a value from its rendered element, which means > the 'caret' widget, for 'inserted' rows will always get their parent's > value (making anything below 1 level of depth impractical). > > *2) CellTable with a funky tree-backed DataProvider.* > This seems really unorthodox but I think it could work out. The idea is: > > - Have a widget that knows how to render the name/caret with > appropriate depth and state (i.e. make sure open nodes are open and that > the parent/child relationship is obvious). > - Write a tree-backed DataProvider that keeps state for open nodes and > then simply inserts the children into the sequence (and then row) at at > the > appropriate spot. > > There's parts of this solution that seem really right (seems to keep the > complexity in the data structure, which is nice) but then other parts that > don't. Fundamentally though, a TreeTable is a 2D view (by virtue of the > fact that it will ultimately render down to a tr/td relationship) so it > could prove to be a good solution. > > *3) Use FlexTable or a bespoke HTML table.* > After the hassles I had with CellTable this was simple to get something > that did more-or-less exactly what I needed. Same problems as #1 though, in > that you're left managing your own data and dealing with either: a) a > relatively inefficient mode of rendering, in the case of FlexTable; or b) > needing to handle events and all the other love you get from widgets > somehow. For reference, though I'm going to continue to look into this > problem, this is the method I've gone with for our production use-case. > > *4) Write a TreeTable widget (that likely extends AbstractCellTree).* > This would obviously be the highest quality implementation but it seems > like there would either be a lot of duplication (as it is a true hybrid > between the existing CellTree and CellTable) or would require a lot of > refactoring to extract some common functionality. I've got a reasonable > understanding of how the data widgets hang together but someone closer to > it would probably be able to advise how practical this would be. > > I also spiked a halfway model, similar to CellBrowser, that uses a > specialised TableBuilder to render a CellTable into tbody and then wrapping > them up in a tree. I got far enough into it to decide that it was a > horrible solution but thought I'd mention it in-case anyone had a better > idea of how it could work. > > Anyway, that's where I'm up to and I'd certainly appreciate any feedback > from anyone else that's looked into the problem or can provide insight or > correction to my thinking. > > On Sunday, 27 January 2013 22:41:48 UTC+11, Andrew Done wrote: >> >> Hello GWT-Land, >> >> I am trying to create a view like the attached. >> >> Essentially, it's a hybrid between a CellTable and a CellTree; that is, >> the data exists in a tree structure but it wants to be represented >> two-dimensionally (in a table) with tree-depth displayed via an indent. The >> actual requirement I have is a very data intensive application and so >> ideally I'd prefer to use the Cell Widgets. >> >> As I see it, I've got a few options: >> >> 1. Try to hack something up with CellTable/DataGrid (ala the Showcase >> example). This isn't ideal as it seems difficult to then rely on the >> individual widgets to reliably manage data. >> 2. Use CellTable/DataGrid with: a) a Cell to indent the name (as per >> the attached) and decorate the value with a caret; and b) a DataProvider >> wired up to fetch data and insert it at a specified index. >> 3. Use FlexTable (or some bespoke table impl) and avoid Cell Widgets >> et al all together. This is what I'm currently leaning towards as it >> seems >> the most controllable. >> 4. Write a new widget -- likely extending AbstractCellTree -- to do >> what I need. >> >> I am of course hoping there's some simple solution I'm overlooking and so >> any help and/or advice would be greatly appreciated. >> >> Cheers, >> - Andrew. >> >> >> <https://lh3.googleusercontent.com/-F0ba4y5B9BA/UQUPWG31bPI/AAAAAAAAAA0/gO_rHuK0f-4/s1600/Screen+Shot+2013-01-27+at+10.25.36+PM.png> >> > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
