This is part of a series on Magento Best Practices. Click here to read more.
Templates are the third component of the view layer inside of Magento. These files hold the html elements and the logic for rendering them. Templates are mainly the domain of the frontend developers on a team. They apply the appropriate logic necessary to customize the look and feel of your site.
Here are the principles you follow:
- Keep Complex Logic Out of Templates
- Map Templates to Associated Block Classes
- Only Use Public Methods
- Declare The Scope of Your Template
Keep Complex Logic Out of Templates
Complex logic can be necessary to render your site. Magento knows this. And that’s exactly why they created block classes. There should be no complex logic inside of your template files. Leave that for your blocks.
<?php $collection = $this->getCollection(); ?>
<?php foreach($collection as $product):?>
<!-- Do product related things here... -->
<?php endforeach; ?>
So what do I mean by complex logic? This is any sort of logic that doesn’t have to do directly with rendering your elements in your template. Logic such as conditionals (if, else), loops, (while, for, foreach) and internationalization are perfectly fine inside of a template file. This logic directly relates to rendering your elements. Any logic more complex than these example should probably be encapsulated inside of a block class.
This also goes for the wrong type of logic inside of a template file. The template files are for rendering. They are not for redirects, data sanitization, or other logic that is not directly to do with rendering your elements.
// if you do this in your template, you should feel bad...
header("Location: http://www.example.com/"); /* Redirect browser */
Map Templates to Associated Block Classes
When creating your template files in their appropriate directories in your themes, keep in mind the equivalent location of its associated block class. This allows you to quickly and easily find an associated block and vice versa. If you place your files in disassociated or random file locations, you will have to dig into the layout just to find out what block is associated with a template. If you keep the directories the same, it becomes much easier to maintain.
Only Use Public Methods
Due to how template files are included and rendered, you have access to every method from inside its associated class. This means you can call public, protected, and private methods from within your template file. While this is possible, you will enter a world of hurt when you call a private method inside a template, and someone decides to rewrite your class.
In order to ensure there are no issues, make sure to call only methods with a public scope. Furthermore, if you are creating a custom block class, make sure all methods called from your template are declared public.
Declare the Scope of Your Template
When working with templates, you call methods from within the $this variable. This is in reference to the current block class you are working with. This can be a little ambiguous. How can you develop quickly and efficiently when the scope of the $this variable has not been defined in your template?
Without the scope defined, you will have to chase down what block class is being used to render a template. This can range from obvious to downright obscure. You can try to navigate folders, look in layout, turn on template hints, or dump out the name of the class with the get_class() function.
The good news is you can declare the scope of the $this variable yourself. Declaring this scope allows you and others on your team to know directly what class they are working with from your template. Also, if you do this, your IDE can also perform autocompletion and association automatically! Trust me when I say it makes life a lot easier.
Now, you know how to develop templates according to best practice. Now get out there and clean up those templates 🙂