Do you think templates represent the best way for separating presentation logic from business logic?

Question

I think most template engines are hard to use for designers and front end developers leaving you, the programmer with the burden of maintaining them.

And frequently updating the templates after the designer updates the html mockup is a nightmare because your templates are no longer compatible with the original htmls.

I had this problem for very long time, recently I had an idea, but I don't know if I'm not reinventing something or if something better exists.

So, I'm asking if you found better solutions for this problem and if so which one?

Answer 1

I personally like how some CMS solutions enable me to break my templates into very small pieces. SiteCore does this well through placeholders and renderings which map to usercontrols.

I've also used UserControls heavily in the past to break out common functionality like login, menu, footer links, etc to make it easier to modify or replace functionality in the future. (ASP.NET)

What template-engines are you using? Something like Smarty for PHP?

Answer 2

Since I've switched to full separation of content from presentation, I've never looked back, and here's why:

• Your business logic becomes very clear. Without HTML tags and presentation logic mixed in, the code takes ½ the space and less than ½ the time to maintain. The burden of maintaining the link between code and presentation can be mitigated by specifying a formal interface between the two, even as a text file or a Wiki note, listing all the variables and values presented to/required by the presentation layer.

• Frequently updating the templates from designer's changes means that your presentation layer should be sub-divided to various "blocks", such as menu block, page layout block, and content block. On most pages, only the content block is different. When properly divided and implemented using CSS and other modern web techniques, reasonable changes in design will have minimal impact on your presentation code.

• CMSes automate this process even further, and are now at the point where even 5-10 page sites can benefit from using a CMS vs. hand-coded HTML from both consistency and ease of support perspectives.

• Code security - Smarty is not PHP, so your designers can have a lower level of trust on the site (they can't mess with the underpinnings too much, although they can mangle the presentation to the same effect as a DoS would have, so don't mess with them anyway); if you don't care about security that much, PHPTal and others run almost at "native" speed.

As for my working solutions, I have two recommendations:

• Develop a projectwide folder structure and naming convention, and stick to it. Given a name of your business logic file, I should be able to tell you what the presentation files are, and vice versa.

• Have an explicit interface spec (again, a text file or a Wiki entry is all you really need) between business logic and presentation. Knowing which vars are available, and how they should be (programmer) / are (designer) formatted, makes both of them very happy when they have to maintain the page a year later.