Summary Functions for UserSummary Dields Don't Work

[oscarlondoņo]

Dear Isomorphics!

I'm facing issues with calculated text fields as the summary functions don't work as expected

1. I'm working with:
• SmartGWT 6.1
• built-in-ds (from SGWT)
• JDK 1.8.0_241
• GWT Eclipse Plugin 2.8.1
• Eclipse 2020-03 (4.15.0) Build id: 20200313-1211

2. Attached to this post are the files I used for showing the scenario and reproduce the issue:
• BuiltInDS.gwt.xml
• BuiltInDS.html
• buffers.data.xml
• BuiltInDS.java

3. I tried to use summary functions from a context menu, such as Count, Min, Max, Avg, and show result in group header for each field.
• This is the way I added the UserSummary field:

Map<String, String> summaryVars = new HashMap<String, String>();
        summaryVars.put("A", "Sku");
        summaryVars.put("B", "Location");

        UserSummary textSummary = new UserSummary("#{A}#{B}", summaryVars);

        ListGridField summaryText = new ListGridField("summaryField", "Summary Title", 100);
        summaryText.setCanEdit(false);
        summaryText.setCanSortClientOnly(true);
        summaryText.setCanFilter(true);
        summaryText.setAllowFilterExpressions(true);
        summaryText.setAllowFilterOperators(true);
        summaryText.setUserSummary(textSummary);
        summaryText.setIncludeInRecordSummary(true);
        summaryText.setType(ListGridFieldType.TEXT);

        final int fieldPosition = 4;
        addFieldAtIndex(summaryText, gridExample, fieldPosition);

• And this is the code for setting the summary function:

getSelectedField().setShowGroupSummary(true);
        getSelectedField().setIncludeInRecordSummary(true);

        Boolean isText = getSelectedField().getType().equals(ListGridFieldType.TEXT);
        if (isText) {
            getSelectedField().setSummaryFunction(new SummaryFunction() {
                @Override
                public Object getSummaryValue(Record[] records, ListGridField field) {
                    String summaryValue = "0";

                    if (function != null && function.getValue().equals(SummaryFunctionType.COUNT.getValue())) {
                        summaryValue = (records == null)
                                     ? "0"
                                     : records.length + "";
                    }

                    return summaryValue;
                }
            }); 
        } else {
            getSelectedField().setSummaryFunction(function);
        }

        gridExample.recalculateSummaries();

4. The video below shows the behavior:

Would you please help me with any approach to get that functionality working?

Thanks in advance for your support

Best regards,
Oscar Londoņo

[Isomorphic]

Thanks for the attempt to be thorough with your test case and video, but the most critical part is missing: what did you expect to see in the column where you have summary functions applied? Are you expecting that your summary is applied after the framework does aggregation, or that we aggregate the result of your summary for you?

Basically tell us what values to expect to see, and where.

[oscarlondoņo]

Thanks for replying back!


This is what I expect:

• If I apply a COUNT function in that summary text field, what I expect to see on each group header, is the number of records for the group.

• If any other function (AVG, MIN, MAX) is applied to that calculated field, I expect a zero (0) to be displayed on each group header.

Please, let me know if you need any other relevant information.

[Isomorphic]

UserSummaries are applied after aggregation, and this is by design, so you can apply UserSummaries to aggregates.

Allowing the other order seems like it would only gain you to the ability to use the "count" aggregate with a UserSummary, which is kind of needless since you could do that with any other field.

Finally, we don't agree that applying min/max/avg to a text field should show 0 as a result. It's a meaningless thing to do, so it should be left blank, as it already is. Any output would just be noise.

[oscarlondoņo]

Dear Isomorphics,

You are absolutely right; I think that your answer is enough to conclude that it isn't necessary that we spend time implementing that functionality, since the only thing that could be developed for that calculated text field, already works perfectly with other fields.

Thanks again for your answer, it was really helpful!!!

Best Regards.