Using Twig with its built in dynamic templating system to populate and control your website “views” — any files that process and deliver output to a browser, is a useful option to consider, especially if you are using the Symfony 2+ Framework since they go hand-in-hand. That said, you can just take the Twig bundle from Twig’s official website and use it for any type of website regardless of the framework or if you aren’t even using a framework. You can even use Twig with WordPress with a little finagling, in case you use a lot of external custom forms that you still have to embed into a CMS.
Some templating engines just use placeholders and basic wildcard replacement of a string to replace some placeholder text with dynamic values. Twig goes much further and incorporates the basic PHP commands a template needs and basic logic you would need your view to perform –such as basic if/then logic and foreach statements to easily loop through values like so:
{% for user in users %}
* {{ user.name }}
{% else %}
No users were found.
{% endfor %}
Twig, like other Symfony bundles, can work as a standalone library. Like other libraries that come with a class object using these tools can help streamline and perform certain tasks in a more automated and predictable fashion. After all, we don’t keep creating our own portal to access our database, right? No, we use MySQL Workbench or PHPMyAdmin or some other “dashboard” solution already out there. These libraries are nothing different.
When you use a library, this means you can download these bundles and use them as a collection of classes that all work together to help you code more efficiently because you don’t have to keep reinventing the wheel for those tasks that you repeatedly perform as a coder, so you can focus your time and energy developing the real custom business logic instead of doing “busy work” kind of coding. Who wants to keep creating a user authentication admin when a proven one already exists?
Twig and Assetic
Another great bundle to consider is “Assetic” which goes really well with Twig to help optimize your site by combining assets, like multiple CSS files into a single minified style sheet file. Assetic and Twig work seamlessly with each other.
Here is a great article that goes in depth with how these two processes work together: http://richardmiller.co.uk/2011/05/13/symfony2-using-assetic-from-twig/
Assetic can even help you optimize and reformat your website images then automatically save all your optimizations to files in preparation to going live with NO processing on the live site. It’s a way to set up your assets in dev then save it all for caching for your production site. It’s an interesting tool and workflow that makes sense for web developers who are going to encounter a lot of images on the site, especially if it’s a publishing or multimedia site.
The best way to learn Twig is to use it. Twig template files are based on extending a basic view of your site’s standard page then inheriting and overriding parts of the pages you need to alter by creating new content in “blocks”. It’s pretty easy and intuitive to learn. Twig really isn’t a language as much as it is a syntax with rules applied to perform different actions. There are only 3 types of tags in Twig, each are enveloped with double curly brackets: “{{ # This is a comment }}”.
Another benefit of using Twig is that it is clean for non-coders to read and follow, since most graphic designers are used to some sort of placeholder logic from using InDesign or some sort of email campaign website where something like “[first_name] [last_name]” is used, they should get the hang of Twig. And you, as a web developer, can rest assured knowing that anything a non-coder in your isolated Twig view does won’t come back to haunt your code and business logic later.
By making sure there is no actual PHP system controls, environment variables, global variables, and other pertinent cogs that could be affected, your templates isolate the design of your views from any values and business logic from the rest of your website. Imagine if you declared some important variable inside your homemade PHP view (which should never be done anyway so chances are you inherited that mess, right?) and that important variable was deleted, or worse: redefined. What crazy things could happen! This is why your views need to always be separate from your business logic, which should be housed safely inside controllers far from the prying eyes and potential mischief of curious “non-coder” designers.
