Magento 2 Argument Types

In today’s post, I’m going to gives you various information about Magento 2 Argument Types including the type configuration, constructor arguments, object lifestyle configuration as well as Sensitive and system-specific configuration settings.

Magento 2 Argument Types

Configure type

The type can be configured in your di.xml configuration node by following this:

<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:ObjectManager/etc/config.xsd">
    <virtualType name="moduleConfig" type="Magento\Core\Model\Config">
        <arguments>
            <argument name="type" xsi:type="string">system</argument>
        </arguments>
    </virtualType>
    <type name="Magento\Core\Model\App">
        <arguments>
            <argument name="config" xsi:type="object">moduleConfig</argument>
        </arguments>
    </type>
</config>

The above example declares two types which are Magento\Core\Model\App and moduleConfig

  • moduleConfig: This is a virtual type that extends the type Magento\Core\Model\App
  • Magento\Core\Model\App: In this type, all instances receive a moduleConfig’s instance as a dependency.

Virtual types

A virtual type enables you to change a specific injectable dependency’s arguments as well as a specific class’s behavior. As a result, a customized class can be used without affecting other classes which have a dependency on the original.

The example creates a virtual type for Magento\Core\Model\Config and identifies system as the constructor argument for the type.

Configure constructor arguments

The class constructor arguments can be configured in your di.xml in the argument node. These arguments can be injected into the class by the object manager during the creation. Please remember that the name of the argument which is configured in the XML file needs to correspond to the parameter’s name that is in the constructor in the configured class.

Below is the example of creating Magento\Core\Model\Session instances with the class constructor argument $sessionName set to a value of adminhtml:

<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:ObjectManager/etc/config.xsd">
    <type name="Magento\Core\Model\Session">
        <arguments>
            <argument name="sessionName" xsi:type="string">adminhtml</argument>
        </arguments>
    </type>
</config>

Argument types

object

Node Formats: <argument xsi:type="object">{typeName}</argument>

<argument xsi:type="object" shared="{shared}">{typeName}</argument>

An instance of typeName type is created and passed in as an argument. Any interface name, class name, or virtual type can be passed as typeName.

The lifestyle of a created instance is defined when you set the shared property. View Configure object lifestyle for more details.

string

Node Formats: <argument xsi:type="string">{strValue}</argument>

<argument xsi:type="string" translate="true">{strValue}</argument>

any value for this argument node is interpreted as a string.

boolean

Node Formats: <argument xsi:type="boolean">{boolValue}</argument>

Any value for this argument node is converted into a boolean value.

Input Type Data Boolean Value
Boolean true true
Boolean false false
String true* true
String false false
String 1 true
String 0 false
Integer 1 true
Integer 0 false

These String are case-sensitive.

number

Node Formats: <argument xsi:type="number">{numericValue}</argument>

Integers, floats, or numeric strings are values which are acceptable for this type.

init_parameter

Node Formats: <argument xsi:type="init_parameter">{Constant::NAME}</argument>

Constant::NAME represents this global application initialization argument.

const

Node Formats: <argument xsi:type="const">{Constant::NAME}</argument>

Constant::NAME represents this constant value.

null

Node Formats: <argument xsi:type="null"/>

A null value is indicated by this.

array

Node Formats: Below is the node format:

<argument xsi:type="array">
  <item name="someKey" xsi:type="<type>">someVal</item>
</argument>

An array with elements which corresponds to the items will be created and passes as the argument. An infinite number of items will be included in the array. Each array item can be of any object type which includes an array itself.

When configuration files are merged for a given scope, the array arguments which have the same name will be merged into a new array.

When a new configuration is loaded later via code or more specific scope, the loaded config will be replaced by an array definition in the new configuration instead of merging.

Argument Examples:

<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:ObjectManager/etc/config.xsd">
    <type name="Magento\Example\Type">
        <arguments>
            <!-- Pass simple string -->
            <argument name="stringParam" xsi:type="string">someStringValue</argument>
            <!-- Pass instance of Magento\Some\Type -->
            <argument name="instanceParam" xsi:type="object">Magento\Some\Type</argument>
            <!-- Pass true -->
            <argument name="boolParam" xsi:type="boolean">1</argument>
            <!-- Pass 1 -->
            <argument name="intParam" xsi:type="number">1</argument>
            <!-- Pass application init argument, named by constant value -->
            <argument name="globalInitParam" xsi:type="init_parameter">Magento\Some\Class::SOME_CONSTANT</argument>
            <!-- Pass constant value -->
            <argument name="constantParam" xsi:type="const">Magento\Some\Class::SOME_CONSTANT</argument>
            <!-- Pass null value -->
            <argument name="optionalParam" xsi:type="null"/>
            <!-- Pass array -->
            <argument name="arrayParam" xsi:type="array">
                <!-- First element is value of constant -->
                <item name="firstElem" xsi:type="const">Magento\Some\Class::SOME_CONSTANT</item>
                <!-- Second element is null -->
                <item name="secondElem" xsi:type="null"/>
                <!-- Third element is a subarray -->
                <item name="thirdElem" xsi:type="array">
                    <!-- Subarray contains scalar value -->
                    <item name="scalarValue" xsi:type="string">ScalarValue</item>
                    <!-- and application init argument -->
                    <item name="globalArgument " xsi:type="init_parameter">Magento\Some\Class::SOME_CONSTANT</item>
                </item>
            </argument>
        </arguments>
    </type>
