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 unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. 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.
