My experience with content management systems goes back to the late 1990's with the
Vignette Content Management (nee StoryServer) product. In working with that system and reflecting on 30 years or so computer programming experience ("objects--like my head--may appear larger that they really are," let's just say I made it around the block at least once), I came to the conclusion that there really should be two modes of operation for a content management system:
- The traditional mechanism used in CMSMS, the original StoryServer, and most, if not all, content management or other web publishing systems.
- The methods used in source code management and build systems.
Both enable you (or should) to track versions, create reusable components, and assemble them as required. The primary difference is that content management systems tend to perform all assembly on-demand while most assembly of traditional software products happens when the product is built except for the dynamically reconfigurable parts reserved for the user. Now that is not a significant difference in result except that there is a real performance penalty to be paid for dynamically assembling otherwise static content on demand even with a good caching mechanism. If nothing else, there is always the problem for the first visitor unless you have a mechanism like a bot to artificially "visit" every "static" page before your new system goes live. This is (or was) a problem for application servers as well though much more of the implementation for a given site or application is pre-compiled.
The point of all this is to advocate for a way to not just cache dynamically created pages, but to actually generate most, if not all, static content (and even templates) for a site when requested from within the content management system.
Some examples of where this may be useful:
- CSS--especially if you want to maintain style sheets for multiple media types. You can do some dynamic assembly using CSS mechanisms but it would generally be better to produce simple CSS files after assembling them from single instances of common rules as well as those specific to a media type with the results written to simple flat files.
- Internationalization--if you have many otherwise "static" pages that are dynamically assembled from some "localized" string repository (e.g. message catalogs) using templates, it is far more efficient to generate the "static" pages during a "build" or "publish" operation than on each request for a particular page. (Of course, it seems to me that good internationalization is dependent on at least semi-localized templates and CSS in addition to message catalogs. Then again, I am a very parochial American who is trying to talk outside baseball...)
- The current performance of the Menu Manager module would not really be as much of an issue if Iyou could generate your "static" pages and dynamic page templates before they "go live." Of course, this isn't that much help if you cannot handle all "dynamic" menu behavior in Javascript...
Forms (mostly), news, and all manner of other dynamic content must still be dynamically served when requested (perhaps with some limited-time caching), but even then, some pre-assembly should be possible. (E.g. most, if not all "meta" tags should be managed in one or more files to serve distinct needs for different parts of a site, but they should be added to all pages or templates where required when "published". Among other things, it should be possible to generate or assemble templates from components and then use those generated templates to power the dynamic parts of the site.
Well, that is a lot of rambling, but you get the idea. Of course, it is a reasonable question as to whether a system like that can still be "made simple."
