smartable

Smartable Data Types

Table of Contents


Supported Data Types

The data types that can be declared in the table definition are the following:

If no data type is specified for a column, it is assumed to be of a str type.


Internal Representation of a Value

With the exception of the num (and some forms of the date) all other types are essentially strings.
The difference is largely in how the values would be compared to each other when doing sorting or filtering operations.
It is, therefore, important to make sure the column definition contains the right data type, if the operations of filtering and sorting are expected to perform correctly.

Since JavaScript does not have native means of comparing “integer ranges” or “IP addresses” or “version strings”, the smartable framework attempts to solve this by creating several different internal representations of the initially supplied value (during the initial data loading). Later, depending on the operation being performed (sorting, filtering, regex matching, etc), the appropriate representation of the initial value will be picked for a particular operation to make sure the results are as expected.

Below are all of the possible representations of the initial value and a brief description of why they could be needed:

It is not expected that all (or any) of these representations should be supplied together with the initial (raw) value, since most of them can be automatically derived from the initial value (unless special/unique representation should take place and it cannot be automatically obtained by the ordinary logic).

The smartable code takes care about creating those representations for a given cell (normally, once only during the initial data normalisation step). However, if needed any of those representations can be explicitly provided as a part of the initial data load (in the converter function). The supplied representations will be used directly without trying to obtain them automatically. This is quite often the case for the .html representation, where the original raw value could be quite different from what should be displayed in the table (it could end up being an HTML link containing the original value or even an image based on the original value, etc.) but the raw value would still be used for row sorting and filtering.


Automated Parsing of the Initial Values

In certain cases the conversion to various representations relies on how the initial value really is really formatted.
This is especially important when certain data type can take various known forms (such as the date or range or ip).
The following principles will be used by the automated conversion routines:

  1. The column data type (defined in specs as a table definition) will always be considered as the basis for all conversion logic.
  2. Non-trivial data types (i.e., not num and not str) must have their initial value formatted in one of the ways that smartable understands (see below).
  3. Any of the representation(s) (like .cmp or .match, etc.) can be user-supplied but they must correspond to the implicit requirements imposed by the chosen data type.
  4. If the supplied representation does not fit the type requirements (for example .cmpMin for a str), it’ll be ignored.
  5. if the supplied value type or its expected formatting does not match the defined type, and the automated conversion is impossible, the representations will be set to a special bad value (see below).


Expected Formatting for Special Data Types


Internal Representations for Certain Data Types

"1.2.?.9876543.omg.9-bUiLd-7"  becomes  "·····1·····2·····?987654···omg·····9bu·····7"
"1.13.7"                       becomes  "·····1····13·····7··················~~······"
"1.13.7-rc12"                  becomes  "·····1····13·····7··················rc····12"
"1.131.7-a-z3"                 becomes  "·····1···131·····7··················a~····z3"


Bad Values Handling

When the supplied data does not match the defined type, it needs to be handled in a special way.
First, a check is being made if the automated conversion could be possible (typically for some num or str values).
When the auto-handling is impossible and/or the actual value is something like undefined, NaN, null or is a JS Object or Array, two decisions will have to be taken:

With regards to the .html representation of the bad value, the following logic will be used:

In addition, to the above, a special CSS class name will be automatically applied to each cell containing a bad value.
The class name can be defined as cssClass.badValue in the specs, however, if omitted the default value of -smartable-bad-value will be applied.

Every time the .html representation is assigned a value that differs from the original value (because the original value ended up being bad), the .match representation will also be automatically adjusted. This would be done to allow filtering and string matching to function correctly and actually match the bad value itself. Keep this in mind, if the .html representation is generated to be a custom value - it will be overridden by the smartable for a particular cell, if the cell value is determined to be bad.

With regards to the .cmp*/.mask representations of the “bad” value, the following rules will apply: