Follow-up to #1866610: Introduce Kwalify-inspired schema format for configuration
Here are some thoughts/questions/suggestions related to the typed data API integration of the config-schema:
- It looks like system.schema.yml re-defines all the simple typed data types. Is that necessary? Looks like a duplication to me.
undefined:
label: 'Undefined'
class: '\Drupal\Core\Config\Schema\Property'
mapping:
label: Mapping
class: '\Drupal\Core\Config\Schema\Mapping'
sequence:
label: Sequence
class: '\Drupal\Core\Config\Schema\Sequence'We should bring this to regular and proper registered typed data types, e.g. provided by config module. However we need to prefix them with config or make sure they generally make sense. Undefined does, but I'd call it "unknown" - undefined usually means something is null.
The current way of adding typed-data types without registering them is problematic I think. Imho it would be a safe assumption that any type you get from $typed_data->getType() is an actually valid, thus registered type.
Can't we bring the type-registries together, or do we need one in yml also?
$this->definition['mapping']
Are they keys added to defintions by the config system documented somewhere?
- The patch implemented TypedData::validate() methods although that part of the API was not yet finished. It needs to be reworked once #1845546: Implement validation for the TypedData API lands.
$configuration += $type_definition;
return parent::createInstance($plugin_id, $configuration, $name, $parent);This was done by the original manager also, but we did away with it during the performance optimizations as this leads to loads of duplicated array copies in memory.
if (is_string($value)) {
$definition['type'] = 'str';
}
else {
$definition['type'] = 'any';str? I've not seen that elsewhere, maybe wrong?
For performance, I'd suggest using TypedDataManager::getPropertyInstance() wherever possible.