PHP Templating Explained

A basic need for any application where the idea of maintainability is of any standing is to have its logical components separated and uniquely dedicated for their designed purpose. How can we apply this principle to presentation tier (aka views) in a MVC application?

What are views?

Views are nothing more than presentation of output in a given format (eg: html). Presentation tier is itself subject of patterned behaviors no different from other architectural parts inside your MVC application (eg: controllers, models). The process of breaking up views into reusable parts based on their patterns is called templating. Once templating is used, a view is transformed template assembly, which makes it logical and easy to be maintained.

How can we template views?

What's the best strategy for to template? Even though there is no consensus in this, but there seem to be three favorite options available:

  1. using a back-end language (such as PHP) inside views whenever scripting is required. This used to be default approach until web applications using it ended up with bloated unreadable views. On the positive side, this solution, if applied responsibly, guarantees highest development as well as runtime speeds because everything is done directly, without a post-processing layer.
  2. keeping views scriptless and using JavaScript behind the counter for any logic that may occur inside. JavaScript also becomes a templating engine destined to toggle subcomponents into pseudo-views, assuming you're using a single-page application model. This way complete separation of front-end and back-end is achieved (so they can be managed by different teams), part of the load is lifted from server to client and content inside becomes independent of whatever solution (framework or programming language) you've opted to use on the back-end. Despite all these advantages, this solution has its own number of serious drawbacks: it adds a huge layer of complexity to your application (typically MVC frameworks used on BOTH back-end and front-end) which makes your site slow as a result (because single-page application means loading ALL your presentation layer when site is opened, hence huge html, js, css) and even slower to develop.
  3. using a templating language that compiles into back-end language (such as PHP) and thus masks the back-end underneath. When output is compiled, templating language instructions will be internally translated into your desired server-side programming language, then the view will behave as if it was scripted all along. The advantage of this solution is that view formally maintains complete separation of back-end and front-end (so they can be managed by different teams) without any performance downsides (except on recompilation when content is changed), while keeping complexity at its lowest (which is always something to be sought after).

What does Lucinda think about it?

View Language API, part of Lucinda Framework, defines a compiler for a templating language standard that strictly works like an extension of HTML in which views can be modularized using custom tags and logic inside modules using expressions.