Attribute type hinting

[nicolaskruchten]

Idea: we could add a parameter to pivotUI() to indicate the type of the data for a given attribute, for example "string" vs "number" vs "date".

• The UI could use this information to provide better filtering options in the filtering menu: numerical or date ranges for example.
• The aggregators could also declare which types they can operate with (i.e. sum doesn't operate on strings) so the UI could not show certain attributes in the values dropdown when they are not supported by the selected aggregator
• The chart renderers could make use of this information by passing the hint along to get some nicer axes for time-series charts
• Not sure if/how the table renderers would make use of this information.

[jeremybarnes]

+1 on this.

For dates, it would be nice to add the ability to format them in a different manner than the standard toString representation. For example, toISOString(). The addition of the DOW in the default representation is particularly annoying.

Maybe it would make sense to detect homogeneous types for a given attribute and do some of this automatically.

[raaffaaeell]

+1. Looks awesome, that item 2 would be nice.

[eMaringolo]

+1 This would be perfect.

[eMaringolo]

Another option is to make these properties specific to each attribute instead of the "data type". Each attribute would have (or not) its own "options" object.

Ej: define if the attribute is sumarizable, orderable (min, max), countable (can be counted, counted as different), categorizable (common/distinct values), etc. And then each aggregate function can check against this "options object"

E.g. You can't sum or average two dates, but you can get MIN/MAX values for those, and also if there is a common date.

If wanted or needed, or just for simplicity, the datatype can be used as a convenience way of specifying a whole set of options. So Date and String are orderable and categorizable, but not sumarizable. Then the aggregate functions can check against them.

Also, the introduction of this "attribute options object" can be used the to determine whether an attribute can be used as row, column, none or both.

Regards.

DISCLAIMER: I just found out about PivotTable.js. But in the past I implemented similar pivot/aggregation table (not in JS), and used the above proposed solution with no shortcomings during several years. Including support for automatic attribute "subgrouping" (date/weeks/month, range, etc.)

[dave-killough]

More attribute configuration would be great. In particular, I would like to suppress some attributes from being selected as rows or columns (like dollar amounts) and others from being selected for aggregations (like GL codes). I think it's confusing for users to have fields where they make little sense. For the simplest presentation, each attribute should be either a dimension or measure.

[ilyaguy]

Yet another idea: derived attributes will return not only attribute label (string) but return array/object:

{
  label:  "Label of attribute", 
  type:   "number/string/date", 
  format: "int/money/percent/string/date" 
}

And aggregator/renderer will use these values to process data.

[ilyaguy]

In my own aggregator I implemented format selector based on additional array.

var fTypes = {
   "Registrations": "#",
   "Confirmations":"#",
   "Revenue": "$",
   "Revenue per Registration": "%"
}

I've pass the chosen value ("#", "$", "%",..) through getFormat function.

    function getFormat(short) {
        if (short == '%') {
            return $.pivotUtilities.numberFormat({ digitsAfterDecimal: 2, scaler: 100, suffix: "%" });
        }
        if (short == '$') {
            return $.pivotUtilities.numberFormat({prefix:'$'});
        }
        if (short == '#') {
            return $.pivotUtilities.numberFormat({digitsAfterDecimal: 0});
        }
        return $.pivotUtilities.numberFormat();
    }

And in the pivot table I've got pretty formatted data.

[chaouiy]

Any news about this killer feature ?