At the moment the custom field api allows a field to essentially set and get a value, and it is assumed that the return value is fully formed html ready to inject into a page somewhere. There is no real way to extract and leverage data stored in the fields in a meaningful way because it has no strong type.

Each field has the datafield() method but this only says how the internal data is stored and has no real relationship with the type of the end data. eg it could be a date which is stored as an 'intvalue' but then converted into the string when exported. Or it could be an ISO 8601 date stored as a string and then displayed as html in the same way and you can't tell the difference from the outside and neither end result is an actual date.

I'm proposing to augment the existing api with a few more methods to allow the real data to be extracted which means it can be leverages in a much larger number of ways. 

Some examples:

• MDL-64815 - any fields which return a type of 'date' can be pulled into the calendar
• In other contexts a date could be manipulated or displayed in different formats, at the moment the format is controlled by the field config regardless of the context in which the data is used.
• A picture field could return the url of the picture as the raw data and the html of the image tag as the html version. Then the raw url could be used in different ways like as a background image instead of an image tag, or the image could be resized in different ways (see MDL-72140)
• In web services both the raw value (if it can be cleanly serialized) and the html value would be returned

To achieve this I'm proposing:

1. a new method which declares the type of the data, which would be from a list of strong types eg int, float, date, string, html, moodle_url, email, host, timezone, action_link, etc. These could be specified using one of the PARAM_xyz constants or a similar enum and the code leveraging the type knows it is safe to use in the same way. If the enum changes over time and the calling code can't handle it then it can always safely deal with the original html value.
2. this has a base implementation which defaults to PARAM_CLEANHTML so is backward compatible
3. a new export method export_raw_value() which returns the data in that type
4. customfield_checkbox returns PARAM_BOOL / bool
5. customfield_date returns PARAM_DATE (doesn't exist) and a date object
6. customfield_text returns either clean html, OR 'actionlink' and an action_link object depending on config
7. customfield_picture returns a moodle_url to the pictures src