Many developers are familiar with the MVC (Model View Controller) design pattern that is seemingly ubiquitous throughout web frameworks. Looking through the code in Magento, however, we see many other components besides the M’s the V’s and the C’s.
Each module (a “module” meaning the separate directories within the “app/code/core/Mage” directory that comprise of Magento’s different functional areas) contains the usual Controller and Model. You’ll see that within each module, there are no Views (more on this later). You’ll also see extra tidbits, such as “helper” , “etc” and “sql”. These are (and are not) standard within the Zend Framework context and will not be discussed in this article. In these modules are also the sort of files which we work with very often. The all powerful block! This article will attempt to (hopefully accurately) describe just what a Block is and how it’s used.
A top priority of (good) Object Oriented Programming is the decoupling of code. In a nut shell, this means that code should have the least amount of dependency on other code as possible. (Slightly more accurately, objects should not rely too heavily on other objects to exist and function). Blocks are part of Magento’s solution to keep their application loosely coupled.
A quick primer on MVC: When a page in Magento is called, the URL tells Magento what code to run. This is done via a “router” which calls upon a selected Controller to do it’s thing. The URL gets “routed” to a particular Controller, which in turns tells Magento what to do. The Catalog controller, for instance, is responsible for telling Magento to load a product collection and and then show those products to us. The Controller tells Magento which layout is to be used. This determines which modules are put into place, which in turn tells Magento what Views to output. The data from the Models are given to the Views to be displayed. In the scheme of things here, Blocks fit roughly between the View and the Model.
Note: The above paragraph tells a simplified version of how Magento uses Controllers (and of course there are exceptions). Magento is capable of doing much more work in the Controller than it generally does, but usually chooses not to as part of its attempts to decouple its code. Hopefully this becomes more clear to you why.
Magento has sets of modules (as mentioned above). Modules act as their own little entities, each (mostly) containing their own M’s V’s and C’s (athough the Views [phtml files] are located elsewhere). These modules create the separate areas within a typical Magento page; the header, header links, mini cart, recently viewed products, static HTML blocks, footer, and so on. Basically, comprised within any given web page are multiple modules, each of which call their own Views.
On any given page request, Magento needs to be able to show a certain set of modules (and by extension, those modules’ Views). The possibility of many sets of modules to be displayed on any given page means a decoupling is necessary amongst the Controller (which handles the page request), the Models/Blocks and their Views. This is where Blocks really shine. Blocks enable this decoupling by allowing the module to get it’s data from its Models, and pump out the data to the Views which display the relevant data. Each functional area of a page can then act separately. In this way, we can decide when we want to show a certain functional area (such as the Minicart). We can tell it to show up on product pages, but not CMS pages. We can move it from the right to the left column, to the center, to the header,to the footer, or to a defined area we create!
So, what is a Block exactly? A Block is basically a data resource for Views. It uses the sites Models, grabs the data, makes any necessary adjustments, and then makes that data available to a View. For instance, when you override / create a Block that calls a product collection, that product collection is pulling some products’ data from a Model. The Block is where you create such a product collection and implement the product collection’s methods, such as adding filters or ordering the products in a certain way. That product collection is then made available to your View so you can display the products on a page.
Whew, this was a long article! And definitely not the usual we see here at Explore Magento.
In this article, we discussed a basic overview of MVC, how Magento implements MVC, modularity within Magento, decoupling of code (and the design-driven reason behind it’s decoupling), and the Block’s place within the architecture of Magento. We concluded that a block is basically a tool which allows Magento to place content items / functionality throughout the site in a modular way (in any given area and on any page).
I hope you found this article to be clear and useful! It was definitely a digression from our usual posts which aim at having the most bang for your buck.