Paul Howson’s Website

Design and Publishing Notebook

Hierarchical Attributes in Website Structure — Part 1

This is Part 1 of a proposal for adding hierarchical attributes to Business Catalyst website structures. The website structure is considered as a tree of nodes onto which attributes can be attached. Nodes inherit attributes from ancestor nodes. A pre-existing example of such a system (the Frontier Website Framework) and its benefits is presented.

The Legacy of Frontier

Long before Business Catalyst was even an embryo, more than ten years ago in fact, one of the first practical content management systems (CMS) was hatched from the fertile mind of Dave Winer, a software entrepreneur from California. This CMS was built with Userland Frontier.

Frontier was a remarkable piece of work. A persistent hierarchical object database with a browsable interface and scripting language all rolled into one.

The Frontier Web Site Framework used a branch of the object database (comprising a hierarchy of nodes) to represent the web site structure. Text nodes within the object database represented individual pages. Sophisticated scripts (also stored in the Frontier object database) wove everything together and rendered a complete website to disk. There were templates, glossaries, image storage and tag generation. Frontier as an automated publishing tool for static websites gradually developed a devoted following and a vigorous online community of users and hackers who continually added to the functionality. It was ahead of its time.

Dave Winer used Frontier to publish “Scripting News” which many people consider the first ever blog — it has been running continuously since 1997. Concepts for blog publishing developed within Frontier went on to become standard practice in many blogging tools. Dave Winer subsequently added a web server to Frontier and created Manila, one of the first dynamic content management systems.

(Note: The current author created and published in 1998 a Frontier “plugin” for rule-based translation of xml into other systems of markup (such as html). This was at least a year ahead of the first practical xsl translators. Frontier encouraged innovation.)

Frontier’s Innovations are Still Relevant in 2010

There were many ground-breaking ideas within the Frontier Web Site Framework. One of them was the concept of a web site as a tree of nodes in a hierarchical object database, to which arbitrary objects could be attached. The effect of these objects would ripple down the hierarchy to individual directory and page nodes. Any particular page in a website would inherit attributes from all its parent nodes in the hierarchy all the way up to the site root.

Attributes attached to nodes could be used to control almost any aspect of the page rendering process. For example, specifying that a particular template should be used for all pages within a particular subdirectory of the website could be done simply by attaching an attribute, naming the template, to the node corresponding to that directory. All pages in that directory and all subdirectories would inherit that template attribute. It was that easy.

“Metadata” could be attached to nodes also. For example, the name of a section within a website could be attached to a node. All subordinate pages would inherit that attribute. Code within a template or page could then reference that attribute to create, for example, a section banner across the top of a page. One common template could thus be customised in almost unlimited ways.

Present day programmers are familiar with including PHP or other language code within web pages. In the Frontier CMS, templates and pages could include arbitrary code in the Usertalk scripting language, including references to code stored in the object database which could call into action a vast array of sophisticated scripted processing during the page rendering process.

Even today I still maintain a couple of websites using the Web Site Framework in Frontier because of the power and flexibility it offers.

Applying These Ideas to Business Catalyst

In Part 2 I will look at how this concept of a website as a hierarchy of nodes with attached data could be incorporated into Business Catalyst. How could it work? What kind of user interface would be required? Are there any interesting possibilities? Would doing this break the existing functionality? Stay tuned.