This in an interesting Magento layout technique that came my way via Vinai Kopp (of Mage2.tv fame).
Magento 2’s automatic constructor dependency injection system presents a problem for class trees with multiple levels of inheritance. First, programmers end up needing to call parent constructors with the right arguments, and in the right order. Second, class hierarchies also create confusion w/r/t the object manager’s configuration — namely, which constructor should the object manager reference when looking for arguments to instantiate and inject?
Magento 1’s block class hierarchy has a lot of inheritance. Magento 1 plugins modeled on the core code also have block class hierarchy with lots of inheritance. Magento 1 avoided the __construct
problem by not having an automatic constructor dependency injection system, and by having an alternate _construct
method (single underscore) that was free of arguments. Converting a module’s blocks, and getting the parent/child block constructor arguments to line up right, is a time consuming part of converting a Magento 1 module to Magento 2.
So, the technique described over one the firegento blog is useful, in that gets view logic outside of blocks and into stand alone classes that aren’t encumbered by the choices Magento core team have made.
It’s also another interesting example of the two tiered system at play in Magento 2’s code base. Increasingly, the core systems and components are considered off limits for third party developers.