Love the web

Separating content from presentation? Okay - so this is definitely not a new idea (have a quick hunt around and you'll find over 30 years of history). However it's still important and you see many cases that could benefit from its use. Smaller to medium sized sites in particular as these are often the result of sites that were originally scoped to be larger. Also sites that have been around for a while, that may have started out with good intentions but these have gradually slipped over time..

The key idea.  Keep your content separated from markup and presentation.  Ideally we want to go a step further and actually build a structure to support how this is managed and delivered. Go one level of separation further and decouple the presentation from the logic that figures out however to manipulate the content into a ready format for the presentation.

Why?  The moment your data is integrated into its presentation it becomes constrained and less flexible so the reasons not to boil down to allowing greater flexibility, reducing constraints, making management of the site easier when it comes to changes and allowing different site components (such as code functions or presentation templates) to be reused nicely.

Often how you present or show content will change over time.  Perhaps you will want to offer different 'views' of your site to different types of end users, like the general public versus your own clients, or to offer a site for mobile users.  Perhaps you will undergo a re-branding and need to overhaul the site.

There is also the possibility that you will want to display lots of different data in the same way - why not re-use common display mechanisms?  For smaller site this may not be practical and it does require your site to use more than just HTML.

What are the options??  Well there's a myriad of approaches; some well defined and some not.  One of the most popular and one implemented by a number of frameworks and website architectures is the Model View Controller (MVC) approach.  Sure it has its critics and situations where it's not appropriate and there are other valid alternatives. The key is structure and making life easier, making your site easy to maintain, modify and grow.  MVC separates your website out into different parts:

• The MODEL is effectively your data or content (maybe it's the text that appears on the pages or a product catalogue or customer details) and could be stored in numerous ways (a database, XML files, some other proprietary system or something else).
• The VIEW is the presentation of the MODEL in a particular format (so it could be a webpage or it could be a spreadsheet export or site viewed on a phone) and it provides a mechanism for a user to indirectly interact with the MODEL (maybe even to change what is held in the MODEL say through submitting a form or some other type of interface).
• The CONTROLLER sits in between and is typically invoked by users interacting with the VIEW.  It can contain the logic to manipulate data from the MODEL and prepare it for the VIEW and also manipulate data in the other direction coming from the VIEW and pass it to the MODEL.  The CONTROLLER can also be used to determine which VIEW to present the MODEL through.

If it sounds complicated it need not be; the key is the separation and at a basic level it really is that simple.  The wonderful thing about the MVC approach is that it not only separates data from presentation but also seperates out that business logic and that the model aspect leads nicely to object oriented development.  In this day and age with the advent of frameworks and proven design patterns there really isn't any reason not to adopt something along these lines - too often you see too much time spent working on the wrong thing.

For some more details you can have a look at Wikipedia:

http://en.wikipedia.org/wiki/Model-view-controller