The process is:
renderView if the block has a template.
renderView() basically is the method to render the HTML, but it assumes that a template exists. It finds the full path to the template according to theme fallback rules and then calls
fetchView($fileName) in turn contains the actual rendering, given a path to a template file. It adds template hints if configured, extracts assigned variables (a feature that probably nobody uses) and includes the template. Then it returns the rendered output, or directly echoes it, if the layout has been configured with
setDirectOutput(true) (usually not the case).
fetchView() are not really meant to be used directly, although Magento itself does it in a few edge cases. Take these as an example:
fetchView() can be used to render the same block but with a different template. This is used in
\Mage_Adminhtml_Block_Customer_Edit_Tab_Cart::getGridParentHtml(). But I would not say that it's a particularly good example. Usually you'll want to create a new block instance to render something else.
renderView() is used in
Mage_Usa_Block_Adminhtml_Dhl_Unitofmeasure::_getElementHtml() because the block doubles as form element renderer (
implements \Varien_Data_Form_Element_Renderer_Interface) and as such can be rendered outside of the layout. Using
toHtml() would have added unwanted overhead and
_toHtml() would have worked, but they probably preferred using a public method.
<block type="core/template" name="name.block" as="cus.block"
Here the block type that refer this block is :
core/template is located in:
name="name.block" we use it when we call the block somewhere like:
<?php echo $this->getBlockHtml('name.block')?>.
as="cus.block" is the alias, we can use it for exemple for calling removing like:
<?php echo $this->getChildHtml('cus.block')?>,
This is the path to your
We can also add ather parameters to the block like:
Nb: getChildHtml(): call the alias first else he call the name.
getBlockHtml() call just the name.
How the Magento layout merge works ?
1. When loading a theme, Magento reads the configuration of all the available modules, and checks which layout files should be loaded.
2. For each file, Magento tries to load it from your theme.
If it exists in your theme, it loads it and goes directly to step 4.
3. If the file doesn't exist in your theme, it tries to load it from the
4. Magento parses the XML files and merges them into one.
5. Magento looks for a
local.xml file in your theme, and appends whatever is there, to the previously merged layout handles.
local.xml vs module.xml:
The benefits to use local.xml :
- Only one file to manage overrides and updates
- No need to have any other .xml file for your theme since it’s dependent on the xml files inside the base folder
- Every change to the local.xml file is evident so there is no need to search for changes inside xml files
None that I could think of, unless transparency and evident code changes aren’t your thing.
All you have to do is to create one inside your theme’s folder and write your xml. Since magento reads through the xml files it will first search for the changes inside your newly created
local.xml and apply overrides and updates and then fall through the .xml files inside the base folder if that is the default xml folder set via the magento administration.