Content Management with Bricolage
by David WheelerAugust 27, 2004
If you've ever had to manage a web site with tens of thousands of pages of content where many people need to be able to update that content, you've no doubt recognized the need for a content management system (CMS). Once you start to manage several such sites, the problem becomes even worse. Since you're reading this article on Perl.com, I'm going to go out on a limb and guess that you're actually interested in Perl-based content management systems.
Well, you're in luck.
This article is the first in a series on Perl.com introducing Bricolage, a Perl-powered, open-source, enterprise-class CMS currently in production for some of the most actively updated sites on the Internet today, including MacCentral, ETonline, and the World Health Organization. I start with a high-level overview (think executive summary) of the concept of content management, the nature of the content management ecosystem, and how Bricolage competes with other solutions in that ecosystem. Future articles will cover installation, document modeling, templating, and the Bricolage SOAP interface, among other topics. But first, the basics.
What is Content Management?
So much is made of the importance of web content management these days that the term, unfortunately, has been used to apply to just about any piece of software that somehow relates to the Web or to HTML. This trend has naturally eroded the meaning of the term content management. So I'm just going to punt on providing yet another definition, and focus instead on contrasting some of the categories of site-management software. In the process, I highlight where and how Bricolage fits into the CM ecosystem, and you get the benefit of determining what category of solution best fits your own content management needs.
Content Management vs. Community Building
|
Related Reading 
Perl Template Toolkit |
First, there is the difference between content management systems and what I call community-building solutions, such as Slash and the various Nuke engines. These applications are ideal for setting up community-building and discussion sites, such as Slashdot, MacRumors.com, or (my favorite) use Perl. The idea behind these solutions is to allow site users to register with the site and post comments about articles, content on other sites, or each other's comments.
True content management systems, on the other hand, are primarily designed to allow organizations to centrally manage and deliver content, such as articles, white papers, marketing materials, or what have you. The emphasis is not on discussion (and indeed, most content management systems -- including Bricolage -- don't offer discussion interfaces), but on assuring the consistency of content structure and formatting. Good examples of such systems include Bricolage, Plone, Vignette, and Interwoven TeamSite.
Application Framework vs. Turnkey Application
Next, there's the distinction between application frameworks and turnkey applications. Frameworks are not actual solutions, but provide the tools for you to create your own solutions. Anyone who has programmed in Java understands what a framework is; a content-management framework provides an array of tools and libraries that you can use (or pay high-priced consultants to use on your behalf) to create an application to meet your needs.
Many organizations have bought such frameworks, and in large, heterogeneous environments with six- and seven-figure budgets and years to implement a solution, it can make a lot of sense. Good examples of such frameworks are Vignette, TeamSite, and the Python-based Zope.
A turnkey application, on the other hand, is a complete application out of the box. It will still likely require a good deal of customization to implement a turnkey application-based solution in a complex environment, but we're typically talking weeks or, at the most, a few months. The downside to such a solution is that you're limited to the features that the developers of the application anticipated would be needed; only with open-source solutions do you have the possibility of adding your own. Fortunately, this category of content management is well represented in the open-source space, including such stalwarts as Bricolage, Plone (built on the Zope framework), and TYPO3.
Application Server vs. Document Management and Publishing
And finally, there is the difference between content management application servers and document management and publishing solutions. Application servers serve dual roles in life: they provide an interface for managing content, and they deliver that content to the final audience. This approach has advantages for some organizations, in that it requires only a single server, document updates are immediate, and you need deal with only one technology. Plone, Zope, and the various Wiki solutions for ad-hoc content management are typical content-management application servers. Blogging software tends to fall into this category, as well.
The downside to application servers is that, because they both manage and deliver content, your choice of delivery technology is limited to the technology choices of the software developers. With Plone, for example, you have to use Zope to serve content to the final audience. Furthermore, many of them provide templates for the output of content that limit how much you can customize the look and feel of your site. And finally, performance on a high-volume site can suffer, due to the overhead of the API and database, as well as the trickiness of distributing content across an array of application servers (think caching).
Document management and publishing systems, however, function entirely independent of delivery solutions. They focus on managing documents, moving them through workflow, ensuring the consistency of their structures, and publishing them to external systems for delivery to the end audience. Content is completely independent of presentation in these systems. Upon publication, they push content through templates to format it into one or more types of output (HTML, XML, RSS, Mason, PHP, etc.), and then distribute the resulting files to other servers (typically a web, file, or application server) for delivery to the final audience.
This separation allows the document management and publishing server to do what it does best, freeing up the delivery server to do what it does best: serve content. Bricolage is perhaps the best-known solution in this category. Another one is the recently introduced Krang, which is itself heavily based on Bricolage.
The downside to the document management and publishing systems is that, while you are free to use whatever delivery technology you wish (plain HTML, PHP, JSP, ASP, TT3, SSI, etc.), for security and scalability reasons the publishing server generally must run on its own hardware, independent of the delivery server. Furthermore, these solutions tend to have a broader set of features than their application-server cousins. Since they don't worry about serving content, they can provide other essentials such as document modeling, workflow, multi-site management, multiple output channels, etc. While such functionality increases the flexibility of the software, it can also increase the complexity of an implementation. The upshot is that the implementation of such a solution requires a good deal of forethought and planning.
Why Bricolage?
Now that you have a feel for where Bricolage fits into the content-management universe (see how it's grown beyond an "ecosystem" in the space of a few paragraphs?), let's take a look at why Bricolage is a good solution for the complex content-management needs of organizations with large volumes of content, many content contributors and editors, and/or multiple sites to manage. Essentially, this boils down to a brief overview of some of the more important features of Bricolage. Once you've read this section, you should have a good idea of whether Bricolage is right for your organization.
Browser-based Editing and Administration
Bricolage provides a complete browser-based interface. Designed to work with any standards-compliant graphical browser, you can handle nearly all configuration and administration tasks via the browser. All document editing can be carried out in the browser, as well. Content authors can create and edit content using up to four different interfaces, including separate fields for each block-level piece of content (paragraphs, headers, blockquotes, etc.), bulk editing of multiple fields at once, or WYSIWYG-style editing with htmlArea in Internet Explorer and Gecko-based browsers such as Mozilla and Firefox.
Document Modeling
The document-modeling features of Bricolage allow you to model the structure of your documents entirely via the browser-based interface. Once you've ascertained the different types of documents your organization needs to manage, and what their structures will be, you can model them in Bricolage. All documents created in Bricolage are based on such models, and as such, must adhere to the hierarchical definition of elements and fields that constitute their models. This approach assures the consistency of document structure.
Bricolage's element-administration interface makes it easy to create new elements, add sub-elements, and create content fields.
