Engineering the HiFi CMS: On Templating
It's no secret that we're working on a new service: HiFi, a content management system for designers who demand nothing less than a high-fidelity translation from a PSD design to live website. The space between PSD and HTML is filled by a templating language harmonizing a website's content with its beautiful, semantic markup.
If you've worked with a content management system before you've probably hated or tolerated its templating language. So have we.
Our internal CMS employs the use of Smarty, a popular and generic templating language for PHP. We tolerate it. The last major release of Smarty was nearly six years ago back in 2003. Since deciding to build HiFi our driving question has been "what should a great CMS look like for the 2010s", not the 2000s.
What's wrong with yesterday's templating languages?
A lot. We're in the process of surveying the good, the bad, and the ugly, and doing some prototyping of our own. Some of the most fundamental problems are already clear, though. Let's take a look.
It's Not a Language, It's Advanced Search/Replace
Many of today's templating "languages" simply search for template tags and replace them with instructions. This can take you a long ways, and the initial implementation is simple, but it leads to poor design decisions by constraining language possibilities to the tasks regular expressions solve.
Moving to a full-blown language processor (lexer/parser/compiler) removes most of the unnecessary constraints and code base scaling nightmares faced when everything is a regular expression search/replace. We're using techniques and best practices straight out of compiler textbooks to make sure HiFi's templating system is as simple and powerful as possible.
Most Errors Surface at Runtime
In most of today's templating languages the only way to find errors in your template is to run the template. So front-end developers get into a cycle of coding, running, hitting an error, coding, running, hitting an error, etc. Lots of these errors are simple ones, like the misspelling of a variable you're printing.
One of the benefits of moving to a full-blown language processor is the ability to do more analysis of a template's content. We can improve the experience for designers writing templates by issuing meaningful errors earlier. We can look at your template and, without running it, tell you "hey, this variable 'daate' you want to print in this if block that only runs on Mondays will never exist".
We believe improving the diagnostics of template coding will make writing template code much more enjoyable.
Weak use of Expressions
Arithmetic in view code should generally be avoided but scenarios exist where it or other expressions are the best way to carry out the task at hand. Assigning a new variable a calculated value, doing date arithmetic, using conditionals, etc, are possible throughout. We're aiming to make expressions natural and consistent.
What are your templating language loves & woes?
Is there a particular templating system you absolutely love or absolutely hate? Features you can't live without? Let us know in the comments as we're hoping to find great influences for HiFi. Also, be sure to the HiFi mailing list as we roll out announcements and a beta program in upcoming months.
Related Posts
Comments
Kris Jordan
@francisco and @Nolan - H20 and Django style templates are pretty slick. Template inheritance is maybe the biggest innovation in templating languages in the last few years.
@Jake - PHTML is fine for the reasons youve mentioned. It is a pragmatic, fast, and sensible way to do view code in a web application. This is how views for the HiFi back-end application are being written. The interesting point you mention "security in limiting what your template designers have access to" is the key point for HiFi. This is a hosted, software-as-a-service application so having a templating language could be called a necessary evil though I do not think it need be evil. In fact, for a task as specific as "Here is the available model/domain/data, now go write a view/template to render it in HTML" I believe a well designed html template language beats whatever general purpose programming language you throw at it every day of the week.
If your view/HTML-rendering layer uses features/capabilities a general-purpose language has that a templating language does not one of two things is going on:
1. Your templating language is weak.
2. Your view is doing something the controller/Model should be.
@Will - I think I wound up responding to much of your comment in the response to @Jake. As far as Recess goes do not expect this work to replace the plain-old-PHP view code that Recess ships with. A descendant of HiFi may one day be released as a view plugin for Recess but that isnt planned yet. A key ingredient to what we are doing with templating in HiFi relies on our ability to have full-knowledge of the data model. To do a Recsess release would mean less knowledge of the data going into a view/template.
will
I couldn't agree more with the poster above. everytime i see words like "templating language" or "smarty" or whatever my heart sinks. especially if its in connection with a project that otherwise looks ace, eg Recess.
For most projects i work on, I make / implement the cms, integrate the design, add features and tweak the content the client enters into the cms so it looks extra lovely. I want to do that with my CSS, Html and php skills. I Don't know or want to learn a templating language. Ruby, yes. Python, ooo, interesting. Latest framework, gimme gimme gimme. Templating? Snore.
None of the designers I have ever worked with would even know what a templating language is, never mind using one.
Jake McGraw
I'm moving my company from Smarty to phtml (PHP as a template language) for the simple reason that neither of the major use cases for Smarty makes any sense for us:
1. The "security" of limiting what your template designers have access to, and
2. The organizational structure Smarty forces on you (no more PHP/Markup soup).
Reason one doesn't apply to us, since the majority of our developers are working end-to-end, authoring both the PHP scripts and template files to implement a given feature. Therefore, there are no security gains, as developers are wholly reasonable for all values passed from PHP to a given template.
Reason two doesn't apply to us as we are in the process of moving the majority of our code to Zend Framework MVC, which dictates a very clear distinction between controllers and views.
That being said, my experience with phtml has convinced me that template languages for PHP are superfluous. PHP provides a whole set of native language constructs which makes template authoring fairly simple, with the added benefit of not requiring developers to learn yet another language.
Nolan
We have a team member who is a big fan of H20. I've used Django's templating system extensively, and I really enjoy it. It really cuts down duplicate code as you are defining what is different between templates, which is nice for sections and sub pages.
francisco lopes
I really love the way TinyButStrong works and its features, and have used it for some projects. I've using H2O too nowadays because of its extensibility and syntax.
Leave a comment