This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Where are the templates?
Feed Title: Avi Bryant
Feed URL: http://smallthought.com/avi/?feed=rss2
Feed Description: HREF Considered Harmful
One of the frequently asked questions on the Seaside list is "where's the template engine"? Although there are in fact acouple of add-on packages that provide templating, I'm usually tempted to just say ''there isn't one". It's not that I think HTML templates were a bad idea to begin with, when they first started showing up in the mid 90s. I just think we've outgrown them. They were a useful and necessary bootstrap, but we don't need them anymore, so let's throw them out and move on.
What's changed? The increasing support in browsers, and increasingly savvy use by designers, of semantic markup and CSS. Spend some time reading design sites like A List Apart, and you'll get a feel for the near future of the web: minimal, accessible XHTML markup combined with gorgeous CSS stylesheets. Web designers, at least the good ones, no longer really hack HTML except to come up with a consensus for what the proper markup for a particular semantic construct is. The aesthetic, best exemplified by Dave Shea's amazing CSS Zen Garden, is "look at this totally innovative design I did that uses the same standard HTML as everyone else".
As an example, let's look at the navigation bar. Websites are full of the things, and they appear in huge array of different looks: sidebars, tab bars, menus, rollovers, whatever. But they're all really the same thing at heart: a list of links, possibly with one selected. And the consensus among tuned-in designers is to represent them as exactly that; a simple unordered list of links, with a special "selected" id attached to one of the items. This unassuming markup can support a strikingvariety of designs (for a full range, check out Listamatic).
So if the concept modelled at the code level ("this is a navigation bar with a list of these items") is always represented in exactly the same way at the HTML level ("<ul><li><a..."), what extra value do templates provide? There's no information added; in fact, there's information lost, because the concept of "navigation list" will get hidden as the information is shunted through the narrow channels necessary for getting data from code to template. Much better is to encode the markup once, programatically, with a method that takes a set of items and a current selection and generates a list with a link for each one. In Seaside, it would look something like this:
Not only does that capture the intent much better than any export of the same data to a template engine could, but it has all the usual benefits of abstraction: if the consensus as to how to best represent navigation lists evolves, you change one method and all of your markup is instantly updated. The possibilities for reuse here are huge. You write good code once to generate all the standard bits of HTML - lists for navigation, a few divs for three column layout, simple tables for reporting (or maybe not) - and suddenly you have a set of high-level, endlessly themable widgets, without a template in sight. This won't cover all the possibilities - you still need a good generic way to produce HTML, but it will be simple, semantic HTML, and as such is best generated by the developer who is responsible for the rest of the semantics. They have to specify the content is somehow, and simple HTML seems as good a way as any, with the added benefit of not needing any translation before it hits the browser.
This is a fairly general rant, since I think it applies to most web development today. But it applies most especially to Seaside, with its strong focus on reusable, sub-page components, and I have some ideas of how to push it much further in future versions of Seaside than is currently possible. I'll post more when the implementation is further along, but the basic concept is to use halos as the designer's interface: the developer puts up a running instance of the application, which the designer can tweak, live, using a direct manipulation CSS-based theme editor. I think this will be very, very cool; I can't wait to get it up and running.
Previous Topic
