Computed values not computed

Except with varchar fields.
I have done a little bit debugging and found out, that, for integer fields, preSave is called for the parent classes only :(
Seems to be a misconfiguration in this module or a bug in core (I guess the latter).

But that does not explain, why computed fields added afterwards are never computed.

Below you can find two patches that may solve the following problems:
1. Numeric values are never calculated
2. If you add a computed field to bundles with existing content, these values never get calculated.

The second patch is a little trick. If you add a field of any type with default value to a bundle with existing content and that field is not displayed in an edit form, this field will stay empty. If you show it on an edit form, the value is saved as desired. So the second patch adds a widget for computed fields to enable (some) display on a form to save the computed value on form save. Later on, when all contents has been re-saved, you can move the fields to the disabled area.

This seems to work, but I have some intuition, that neither my patch, nor the whole module is following the Drupal-8-way of doing this. For example the method ComputedFieldItem->isEmpty() is called over and over again.

the problems with isEmpty are:

1. it is called for fields on the form only --> solved by adding a field widget.
2. $value = $this->get('value')->getValue() mostly returns the value before editing the form (or the default value). Only if it is called immediately before preSave, it returns the edited value. With the addition of the field widget (default values '' or 0), it always returns a non-empty value, so isEmpty always returns TRUE (if you set the default values in the field widget to NULL, preSave will not be called!)

My patch "Allow_numeric_values_to_be_created" is indeed superfluous, as the other patch solved the problem, too.

I rewrote isEmpty to always return TRUE and the field widgets are now always be hidden (by setting the #access-property to FALSE).

I have rewritten the module to provide native field types with built-in formatters for these field types. Here is an excerpt from the README.md:

# Computed field
## Description
This is a complete rewrite of the former computed field module to separate field types more precisely.
It now provides five field types, whose values are computed by PHP-code you provide in the field settings.

* **Computed decimal**. A numeric field type with precision and scale, and optional prefix and suffix.
* **Computed float**. Another numeric field type with optional prefix and suffix.
* **Computed integer**. This is a numeric field type for numbers without decimals, with optional prefix and suffix.
* **Computed string**. This is a character field type with a given maximum of characters.
* **Computed string** (long). This is like above, but with unlimited length.

Besides the data types this module also provides some field formatters for each type, like the core field types:

* **Unformatted** displays the value as is.
* **Default** allows to add prefix, suffix, thousands separator (numeric field types only)

All these formatters allow to set cache duration. By default, cache settings are left untouched (default) which is in most cases correct. But if the PHP-code consists of volatile elements, like time/date dependent values you should set the cache duration accordingly.

**Attention!**

> Unlike prior versions computed fields don't have a display code anymore. This is due to the fact, that display code is formatting and formatting is not field definition. But now you can have different formatters for different view modes.

## Usage

* Download and install the module as usual. No additional configuration is needed.
* Add the computed field(s) to your bundles.
* Go to the tab "Manage form display" and at least save the form. This is **necessary**, even if you don't change anything else!
* If there is currently no content of that bundle, you can safely move the computed fields to the *Disabled* area. But if there is content, don't do that otherwise the computed values for existing content would not be created. Normally the fields are not displayed in the form unless you have defined the computed field as *multiple*. Then an (almost) empty table with drag options appears. This seems to be "normal" Drupal behaviour. You can solve this only by moving the computed field to the *Disabled* area with the implications above.
* Go to the tab "Manage display" and drag the field into the correct order. Then you can select and configure the formatter. **Don't forget to hit the *Save* button to store your changes** otherwise they are lost.
* It's always a good idea to **rebuild the cache** if you are playing around with the computed fields.

## Additional modules
There are two additional modules you could enable:
### Computed field example formatter
This module provides an example to create your own PHP formatter for a computed field. To do so see below.
### Computed field PHP formatter
This module provides the ability to define the formatter code on the fly everywhere a formatter can be specified (this is also true for views!). As this can be dangerous, especially if users can define their own views, activate this module only if really needed. It is almost better to define the formatter in a separate module than on the fly!

## Examples
### See the difference between cache *default* and cache *off* or *duration*
To see the effects of caching you can follow this little example:

* Add two computed integers to the bundle.
* In both field set the PHP code to "`$value = time();`".
* Go to *Manage form display* and hit *Save*.
* Go to *Manage display* and set caching in one of the field to *off* or a certain duration. Leave the other field as is! Hit *Save* again.
* Add content or view existing content for that bundle.
* Refresh the screen.

Now you can see that one field keeps its value while the other field counts the time (in intervals you have set with the cache duration).

*This does not work if you have developer settings with caching set off!*

### Create your own PHP formatter
To create you own PHP formatter, clone the provided **computed_field_example_formatter** as follows:

* create a new module folder *modules/my_module* or (better) *modules/custom/my_module*.
* copy the contents of the *computed_field_example_formatter* folder to *my_module*.
* rename *computed_field_example_formatter.info.yml* file to *my_module_formatter.info.yml*. Modify name and description within the file as needed.
* rename *ComputePhpFormatterExample.php* file (in *src/Plugin/field/FieldFormatter*) to *myModuleFormatter.php*
* in this file change all occurrences of *ComputedPhpFormatterExample* to *MyModuleFormatter*
* In the annotations section *@FieldFormatter* change *id* and *label* to your needs.
* Modify the body of the method *formatItem* as needed.
* Install your module, or rebuild the cache to let drupal read in the annotations, if your module is already installed.

## Credits
@todo: add credits

@Martin (#6):
Indeed, if you add a field with default value to a bundle with existing content, you have to display the field on the edit form or you will never get the default value. This is true for core field types and also for custom field types. After saving all existing content everything seems to be ok. For new content, the fields do not need to be on the edit form. They are always created.

But this is not true for numeric fields :(
To create numeric fields with default values, the field *must* be displayed on the edit form. This is true for existing content as for new content.

"display" does not necessarily mean visible. You can add this field as a hidden field or set #access to FALSE in the render array of that field.

I was supposed to submit the complete rewrite as a patch, so I did. But if you'd better like to have the complete module, here you are.

Thank you for testing ;)

Hi Alessandro,

up to now, you have to use a text field as you would do with the D7 version. But it is a good idea, to provide a computed field for nearly any field type. But not now. First my current changes must be reviewed and populated to the module.

PHP-Code works for me without any problems. You must not enter PHP-tags!

The problem with null value fields is: they won't be displayed by Drupal, thus the formatter code never called. Each computed field must have a value in the database to trigger the formatter. I currently haven't found a way to solve this, so I can't and won't fix this.

Perhaps dealancer, as the maintainer of the D8 version, can take a look on my work to publish or discard the code. I'm currently not allowed to.

After that I can check if and how to implement additional features as requested in #15

@#20: If the field was added afterwards, it will only be populated if the form is shown (but only if the field is not in the disabled area, as I described in the readme.md). If the field already has content and you change the php-code, the bulk update should work.

Later I will update the readme.md when my rewrite is accepted and published by dealancer.