A Typical Magento 2 Programming Experience

I’m knee deep in a rewrite of No Frills Magento Layout for Magento 2 – I know the systems well enough to use them, but I’m still coming up to speed on the underlying object implementations. This is important, since my approach in No Frills is

Here’s how you’d do this in PHP, here’s how to do the same thing in XML, hey look, all that XML means you don’t need to write PHP

When I was looking at the layout arguments, I was pleased to an xsi:type attribute

<argument name="block" xsi:type="string">integration_edit_tab_info</argument>

In Magento’s di.xml files and the UI Component XML files, these typed nodes usually meant you can sneak an actual object manager object in as an argument using xsi:type="object"

<argument name="block" xsi:type="object">MagentoFrameworkAppState</argument>

This would be a powerful feature for the layout system, and get layout developers out of the business of injecting their own parameters via automatic constructor dependency injection.

Unfortunately, when I tried this, I ended up with the following error.

Exception #0 (UnexpectedValueException): Instance of MagentoFrameworkDataCollectionDataSourceInterface is expected, got MagentoFrameworkAppState instead.

Without getting too deeply into it, the code that turns Magento 2 layout XML into programatic instructions will only serialize objects that implement the MagentoFrameworkDataCollectionDataSourceInterface interface. This is an interface with no methods, and serves no other purpose than to implement this type restriction.

namespace MagentoFrameworkData;
interface CollectionDataSourceInterface
{
}

Worse (again, apologies for not getting too deeply into the implementation), the restriction is implemented as a non-array injected argument

<argument name="expectedClass" xsi:type="string">MagentoFrameworkDataCollectionDataSourceInterface</argument>

This means developers can’t add to the list of allowed classes.

So, unless the layout developer needs to inject a collection (and one that implements this empty interface), they’re still dependent on PHP developers to get other objects into their blocks, or still need to risk breaking __construct parent/child call chains in deep block hierarchies. (I can also hear an imaginary architect telling us that there’s too many problems with the block system and that Magento will be moving away from them).

When you hear developers – developers like me – look askance as a “design patterns” approach to programming, or at rigidly enforced type hierarchies, it’s this sort of business that comes to mind. I can’t think of a single good real world reason for this restriction.

I’m always hesitant to speculate about these sorts of things, and it’s always more complicated that any succinct cynical take, but a junior developer showing an abundance of caution in an engineering culture where architects are encouraged to develop patterns whose primary goal is headcount doesn’t seem that far off the mark.

The release of Magento 2.0 saw many third party extension developers hewing closely to the patterns recommended by Magento’s core engineering team. As Magento starts rolling out significant version updates (2.1) that introduce breaking changes, and extension developers are further caged-in by incomplete implementations of complex, restrictive design patterns, I imagine we’ll see more and more extension developers writing the bare minimum Magento boilerplate to hook into the system and invoke external frameworks (either full stack, library based, or completely custom) that are actually developer friendly.