06 - Tools for DRY Templates in ExpressionEngine
With the HTML from the Folder Theme now residing in ExpressionEngine you might be tempted to start with implementing fields and channels to store the content on the site.
But let’s hold off on that a moment.
If you look at the 12 HTML files we brought in, there is a lot of repetition. At the code level there are HTML doctypes and meta tags. From a visual perspective there is the site header, main navigation and footer. If seeing this repetition doesn’t cause you to pause a moment and wonder if there might be a better way, then we need to give that inner developer in you some time to surface. We’re using computers here - and if there’s one thing computers are good at it’s automating repetition.
We want to implement our site in a DRY fashion - DRY standing for Don’t Repeat Yourself. ExpressionEngine has a number of ways to simplify repeated code for a backend that’s more efficient and easier to manage and change in the future.
I like to think of EE’s code storage tools as one of those sets of Tupperware that all nest inside each other from smallest to biggest. Let’s unpack that set and talk about them from smallest to biggest.
The smallest of our Tupperware containers is ExpressionEngine’s User Defined Global Variables.
We’ve already used a Standard Global Variable (site_url), these are the User-Defined counterpart. I think of Global Variables as the smallest of Tupperware because they aren’t run through the EE template engine, so they can’t contain any PHP or EE code. They are also late-parsed, which means as EE reads through your code and takes action on it, User Defined Global Variables are one of the last things it look at.
Global Variables are really intended for and best at storing small bits of static text - copyright dates, etc. However if that static text needs to be managed by a client then I wouldn’t even use a Global Variable, because in order to allow Content Admins access to Global Variables you need to let them in through the Template Manager door, and I really don’t like letting clients into the Templates.
Set aside the small Tupperware and grab the next one in the stack. These are Snippets.
The last container in the Code Storage Tupperware stack is Embedded Templates.
If you are familiar with the concept of PHP Includes, templates can be similarly included into - or embedded - into other templates. There is no built-in notion of “parent” or “child” templates, no checkbox to set to tell EE the intended use of a template. Any one template can be embedded into another template. There is no built-in limitation on how deep you can nest templates, nor is there any requirement for how you store and organize your templates.
The biggest disadvantage of embedded templates is that they are the heaviest from a performance perspective. Each template that’s called re-invokes EE’s template parser with all the associated parameters needing to be analyzed (caching, access, PHP etc). The biggest advantage of embedded templates is that you can pass values from the calling template into the embedded template. This is known as an Embed Variable - and proves to be a really handy feature of EE. Using an Embedded Template with Embed Variables allows us to have our cake and eat it - creating centralized code that can still be context-sensitive.
The EE User Guide has some additional guidance on how to choose between a Snippet or Embedded Template - and I’ll also talk about my reasoning while working through the implementation.
How DRY is DRY?
Us developers, we love us some rules with black & white answers. Whether a site’s code validates or not becomes more important than if it effectively communicates the intended message to the intended audience. The indenting of the rendered source code is worried about more than whether or not the site earns the business an income.
Similarly, DRY can be a religion too strongly believed in. The more you splinter a site apart on the back end the harder ExpressionEngine will need to work to re-assemble it and the more pieces you’ll need to manage going forward. The technical abilities of the CMS need to be tempered with reasonable expectations of future time savings.
For example, I’ve seen Global Variables created to store only the closing body and HTML tags on each template. The name of the variable actually had more characters than its contents. How likely is this code to change? If it did, and was stored in 20 templates, how long would that actually take you with templates saved as files and a good text editor with find & replace?
I know other developers will take umbrage with my approach, but I don’t mind if my EE builds have some repeated code or markup across a moderate number of templates. What I’ve seen in 10 years of building clients sites is that for most of them markup changes come more often in the form of complete redesigns than as a remodel of an existing design. When remodeling does happen it only takes minutes to replicate the required change across multiple templates. The approaches I’ve seen to making EE really dry use 3rd party code at a more core level than I’m comfortable with - I worry about future upgrades and migration paths when the build is no longer “EE-centric”.
As with any content you find here on Train-ee, understand that it’s presented as “one way to do things, based on the projects and clients I have had”. I don’t believe in so-called “best practices”, and don’t write these tutorials as such. If you have factors in your projects that seem to logically push you in a different implementation approach don’t worry if you are “doing it wrong” - the great thing about ExpressionEngine is its flexibility. The other thing to keep in mind is that this series is really for newcomers to ExpressionEngine. There are a number of 3rd party add-ons that have the intention of furthering your DRY intentions in EE, but those are best looked at after understanding what EE does out of the box.
Yadda Yadda Yadda - Can We Code Now?
With a better grip on the available code-storage tools in EE, in the next installment we’ll figure out which of the 12 Folder Template HTML files we’ll actually use, and work through the process of splitting them up into a collection of Snippets and Embedded Templates.