Magento Forum

Views in Magento - Design pattern used? 
 
nikefido
Guru
 
Avatar
Total Posts:  481
Joined:  2008-07-11
New Haven, CT
 

I have been looking pretty intensely at the code in Magento lately, attempting to decipher how the layout of Magento is put together.

Many times, the controller simply does a $this->loadLayout->renderLayout() (or similar process) - without doing to much other work (seemingly).

Obviously many modules create content for smaller functional areas ("blocks") - Additionally, many “blocks” are shown on many different pages in deifferent combinations. This means that the many components of the layout need to be loosely coupled from any controller.

So in the process of understanding just what is going on, I am attempting to discover a design pattern, such as composite / two-step view (most likely a mix of the two? Zend framework supports these, but obviously Magento is using a pretty complex system).

I was wondering if anyone had any feedback on how they see what is happening with this system.

Obviously it’s complicated - a complete overview of what’s going on would be too much - And this isn’t necessarily important to know to develop for Magento, but it could be immensely useful in complex development situations.

 
Magento Community Magento Community
Magento Community
Magento Community
 
nikefido
Guru
 
Avatar
Total Posts:  481
Joined:  2008-07-11
New Haven, CT
 

To continue my line of thought:

I need to really ascertain what I am really after.
1) How does each block grab the appropriate view file (where is the view file held, how does Magento know which to grab)
2) How do these views work together to become a cohesive whole (the harder question)

First, every view is associated with a block. I explored this relationship in this post: http://www.exploremagento.com/magento/whats-in-a-block.php if you are interested on reading it. So, let’s go see whats up with the blocks -

app/code/core/Mage/core/Block/Abstract.php - This is the base block class on which all other ones are built. A few blocks used directly extend this class, such as the blocks within the core ‘cms’ module. This sets up much of the functionality for with information provided by the request/router, and more importantly, provides an interface for setting child/parent blocks, retrieving HTML and other items. I suggest looking at it to see whats going on -there is a lot of useful functionality provided here. It appears you can also retrieve other block information from another block.
Something interesting here is that you can set a layout via the “setLayout” method. This takes a Mage_Core_Model_Layout object (which in turn extends a Varien_Simplexml_Config object). These layout objects seem to handle the xml, presumably from the layout XML files. This will be an interesting area to investigate as these layout objects deal extensively with Block objects.

app/code/core/Mage/core/Block/Template.php - This is the most extended block found within the system (used within the Catalog, Adminhtml, checkout and page modules (among others). This class wraps some methods in the abstract block class. It also handles adding template path hints, fetching and rendering a view (phtml file). Fetch view retrieves the view via:

...
include 
$this->_viewDir.DS.$fileName;
...
renderView does some interesting things that should be investigated:
Varien_Profiler::start(__METHOD__);

        
$this->setScriptPath(Mage::getBaseDir('design'));
        
$params = array('_relative'=>true);
        if (
$area $this->getArea()) {
            $params[
'_area'$area;
        
}

        $templateName 
Mage::getDesign()->getTemplateFilename($this->getTemplate(), $params);
        
$html $this->fetchView($templateName);
        
Varien_Profiler::stop(__METHOD__);
        return 
$html;
It appears to retrieve it’s “area” via the “getArea” method which is set within the objects “data” ($this->_getData, $this->_setData - basically just an array that’s local to the object - _getData is functionality created within the Varien_Object class). I’m not sure when this “area” is set for this block.

I suppose I have a start here - it appears there are many areas to branch out to investigate from this point.

 
Magento Community Magento Community
Magento Community
Magento Community
 
nikefido
Guru
 
Avatar
Total Posts:  481
Joined:  2008-07-11
New Haven, CT
 

jshpro

Thanks for the clarification!

Also, good stuff in your blog so far, keep it up (+1 google reader for me)

I have not looked at the issues in incredible depth myself, but I’m not sure I agree that it is a large mistake on Magento’s part. It allows the decoupling of the blocks from a particular controller, which has the effect of being able to use modular layouts with separate functional areas (hope that makes sense).
I don’t really count the core controllers within Magento as “fat” (I do agree that MVC should promote thin controllers and fat models). Yes, this way makes for more view logic within controllers, but the end result is a loose coupling of views to modules/controllers - this gives us the flexibility to move items around in our design, reuse items multiple times, and do things like add or remove blocks via Update XML in CMS pages. Many controllers only have a few lines of code dealing with layout. (An exception is Catalog controllers, but they don’t seem to have a lot of “fat” to them).

 
Magento Community Magento Community
Magento Community
Magento Community
Magento Community
Magento Community
Back to top