Magento 2 Backend – How Admin Icons Font Files are Generated

To create new configuration type, module developer should create a configuration type class that will be used by clients of configuration.

To make these type classes as simple as possible, all behavior of reading configuration files and caching data was moved to \Magento\Framework\Config\DataInterface with two reusable implementations:

• \Magento\Framework\Config\Data - for configuration types that only make sense to be loaded in one scope (eav_attributes.xml only in global)
• \Magento\Framework\Config\Data\Scoped - for configuration types that can be loaded on different scopes (events.xml - global and per-area)

Every configuration type is supposed to have pre-configured Config\DataInterface object. Configuration can be done either with Virtual Type or with inheritance.

Although module developer can technically inherit their configuration type from Config\DataInterface implementation, it's recommended not to extend from core classes. Always better to use composition.

Now \Magento\Framework\Config\Data and Data\Scoped only do caching and delegate configuration reading to \Magento\Framework\Config\ReaderInterface. ReaderInterface is supposed to provide valid configuration in format of PHP array for requested scope (if configuration is scoped). Multiple implementations of ReaderInterface are possible (for example read configuration from DB) but Magento only ships one generic reader: \Magento\Framework\Config\Reader\Filesystem.

\Magento\Framework\Config\Reader\Filesystem does all operations required for reading files from modular filesystem: read files, merge and validate.

Every Config\DataInterface is supposed to have separately configured instance of Config\ReaderInterface. As any instance in system, specific reader can be configured either with Virtual Type or with inheritance. Magento Documentation Describes all Filesystem dependencies.

Every element in this chain is optional (except for Config Type Class itself) and can be substituted with more specific implementation.

First of all autogeneration is happening based on class name suffix, e.g. Factory, ExtensionInterface (see \Magento\Framework\Api\Code\Generator\ExtensionAttributesInterfaceGenerator::EXTENSION_INTERFACE_SUFFIX) or Extension (see \Magento\Framework\Api\Code\Generator\ExtensionAttributesGenerator::EXTENSION_SUFFIX).

Proper generator is selected based on suffix here \Magento\Framework\Code\Generator::generateClass.

Let's assume Magento mode is developer and missing classes can be generated on fly (similar process will happen when compiler is used). When object manager tries to instantiate let's say Magento\Quote\Api\Data\CartItemExtensionFactory and it does not exist, the following happens:

1. Autoloader fails to instantiate class and initiates code generation here \Magento\Framework\Code\Generator\Autoloader::load
2. Then class suffix is determined as Factory (list of all declared suffixes can be found here \Magento\Framework\ObjectManager\DefinitionFactory::getCodeGenerator) and corresponding Factory generator class (Magento\Framework\ObjectManager\Code\Generator\Factory) is used to generate missing factory
3. All autogenerated classes are always based on another classes, in case of factory, source class name is calculated just by removing Factory suffix, it will be Magento\Quote\Api\Data\CartItemExtension. This class does not exist and autogeneration is invoked once again by autoloader, but this time for Extension class
4. Now suffix is Extension and \Magento\Framework\Api\Code\Generator\ExtensionAttributesGenerator will be used to generate this class
5. Source class for Extension class generation is calculated as Magento\Quote\Api\Data\CartItemInterface, it exists and Extension class is successfully generated. However, on the attempt to include Extension class file, autogeneration is triggered once again because Magento\Quote\Api\Data\CartItemExtension implements Magento\Quote\Api\Data\CartItemExtensionInterface, which does not exist
6. Suffix is ExtensionInterface and \Magento\Framework\Api\Code\Generator\ExtensionAttributesInterfaceGenerator will be used for generation
7. ExtensionInterface and Extension classes are generated based on information from extension_attributes.xml, accessible via \Magento\Framework\Api\ExtensionAttribute\Config, then Factory gets generated

One important note is that there is no preference for ExtensionInterface in di.xml because both Extension and ExtensionInterface are autogenerated. This is not a problem because ExtentionInterface is not expected to be injected via construct directly.