Content Management Systems (CMS) are a way of handling lots of different users interacting with lots of different data in lots of different ways. A CMS is a robust solution to user interaction and the information they are interacting around. There is a broad range of CMS system capabilities if we consider platform-dependent applications that have been developed within industry. Looking specifically with the web space there are essentially content management frameworks, which create a foundation upon which is built functionality like storage, editing, display, etc. A sub-structuring of these CMS options has been suggested4.1 to consist of four general categories:
These categorization are most relevant to the perspective of a user choosing a solution for their website. The developer perspective is that in reality all of these systems can with little trouble be divided into two categories: those that use content management frameworks, and those that don't. Those that don't are often very customized for a specific workflow, or use a model of inter-object communication. Having the code of individual models talk to each other does not scale well, some operational models are generally impossible to implement, and in practice the code across all the modules is very messy (bordering on "nightmarish").
CMS products that do use content management frameworks can scale well and are easier for robust development - but come at the cost of expertise. Editing them requires good developers. In most cases, the basic content management framework provides basic functions like workflow, templating and personalization - but requires everything else to be custom written. In most cases each of these products have their own pre-built package, but as always, some modification will probably be necessary. These systems are often costly to setup, and are usually used by large organizations.
Content management frameworks are further divided into two main categories, based upon design model:
To date, most Content Servers utilize a rudimentary content management framework, which is largely a result of their being built on top of a high-level development language like PHP. Creating a full-featured framework would slow down the CMS too much, and as a result most CMS products in their category offer a thin framework, if any. PostNuke (and siblings) offer no content management framework, replying instead upon object-style inter-module communication. Again, this does not scale well. Other CMS products create a base framework to handle low-level coordination like variables, paths, and some data structures - though many still rely heavily upon inter-module communication, or the collective assertion that a specific module will assume framework-like capacities.
The basic architecture of Zope, TikiWiki, TikiPro and Drupal will be covered below. These products were selected because they are the most widely adopted. A brief story will illustrate these products at a glance:
TikiWiki, Drupal and TikiPro are like the three metaphorical brothers from Chinese tradition. TikiWiki is the oldest (most features), but is complicated and ornery for it. Drupal is the middle brother, drawing on the experience of its younger and older sibling it plots deeply (big plans). TikiPro is the youngest brother, and not being the front-runner it has the opportunity to learn much and is the wisest (best design model), but is the least developed. Zope is the Taoist monk who remains undefeated because none of the brothers can challenge him on his turf (different CMS model).
TikiWiki is a CMS that presents a wide range of features "out of the box." For this reason it is many peoples' CMS of Choice. For the individual, small company, or organization that is looking to make an ambitious step from a web site of mostly static documentation TikiWiki is the common choice (Drupal as well, which we shall get to later). Some developers have moved to TikiWiki due to the extreme learning curve of Zope. Comparatively, TikiWiki's home site is poorly designed for navigation and the documentation is frequently re-organized, and incomplete. (It is hoped that these are momentary growing pains.)
A "feature" can be any of a wide array of things; from an Image Gallery or Interactive Map to a list of system variables and their state. A full feature list, as defined by the TikiWiki documentation, is provided below for the deeply interested. Some of the features under "Communications Tools" are quite compelling, and worth considering whether choosing between an existing CMS like TIkiWiki or creating one from scratch. TikiWiki has come to implement a wide number of features in a short period of time, and the speed of development has led to code design that is sometimes considered sloppy. Less so than PostNuke, but more than Drupal, some may characterize.
Content Creation and Management Tools
Content Organization Tools and Navigation Aids
Drupal seems to have cropped up in part response to TikiWiki and part to Zope. The development community seems to have a concern with making many of the jagged areas of TIkiWiki more soft, while still being within the learning curve of the general web hacking public (unlike Zope). Some of the basic features of Drupal are:5.11
Many more features are available through third-party contributions - as with all CMS systems. Drupal has a very clean 'interface' for the home distribution site that allows new users to get 'in the flow' of the way the software and its development community works. The product is perhaps not as full-featured as TikiWiki in their raw states, but it hold a great deal of promise and is one of the biggest competitors from this segment of the CMS 'market.'
TikiPro is a relative newcomer to the CMS scene, having grown out of the TIkiWIki source with the intent of being more architecturally stable than other PHP-based CMS solution. As such, it is comparatively sparse, but it's core foundation is simple and direct:Basic Components:13.52
TikiPro makes a decisive move toward having all packages use the Liberty Data Integration package to coordinate information within the system.
PostNuke has grown to have an architecture very similar to the Tiki packages: 'module' based with templates to wrap things together. Its relatively widespread use is reflective of the fact that it was one of the first CMS systems to emerge in the public space. The architecture9.5 has not been cleanly developed over time, and as such it is not feasible for the scale of system that is being considered here. There is a two-sided coin to PostNuke's scalability problems: there is no core system module(s) that regulate the operation of all others, and there is no well-standardized protocol for all the 'modules' to talk with each other. These are problems loosely suffered by all the framework systems described above, but PostNuke particularly fails prey to these issues.
The Zope Application server is something of a departure from the mechanism of existing content management frameworks. It is in the process of evolving from something that looked much like the models described above to a system which is a true object-oriented component architecture. A full discussion of the object-oriented model will not be covered here, as it has been well discussed other places,1.9 and doing so often requires some length. Suffice to say that objects carry with them attributes, methods of communicating and dealing with other things. Difficulties in the system arise in coordinating and ensuring responsibilities for inter-object relationship. The similarities are so remarkably similar to inter-personal psychology and human relationships that people have questioned if the Object-Oriented programming has arisen primarily as a mirror of our mind, in much the same way that John von Neumann's characterization of the computer as a model for the brain carried with it such utility.
The content management framework model that Zope uses for its version 3 is an interpretation of the object model know as Component Architecture:15.53
The object model is fairly succinct, and versatile for handling a wide range of application scenarios. Consider the 2.x system, which is at work for most Zope users, and its similarities to the CMS frameworks utilized by the Tikis, Drupal, PostNuke, etc.:15
The overall structure is very prominently presented as an object-object oriented, especially considering the implementation of inheritance, an aspect of object models. With this 'old' model we can without too much effort project is similarly to the CMS models of Tiki, Drupal, etc, each of which use an inter-module communication model for their framework. It is in Zope 3 that a dramatic step is taken toward thoroughly implementing an object/component model.
Architecturally, TikiWiki, TikiPro, and Drupal are nearly identical - and depending on how far back one stands Zope could be a near cousin to the rest. All of these CMS products have moved toward an object-oriented model for their application, whether they call the objects "packages," "modules," "components" or otherwise. Now that we have covered the layout of each it become easier to see that the differences between these products is in how they implement objects. The Tikis, Drupal, PostNuke, etc are all written on top of languages that are procedural, or only thinly implement an object model themselves. Thus, for these programs to build object interaction on top of their 'support structure' is, at best, slow.
Could a true object structure be built? Sure; in the sense that C++, a popular object language, was built on top of C. Invariably, though, there is a little bit of overhead. This overhead is something that is maneuvered around by compiled languages through better compiler design - an avenue not as easy for the uncompelled script languages of PHP, ASP, etc. Zope avoids this problem by being written on top of Python, an object language with a long history of solid development.
Pragmatically, what is really being said here? Each of these languages is moving toward an object model and it is conceivable that they will all operate at comparable speed one day. Architecturally, as problem exists in how PHP & ASP run through code that sits 'inside' of the web server. This adds another delay in speed and a bottleneck that cannot be worked around through good network engineering.
Further, at the present time Python implements objects cleaner than other languages in its class (interpreted scripts). it sits at a unique position of having the object-functionality of a pre-compiled language (C++, Java, etc) yet being flexible like other languages that are executed on-the-fly. The mix of object design and interpreted execution has made Python (and Zope) a perennial favorite among academics and scholars, including its use at Google,8.6 Apple Computer, NASA, and others. Though other languages may in time develop to be contenders with Python, they are not at the state of maturity or acceptance to be used to implement projects of sufficient scale.
For this reason, if no other, it is clear that the Zope content management framework is the best choice through which to envision the system conceived and sketched earlier. As other options mature then reconsideration will be in order, particularly since it is the capability for fledgling languages to implement features easier than their elders. The developers for each of these language is working hard to envision what the 'next generation' language will look like. With the advent of server-side web-based applications the browser is becoming the new development platform, and the result is a feedback loop to the languages the support this new medium. Thus the products influence their production language. Roads are being laid for whole new distributed platforms, and the place of new collaborative systems to influence the way we consider this scale of communications technology is discussed more in the appendix The Broader Vision. Growth is perpetual.
© New Alexandria 2002