Formula Field Internal Name

[oscarlondoņo]

Hi, dear Isomorphic!

In our application (which used SmartGWT 4.0 Pro), after getting the state of a ListGrid (listGrid.getViewState()), we used to identify computed fields within the JSON by utilizing the predefined prefixes in their names: formulaField and summaryField. These prefixes were consistently followed by a consecutive number, such as formulaField1, summaryField4, and so on.

However, now we are using SmartGWT 13.0 Pro, and in this version the behavior has changed. Now, the field names are composed by concatenating the corresponding title with the consecutive number (you can check that in the Manual Saving example). For instance, if we define the title as 'Balance' for a computed field, the resulting internal name will be 'Balance1'.

We kindly request a modification to revert this behavior and reintroduce the use of the 'formulaField' and 'summaryField' prefixes.

Additionally, we would like to bring to your attention that the CanFilter property is currently set to 'false' by default. We would appreciate it if you could consider changing the default value to 'true'.

Thank you for your attention and assistance in addressing these matters.

[Isomorphic]

The format and contents of the viewState is undocumented by design, so unfortunately, anything you were doing with it in terms of parsing it or modifying it is unsupported.

If you let us know what you were trying to accomplish, we can suggest an alternative, supported approach.

We're not sure what you mean as far as canFilter. It remains unset by default, but it is defaulted to false for formula fields, since filtering for formula fields cannot be performed unless the entire dataset is loaded. What behavior were you hoping for here?

[oscarlondoņo]

The Json that is obtained from the state of the view is only stored in the database for reading purposes (it is not modified) and, later on, it is used to obtain specific data. Particularly, formula fields are obtained to be used within a stored procedure in the DB and for this reason it is important to be able to easily identify them.

Regarding the formula fields with filters: it is clear that the dataset must be loaded to be able to use formula field's filter and, therefore, we save the state of the view. After saving it, the view is reloaded to have the field enabled so that the user can apply filters (this was the normal behavior of our application); but now it appears disabled, even after reloading the previously saved view.

[Isomorphic]

This means you have written code that is dependent on undocumented, internal details. It also sounds like you are parsing the formula string and creating a stored procedure from it, which is why you would want filtering enabled.

To do this correctly, without relying on undocumented internals:

1. invoke the FormulaBuilder yourself, based on your own custom menu option

2. create a field from the data, possibly using field.userFormula or just generating values using your stored procedure