#carnotaurus cms

[justphilll]

Finding time for Carnotaurus CMS

I have been trying to get back to writing Carnotaurus CMS. The problem is that I am finding it difficult to find time to make more of my time available to do so. I intend to get back to my notes on this programme this weekend. With getting married, entertaining, going on holiday, reading ghost stories for relaxing, and reorganizing my backups, there is little time for much else. However, Carnotaurus CMS needs to be a success!

[justphilll]

Carnotaurus CMS - Deciding upon a CMS Data Storage Schema

After you have decided to write your own CMS, you may consider how you might want to store your data. In any way, you might want to walk your existing database tables (assuming that you currently have your data stored in a database) into one of the following CMS structures:

A CMS style database or;

Xml-based CMS style data storage

CMS style database storage – a set meal

Let us assume the first option. If you opt to store data in a database in some kind of CMS style then you would need to decide upon a structure.

We consider the following page hierarchy (using a simplified EPiServer terminology) and assuming no page versioning:

   For each table in your current database, you might consider having a corresponding row in a Page Type table 

For each row in each table in your current database, you might consider having a corresponding row in a Page definition table 

For each column in each table in your current database, you might consider having a corresponding row in a Properties definition table which also includes a value for that property

The list goes on and you may even have a role of Dynamic properties.

The key is that you could, in principle, migrate any non-CMS style database to a CMS style database in this way.

Xml-based CMS style data storage - half chips half rice

The issue with creating a database schema in the initial stages like the one described above is that it could be difficult to change downstream. This is especially the case if you use dynamic Sql and other techniques that blur relation object to database mappings. The  storage of data in a project such as this one could reflect the emerging design of the page hierarchy object model. Storing data in an XML structure which maps directly to the objects used in the application makes a lot of sense:

   It is easy to change where a database schema in my experience is often not.

A direct mapping between an object and xml facilitates serialization and deserialization for such object mapping

If there is ever a need to use a database (such as Sql Server, Oracle, Microsoft Access, or any other database format) then it would not be too much work to move from XML-based data storage and write a data provider. 

It would be easier to export or transform xml than any non-flat proprietary format

Summary

Using a strict database schema early in the application could impose unnecessary rigidities for data storage. The use Xml has several advantages over database storage. There are no great disadvantages, not even performance as entities (e.g., pages) would be cached in IIS, irrespective of whether we are talking about database or xml. There could be an option to generate both the Data Access Layer and Business Layer could be automatically generated from the Xml. This would prove useful for the creation of strongly type classes and validation. So, Xml storage is the route that Carnotaurus CMS follows for the moment.

[justphilll]

The Beginning of Carnotaurus CMS

Many a time I have heard people expounding, "Do not re-invent the wheel!". Actually, best practice programming often requires just that.

In recent months I have made some headway into developing my own Content Management System (CMS). The necessity came about through an examination of existing CMSs (free or otherwise).

Despite my investigation, I eventually realized that there appears to be nothing out there for free that suited my purposes. Is there anything out there that is scalable and handles says 50,000 individual pages?

The nearest I got to an answer was Orchard CMS. However, migrating a web directory such as myPUBGUIDE to Orchard CMS based became rather time consuming. In the end, I aborted the attempt.

The Orchard CMS import tool is simply too slow. It would only accept small batches at a time. Initially, it took eight minutes to import 1000 records. So, working on that principle I expected that it could take seven hours to import all the records. Unfortunately, I started to receive performance issues as more records were inserted into the database. I even started to reduce the batch size, which helped only temporarily in the early stages.

Another approach that I took was to investigate how I could transform the data from a simple database to an Orchard style one through SQL (hence bypassing any overhead that the Orchard importer would have otherwise introduced). This proved to be much work as the Orchard CMS table hierarchy is pretty complex. So, I put the idea on ice.

I figured that it may not even be worth the time because even if I completed the task:

There would be no certainty that the pages would scale and there would be no performance issues.

Orchard CMS defines every property as a string. So, I became increasingly convinced that this would be insufficient for my purposes, especially as it goes against strongly typed classes.

Learning someone else's CMS sounds more daunting than writing one's own

I asked around on Stack Exchange, thinking that it had the best forums to post such questions over comparative CMSs because it boasts the reach of programmers who are familiar with the technologies that I use. Instead, I just received non-constructive responses.

So what can a man do? I set out to write my own CMS, Carnotaurus CMS.