Community
Participate
Working Groups
Build Identifier: HEAD After a short discussion http://dev.eclipse.org/mhonarc/lists/nebula-dev/msg01322.html I decided to try to extend the Grid to allow for dynamic, user-defined footer texts. I'll attach a patch that enables a GridTreeViewer to display footer texts that are recalculated on every refresh. There may be an IAggregateProvider attached to a GridColumn and the Viewer will present any displayed (that is, selected by the filter) row to that aggregator. When done, the Viewer asks the aggregator for the text, font, and colors to be set on that column's footer. The user may also specify what rows need to be presented to the aggregator: 1.) top-level elements 2.) leaves If only top level elements need to be aggregated, the viewer needs not completely walk the tree. I'm still not sure whether I started at the "right" points and I'm especially uneasy with overriding the refresh() method as a hook to recalculate the footers. It seems that it works fine, but is that efficient? Also, the main functionality is built into the GridTreeViewer, but the aggration options are set on the GridColumn and Grid itself. To enable similar functionality in the GridTableViewer we'd have to duplicate that code... There's one more design "flaw" at this time: I first thought that it would be possible to make Grid itself handle all the footer calculations -- but the Grid doesn't have access to the raw values "behind" the cells (e.g. BigDecimal), but only to the formatted cell texts. The aggregator would have to parse that information and... I dismissed that approach. So, now the IAggregateProvider gets the whole row object and needs to extract the information it needs. To use the bundled NumberSumAggregateProvider, you'll need either a) Numbers as elements of your model, or b) another wrapper IAggregate that will extract the Number data from the actual model and pass it down for aggregation. Reproducible: Always
Created attachment 186000 [details] Suggested patch (work-in-progress I guess)
Overloading refresh() is not enough because one can also modify things using add, remove - I also think setFilter(), addFilter() is not going through refresh() as well as sorting. I'll try to take a look at this and give you much more qualified feedback when I had a closer look.
The filter operations (addFilter, setFilter, ...) all do explicitly call refresh() in any case. Ordering should not have an impact on the calculated aggregates. add()/remove() do indeed not call refresh(). Thank you for looking into this!
Not for aggregation but probably other functions which operate on the order of things.
I admit I have not read the comments or the patch code submitted. I just wanted to put my $0.02 in. I do aggregation on my GridTreeViewer - but I base it on data from the column that tells me to total it or not, how to format it, and if I have selected rows I only total those records, vs. all the records if none are selected. I'm sure what I've done can be integrated (to some degree) with an API to make it easier for me (i.e. recalculateFooter(IStructuredSelection) override and ability to set column totaling information - $$ amounts, percent calculations, quantity (# of units) - note they have different formatting requirements....and the ability to do this based on content and selection changes). If you'd like more info on what I did, I'll be happy to provide you with the info and my thoughts on what might help in terms of a common API that can be used by others. While something would be great to have built in, don't remove the ability for us to "roll our own" if the one you provide doesn't "do it" for us please!
In preparation for the upcoming transition to Mars, I've ported my patch to the current head. For now, I'll be maintaining my changes at my Github Fork: https://github.com/hannibal218bc/rap/tree/_hannibal218bc The changeset is not yet fully tested. In short, the base idea is to override refresh(Element) and update the footer texts. Sharon, I'd be still interested to hear how you solved that. With the current public API of the GridTreeViewer, I don't really see how an automatic calculation could be implemented? The ContentProvider has no way of knowing what items are currently displayed, the Filter has no way of receiving updates; the only way would be to add a change listener to the ContentProvider, filter the elements once more and update the footers then?
I left that job a couple of years ago and, unfortunately, have not been working with Eclipse much. However from what I remember of what I did, I added some data to the column definition that would tell me that a column was to be summed, averaged, displayed as a percentage, dollar amount, etc. Sorry - but that is about all I remember.
This bug does not have a target milestone assigned and is automatically closed as part of the 2.3.0 release cleanup. It could be that this bug is accidentally closed for which we apologize. If this bug is still relevant, please re-open and set a target milestone.
