Provide static templatesThursday, June 25, 2015 5:15 AM
Good reasons why you should deliver static templates
- Independent from any template language and therefore reusable in other systems
- Good overview of the used component strategy and easy to read
- Easy to refactor and clean up
- Enable Automatic Testing
- Easy to maintain and bugfix since you don't have to setup the whole system
- Your teammates will love you
Dynamic vs Static
Projects are usually based on feature-rich applications like a Content Management System, a Backend Framework or any other System. Working out templates for projects like this means you need to prepare your templates to work with the systems template engine.
Coding your template directly in the system's template language, creates a strong dependency of your template with the used system which makes it impossible to use the same template on another system with a different template language.
Heavily split up files and template-engine syntax throughout your HMTL makes your templates hard to read, your overall strategy is hard to oversee and your work becomes prone to failure.
A good and thought-through component strategy is often found close to the end of your template development process and requires changes and refactoring on your existing codebase. Since you are already pretty deep into the systems strategy, you probably think twice of refactoring your templates in order to cleanup your code and remove redundancy.
When it comes to testing and specifically to automated testing, it makes more sense to perform this task on static files then on everchanging dynamic files.
To fix all these problems, you should separate the templates your system is using and the templates you are creating as a static blueprint. This first sounds like double the work, but here's why it's not:
Well, the workflow when using static templates first doesn't differ from the previous approach that much. But instead of loosing the static character of your templates when inserting dynamic elements of your template language, you keep your static templates at a separate place, copy them over to your system's template location and start making them dynamic there.
To separate your static templates from the dynamaic templates we have two folders in our project root.
source holds your systems source files plus your dynamic templates anywhere deeply nested.
project | |-- source | |-- templates
With the help of our build script we'll still be able to outsource HTML partials and include them into other scripts. If you are in need for a little bit more logic, you still can go with PHP files, but make sure your static templates don't rely on any database nore ask other developers to set up a complicated system. Your static templates are meant to run out of the box.