Problem/Motivation
Some storage clients exactly know the data they are dealing with and they also know what their id field is. On the user side, the name of the id field may not be obvious. Furthermore, some storage clients may not be able to load data without a correctly mapped id, and could not provide an example data structure with the external entity manager module (inspector) and the user would not know what field can be mapped. In such cases, having the storage client being able to automatically map the id field would be useful.
On the other hand, some id mapping may require complex expressions (I met the case where the id value is not a field value but part of it, like in the full URL to the entity for instance, and a substring of that field must be extracted to get the id to use). And there might also be a problem when multiple storage clients are used (with a data aggregator): which client id mapping should be used then?
And what about title fields that are also required?
Proposed resolution
Add a method to storage clients that returns the field name to use to map the identifier field or an empty string if it is not available. That method could have a 'field name' parameters to handle other fields when possible, such as title or language. Maybe the return value should be an array with the field name or a mapping expression, with a field mapper id and config and a flag telling if it should override user settings.
Add a similar method to data aggregators that will be called by the external entity type class on saving, to set the field mapping if it is not set.
Remaining tasks
Open to discussion and opinion expressions...
User interface changes
None.
API changes
New methods for storage clients and data aggregator but which can be provided by base class to avoid existing clients modifications. The new behavior should be documented.
Data model changes
None.