</config>

Note: During merging, if the argument type is different, arguments which have the same name will be replaced by other arguments. In contrast, the old argument will be replaced by the newer one.

Abstraction-implementation mappings

Abstraction-implementation mappings are used when a class’s constructor signature requests an object by its interface. These mappings are used to define the default implementation for that class for a particular scope.

The default implementation is specified by the preference node:

<!--  File: app/etc/di.xml -->
<config>
    <preference for="Magento\Core\Model\UrlInterface" type="Magento\Core\Model\Url" />
</config>

This mapping is located in app/code/Magento/Backend/etc/adminhtml/di.xml, so that the Magento\Backend\Model\Url implementation class is injected by the object wherever a request for the Magento\Core\Model\UrlInterface is in the admin area.

Parameter configuration inheritance

Parameters which is configured for a class type pass on its configuration to descendant classes. The parameters configured can be overridden for its supertype by any descendant. Its supertype can be the parent class or interface.

<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:ObjectManager/etc/config.xsd">
    <type name="Magento\Framework\View\Element\Context">
        <arguments>
            <argument name="urlBuilder" xsi:type="object">Magento\Core\Model\Url</argument>
        </arguments>
    </type>
    <type name="Magento\Backend\Block\Context">
        <arguments>
            <argument name="urlBuilder" xsi:type="object">Magento\Backend\Model\Url</argument>
        </arguments>
    </type>
</config>

In the example above, Magento\Backend\Block\Context is a Magento\Framework\View\Element\Context’s descendant.

In the first entry, all Magento\Framework\View\Element\Context’s instances, as well as its children, are configured as $urlBuilder in their constructors to pass in Magento\Core\Model\Url.

In the second entry, this is overridden and all Magento\Backend\Block\Context’s instances are configured as the $urlBuilder to use Magento\Backend\Model\Url instead.

Configure object lifestyle

How many instances which can exist of an object can be determined by its lifestyle.

The dependencies in Magento 2 can be configured to have the below lifestyles:

  • Singleton (default): Only one instance of this class exists. It will be created by the object manager at the first request. If you request the class one more time, the same instance will be returned. The instance will be released if the container registered is disposed of or ended.
  • Transient: A new instance of the class is created for every request by the object manager.

The lifestyle of both argument and type configurations will be determines by the shared property.

<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:ObjectManager/etc/config.xsd">
    <type name="Magento\Filesystem" shared="false">
        <arguments>
            <argument name="adapter" xsi:type="object" shared="false">Magento\Filesystem\Adapter\Local</argument>
        </arguments>
    </type>
</config>

In the above example, the Magento\Filesystem is not shared, therefore, separate instances of Magento\Filesystem will be retrieved by all clients. Besides, because the instance of Magento\Filesystem is non-shared, every Magento\Filesystem’s instance will get a separate instance of $adapter.

Configure sensitive and system-specific

With multi-system deployments, for example, the pipeline deployment model, the following configuration settings’ types can be specified:

  • share: Settings which are shared between systems by using app/etc/config.php.
  • sensitive: Settings which are restricted or confidential.
  • system-specific: Settings which are unique to a specific system or environment.

The sample below is a template which is for specifying values as sensitive or system-specific:

<type name="Magento\Config\Model\Config\TypePool">
   <arguments>
      <argument name="VALUE_TYPE" xsi:type="array">
         <item name="CONFIG_PATH" xsi:type="string">ARGUMENT_VALUE</item>
      </argument>
   </arguments>
</type>
  • VALUE_TYPE: The type of value: sensitive or environment.
  • CONFIG_PATH: A string which identifies the configuration setting.
  • ARGUMENT_VALUE: A value of 1. It indicates the CONFIG_PATH value is sensitive or system-specific. The default value is 0, which would indicate the CONFIG_PATH value is neither sensitive nor system specific.

Sensitive or system-specific settings which are stored in app/etc/env.php should not be shared between development and production systems.

Conclusion

In this article, I have just provided you various information about Argument Types in Magento 2. I hope it is helpful for you. Should you have any questions or new ideas, feel free to leave a comment below.

Enjoyed the tutorial? Spread it to your friends!