Thanks for your reply. I've tried various approaches with using a composite cell but not the idea of using one cell as a pseudo-table. That's definitely worth a shot.
On your second point, to be honest, I don't know that I've ever really been aware of the "TreeTable" concept as a UI device prior to the last few days and I don't have strong opinions on its usage. Saying that, it now seems to me that the canonical example might be the graphical file system explorer on your particular flavour of OS (for me, Finder on OSX) and in my 10-sec exploration, it seems to column sort on the root-visible nodes only (also). I'm far too biased at the moment but I'm also a fairly experienced GWT dev and personally, now that I'm aware of it, I'd welcome a TreeTable in GWT. It's anecdotal but I have noticed the requirement for this sort of thing cropping up more in the work we do, which is one of the reasons I chose to summarise the alternatives. On Monday, 28 January 2013 at 8:05 PM, Thomas Broyer wrote: > 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: > > > 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. > > > 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. > > > 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. > > > 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. > > > > > > > > > > > > > > > > > > > > > > > -- > 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] > (mailto:[email protected]). > To unsubscribe from this group, send email to > [email protected] > (mailto:[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. > > -- 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 [email protected]. To post to 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.
