Consider this post a feeler of sorts. There’s a topic I find interesting, but I can’t say I’ve yet fully fleshed out my thoughts on the matter. I’m hoping to generate some discussion here. If other people are also interested, and if a discussion leads me to the train of thought I think it will, then I may put these thoughts together and present them at Refresh Seattle on October 30th.
Web Standards advocates tend to only talk about the front end of web sites and app. They tend to completely ignore the back-end. This bothers me. So I want to reevaluate best practices with regard to these “layers,” viewing things more holistically — sort of combining the MVC-ish model back-end web development is heading towards and the front-end oriented layers Web Standards folks talk about. I will quickly outline what I believe to be the real way cutting edge web sites are put together, and then I hope you’ll discuss and tell me where I’m wrong.
Structured content layer (Database/Model)
In the traditional view of things, this means (X)HTML markup. However, real websites don’t store their content in (X)HTML. They usually store their content in relational database. Or sometimes they don’t store their content at all, and rather they gather it via REST APIs in structured, database-like formats such as XML and JSON. Ideally, these databases are semantically designed with fields that properly define the data stored within. Also ideally, the data in these databases contain little to no (X)HTML markup, as this would serve to inhibit the data’s ability to be used in other contexts (our web is not simply X(H)TML anymore. We may want to use this data in plain text for e-mails, in PDFs, in SWF files, and so forth.).
Business logic layer (Controller)
Real websites have some sort of business logic layer. This is generally server-side processing, which can be done in just about any programming language under the sun (Python, Ruby, PHP, Java, and .net are some common ones). Generally, this layer will interact with the data in the structured content layer, perhaps performing tasks like user authentication, validation, and data parsing and processing. Ideally, this layer is fully separated from both the structured content layer and the rendered output layer (next).
Rendered output layer (View/Template)
After the business logic layer has done it’s thing, real websites will want to display a rendered view. Often, this means (X)HTML markup. However, it could also mean PDFs, SWFs, plain text, and even RSS, XML or JSON. In most modern systems, this layer is handed by some kind of templating. Whether it’s a dedicated template language (a la Django Templates, MoveableType templates, or Smarty), a full fledged programming language (a la Ruby in Rails or PHP in Wordpress templates), or something else entirely (XSLTm for example), the goal here should be that only presentational logic is used. Business logic should never be mixed with (X)HTML (or the presentational format of your choice). All programatic elements should be used simply to present the data in the appropriate manner — not to process or otherwise modify the data, and certainly not to validate it, save it, or retrieve it from a database.
Generally handled by CSS, the style layer adds visual design to the rendered output. This is generally well-understood by the Web Standards folks that tend to read this blog, so I won’t go too deep into it. It’s important to note, however, that CSS is not the only technology at play here. In Flash applications, the style layer will be part of the same SWF that contains the rendered output layer. In this circumstance, it’s important to keep the two layers as separate as possible within the Flash (FLA) environment — the fact that they’re ultimately rendered as a package is a non-issue.
Here comes the rub
So the piece of this that I expect to be most contentious (if The myth of content and presentation separation is any indication) is the idea that the content layer is fully separate from the rendered output (i.e. markup) layer. In short, I’m suggesting that the (X)HTML templates used for a website in today’s modern world are much more closely related to presentation than they are to content. Why? Because (X)HTML templates are only one of many ways the content of a modern website is presented. It may also be presented as RSS. Or as a PDF. Or within a Flash context. Or sent as an e-mail. Or exposed as JSON in a REST API.
But, you say: (X)HTML markup gives it structure! I say: Not really. The structured content layer (i.e. database) layer gives it structure. That structure may be replicated in your (X)HTML templates or RSS feed, but the database is the place where the structure begins.
What’s different about the content as it appears in the database and as it appears in (X)HTML? Well, mostly a bunch of
div elements and
id andclass` attributes. What are these for? If you’re being honest with yourself, you’ll admit they’re mostly for hanging styles and behaviors on. In other words, (X)HTML templates are pretty much part of the presentation layer.
It’s okay. Just accept it. You’ll feel better in the morning. :)
Please do discuss.