A perfect example of a CMS application is the interface used to publish this very Knol article. It allows for anyone desiring to publish "a unit of knowledge" to do so in a relatively easy manner. The user interface includes a basic word processing "WYSIWYG" interface (bold, italics, underline, bullets, numbering, etc...). Other examples of CMS systems can be found in applications used for publishing news articles, blogs, wikis, social media websites, etc...
And while anyone who uses the Knol CMS is greeted with a very user-friendly work flow, the underlying application which makes the user experience so simple, is often incredibly complex. It is this underlying programming architecture that separates one system's capabilities from another, and ultimately determines the usefulness of a given CMS.
The following is a list of basic features often found in a CMS:
- User or Role Management (Administrator, Publisher, User)
- Survey or Form Data Collection
- Basic text publishing (as in news articles, or any text based web page content)
- Image Gallery Management
- Navigation Management (creation of navigation menus)
- Content Versioning (the ability to archive and track site content based on date or time increments)
- Calendering (a calender of events for a school or church for example)
- Publishing Multimedia Content (videos, music, podcasts, etc...)
The way in which management of content occurs can be done using several different approaches; however, typically you will find the following to be present in almost every system:
* Database (stores the data) + System Administration Application (allows for the Administrator to manage users and roles) + Site User Interface (allows for publishers and content managers to manipulate the sites content)
Dissection of the standard CMS
A CMS should be typically made up of these three components or units:
- Content Management Application (CMA)
- Meta-data Management Application (MMA)
- Content Delivery Application (CDA)
The permutations of how these three layers can be implemented are endless and definitely depend on the technology used to develop the package. This is not an exhaustive list but, the most important ones. A good CMS should incorporate these three.
CMA
In this layer the framework manages the work flow of content. It can be as simple as allowing users to select the content to edit, invoking a text box or in HTML terms a text area for multi-lined content, changing the content and clicking a save button.
For large scale CMS applications, it could mean multiple users making changes across different sections or even on the same web page. Through this scenario, content can go through different stages of approval before going to production. Content could even be rolled back to an older version if necessary. This kind of functionality requires many features such as role based authentication, version control tracking, and functionality to approve/disapprove content.
A good CMA only allows unformatted content to be entered and leaves this the responsibility of the MMA discussed later. However, many existing CMS applications today use Web based WYSIWYG HTML editor components such as FCKEditor and FreeTextBox. There are commercial editors provided by Telerik and DevExpress to name a couple.
CMA Content
Content can be an entire Web page, a paragraph, caption, image, link, and much more. Storing an entire Web page is typically something a document management system does. Compartmentalizing content and dynamically building a Web page is what characterizes a classic CMS most.
Web platforms such as ASP.NET allow you to use existing Web controls or create custom ones. A Web control is nothing more than a widget that knows how to render its own HTML and participate in the “Web Page Lifecycle”. Other Web platforms such as JSP use similar concepts of automating the HTML output, while others require you to output the HTML yourself.
Regardless of the platform chosen, rendering HTML remains the preferred way to output the content and it usually involves pulling the data from a repository.
CMA Repository
All content should typically be stored in one place, usually a database such as SQL Server, Oracle, MySQL, etc... It can also be in XML files or some kind of file system scheme. Robust CMS applications usually go the database route, because you write complex queries to extract the content you need. Plus one feature of content management is the archival and searching of content, which is much more difficult to do if the data is not stored in a database.
The overall goal of the CMS is to fetch the content from the repository, based on the current context request, and display it on a Web page.
=====================================================
MMA
Content alone does not know how to format or pace itself. This is where metadata comes in handy.
The MMA portion stores properties about the content, details that are generally not shown to the end user. Example properties could be coordinates, name of a place holder such as an HTML table cell, style definitions such as bold, font, color, and many more.
Robust CMS applications use template systems. It could be as simple as loading an HTML file with placeholders and doing text replacements, or as complex as creating XML definitions and using XSL to convert it into HTML. The latter case is more for technically savvy people. However, one nice benefit of XSL is that it uses the XPATH language to build the content using various constructs. Basically you have a pseudo language outside of your compiled application that lets you change the look and feel of something without recompiling the system.
======================================================CDA
The content delivery application is essentially the Web site. There are many different flavors of how the content can be laid out. Many frameworks force you into a design-pattern. This means that all of the pages have the same master page and all the content components are rectangular, meaning it fits some pre-defined HTML table structure.
Other CMS applications delegate the design work to third party WYSIWYG tools such as Adobe DreamWeaver and let you add place holders recognized by the MMA portion of the CMS. In this case the CMS becomes an ancillary tool for the Web Designer.
Many CMS applications are portal based. Meaning the Website provides a conglomeration of information possibly from third party sources and compartmentalizes them in various components such as calendars, news links, lotto results, weather, and more. These portal sites usually give the end user the ability to re-arrange the content facilitated through a personalization framework.
In the advent of Web 2.0 via technologies such as AJAX coupled with JavaScript and CSS, a couple of portal applications such as Page Flakes let you build the portal by dragging your widgets around.
Web Platforms such as ASP.NET have what are called Web Parts, first introduced in SharePoint Portal. Web parts allow you to create web zones. You can then drag your web parts between zones and the position of the controls is recorded in a database. It is a novel idea, however limited due to the fact that the dragging of the Web Parts unfortunately only worked in Internet Explorer.
The future of Content Management Systems is bright, as the very concept of the CMS is in its infancy. With the platform technologies advancing rapidly, massive strides are being made in the CMS field, and the market for Content Management Systems continues to show strong growth.
If you have insight that you wish to share regarding this Knol topic, please let us know and we will make updates as time permits.






Comments
Write New Comment ▼
Write New Comment
Sorry! This knol's owner(s) have blocked you from editing, making suggestions, or commenting here.