How and why to avoid mixing your mark-up and server side code14 November 2012
When we started developing our small CMS product Perch, one feature was very important to us. We were keen to ensure that Perch would never add anything to a user's mark-up that they didn't ask it to. One of the issues with many content management systems and other systems that output front-end code is that they dictate the mark-up to a greater or lesser extent. As front-end developers ourselves we wanted web designers and developers to have full control of their templates, mark-up and the look and feel of sites running Perch.
Whether you are developing a complete CMS or just needing to give editors the ability to manage parts of an application, taking a bit of care over separating the back and front-end code will pay dividends. As a back-end developer you will avoid needing to worry about mark-up, and the website will be far easier to redesign in the future without the need to change serverside code. This post explains some of the key things to consider, based on our experience developing Perch, if you want to ensure your back and front-end remain separate.
NEVER DIRECTLY OUTPUT MARK-UP FROM A SERVERSIDE SCRIPT
With one exception that I will cover later, we do not output any mark-up from Perch PHP code. All of the mark-up used on the front-end of the website comes from the templates that are under the designer's control. This is the key factor in ensuring that your system keeps out of the front-end code. If there is HTML mixed up in the PHP or other serverside code then you have a problem.
USE A TEMPLATING SYSTEM THAT MAKES SENSE TO YOUR USERS
Many Perch customers are web designers and front-end developers. They are not necessarily familiar with PHP or other serverside languages. Understanding this issue was important when deciding how Perch templating should work. Creating templates had to be simple. We decided to use a syntax that would look familiar to anyone who understood HTML.
This is an example of a Perch template. This one is for an article on a website. I have highlighted the Perch tags within the regular HTML. The designer can use any HTML around these tags - the only bit that Perch cares about is the Perch tags which are used to create the editable form in admin for the content editor.
<article><h2><perch:content id="heading" type="text" label="Heading" required="true" ti/tle="true" /></h2><p><perch:content id="date" type="date" label="Date" format="%d %B %Y" required="true" /></p><perch:content id="body" type="textarea" label="Body" textile="true" editor="markitup" required="true" /></article>
This then displays in the admin to be completed by a content editor.
MOVE AWAY FROM RELIANCE ON WYSIWYG EDITORS
If the way that content editors input content into a site is through a large textarea, then typically HTML needs to inserted via some kind of WYSIWYG editor. For designers who want to maintain control over the look and feel of a site, this can be disastrous. If content editors have to make decisions about the HTML to use they are liable to think visually rather than semantically, or require a lot of training to select the right elements in order that CSS will style the pages correctly. The Perch templating system moves away from a reliance on these big textareas, instead encouraging designers to use structured content, retaining control of the mark-up. Content editors then only need to enter the bare minimum of mark-up - for example links, making text strong or emphasised and perhaps images.
WHEN YOU NEED TO INSERT HTML, LIMIT YOURSELF TO A SINGLE ELEMENT
One place where we need to actually insert an HTML element, is when we are displaying forms. We need to generate the elements in order to have control over their validation. Some systems manage forms by inserting a lot of HTML - the label, text, even wrapping elements. The designer can sometimes find themselves jumping through hoops to get the layout or accessibility support that they require.
We ensure people have control over each individual element. When creating a form different tags allow the label, form field itself and any help text and label to be inserted independently.
<perch:label for="email">Email address:</perch:label> <perch:input id="email" type="email" required="true" label="Email address" />
Where we do output a group of fields - a set of radio buttons for example, we allow the designer to wrap these in an element of their choosing.
<perch:input type="radio" options="red,blue,green" wrap="div.radiowrapper" />
AVOID ASSUMING A FLAVOUR OF MARK-UP
In Perch we allow people to set whether the system uses xml style closing elements (for XHTML or HTML5 written as xml) or not. We also have a constant for people to choose whether they want to use HTML5 form elements or not.
This then allows us to use an email field type for example if a user wants to use HTML5 form elements, and a regular text input if not.
ALLOW ATTRIBUTES TO BE PASSED THROUGH FROM YOUR TEMPLATING TAGS
Perch tags have attributes in the same way as HTML tags. When a user adds a form element using a Perch tag they can add any attributes they like. Some of those are used by Perch to enable serverside validation for example. However others are just passed directly through when the form field is created. This means we don't need to worry about supporting all the different attributes people might want to use. If they are of no interest to us we just pass the through directly.
These techniques have enabled us to create a system that gives the control back to the designer or developer implementing the site and ensures that the use of a CMS remains transparent to anyone viewing the website. There are additional benefits of ensuring that you stay out of the HTML. Perch can be used to manage xml documents or json files, in fact any text file format that you want. This wouldn't be possible if we routinely inserted mark-up into the site so is a nice additional benefit to separating the two.