What is the content? What is the structure of the content? What is a document type? What is a property of a document type? How can I reuse documents? Flexibility versus usability? How to avoid different appearance of same kind of data? How to extend the system on the fly?

These are some questions that come along when designing the internal structure of a CMS based website. Depending on your CMS some of them will be addressed with built in features, some of them could be done with some effort and some of them may not be solvable.

Here I want to show a very simple case study concerning what could/should be a document type.

The site

We want to create a site providing news items. To keep it simple we forget about authors, date to appear, date to disappear, categories and so on.

I will use the naming of the Umbraco CMS for this case study.

Straight forward Solution

Our document template (NewsItem) contains only one dynamic property called "Content" of type "Rich text editor". The title of the article is the node name itself.

Really simple. Let's write articles. Create a new content node with a meaningful name. Fill in your text in the Content area. Publish it. Ready.

The authors of the content will write text, insert some pictures and everything will be fine. Style sheets are defined well, so all articles look just the same.

Content without structure

After a while you will realize that the authors add a section for related links to external resources in the content text. Some of them write a heading called "References" listing all links with a bullet list others add a bold text named "Related" and provide the links with a comma separated list.

The result are articles formatted in many different ways destroying the corporate identity of the site.

Approach 1

The first approach would be to tell the authors that they should use a heading, call it "References" and to list the links using a bullet list. Maybe it would solve the problem if the authors work really consistent. Let's face it. Don't event think about this approach. You are using a CMS!

Approach 2

The next approach would be to add a property called "References" of type "Rich text editor" to our document type. This property would be used to write the links (again using a bullet list). The difference would be that the designer can decide how to call this section and where to place it. Even the formatting could be easier changed. Still not happy? Right.

The authors must still ensure that the formatting of the links is consistent (bullet list). Changes of the formatting could only be done by rewriting each article (ok, style sheets would also help for some situations).

The solution

The solution in terms of a CMS is to introduce another document type called "LinkItem" containing a property "Url" of type "Text string". The Friendly name of this link would be again the name of the node. This LinkItem is then declared as a "Allowed child node type" of the "NewsItem" type.

To add related links to a news item the authors add one child node of type LinkItem for each link.

Benefits

With this solution the authors now can again force their energy to write content and to provide related links. The designer can decide where to place the links, how to format them and even if they should be hidden in a special situation.

That's why we use a CMS. Isn't it?

1. Klare Trennung von Inhalt und Präsentation
2. Einfache Handhabung für denjenigen der den Inhalt pflegt
3. Einfache Korrektur der Struktur und Präsentation über das Internet (verteiltes Arbeiten)
4. kostenlos

Punkt 1 sollte implizit klar sein wenn man von einem CMS spricht, darum habe ich mich also vorerst gar nicht gekümmert. Aufgrund Punkt 2 war die Idee eines Clientseitigen CMS naheliegend auch wenn das Punkt 3 eigentlich ausschließt. Aber strukturelle Änderungen sind ja nur im Vorfeld zu erwarten und bei einer privaten Seite keine Sache die sofort erledigt werden muss.

Clientseitiges CMS

1. Die Oberfläche zur Verwaltung und auch zur Pflege der Inhalte ist dank AJAX bereits sehr komfortabel.
2. Klare und einfache Struktur der Oberfläche bzw. dem zugrundeliegenden Konzept.
3. Das System ist extrem flexibel. Eine klare Trennung zwischen Struktur und Inhalt mit zusätzlicher Möglichkeit verschiedene Präsentatoren (Templates) zu verwenden und diese auch zu verschachteln.
4. Ist in Microsoft .NET realisiert und verwendet den Microsoft SQL Server, was meinem gewohnten Arbeitsumfeld entspricht und mir als Software Entwickler somit sehr entgegenkommt. Obwohl ich bis dato keine Notwendigkeit hatte, diese Tatsache für mich zu nutzen. Ich konnte bisher alles mit den Bordmitteln des Systems und extra Packages lösen.