On Thursday I started work on my new content management system for ASP.NET, called Byron. I wanted to make it both flexible and efficient and in doing so I’ve had my first setback, and it’s all to do with data.
ASP.NET has a great model for creating flexible applications that can be configured very easily and without having to write too much unnecessary code. The Provider module means that you can put all the logic for a set of functionality in one place, and worry about the nuts and bolts later.
For example, I started off with a DataProvider system. I created a base class with a load of functions for accessing information about users and their roles, so that I could build a login system for the admin area later down the road. I then built a MySqlDataProvider which inherited from the DataProvider class and which would actually handle the instructions that the DataProvider was being given.
So basically the user system says “reset this user’s password” and the DataProvider says ”OK. Oi, MySQL? Check this user’s password would you?” MySQL comes along, resets the user’s password and tells the user system it has done so. (A very simplistic description, but hopefully it makes sense.) That all works great because the MySqlDataProvider knows what data to access, in what table and what to do with it. Now comes the tricky part.
I want the system to be a framework or platform, more than a CMS. I want Byron to form the basis of all .NET sites I develop in the future, so that means the system needs to be flexible enough to deal with any type of content, be it a page, a blog post, a contact form or a news article. Because there are subtle differences between examples 1, 2 and 4, a catch-all system wouldn’t work, so total flexibility was what was needed.
So I built a ContentProvider and setup a whole load of stuff in the site’s configuration file so that new types of content could be created, understood and rendered. It all went swimmingly until I came to the point at which I’d have to access data for each page, post or article.
And that’s where the stumbling block came and whacked me square in the noggin. How do you access data from a database without knowing
- what the content will be used for, and crucially
- what form that data is held in?
It could conceivably be XML, a MySQL or MS SQL database or even - heaven forfend - a bunch of text files. If I wanted the system to be totally flexible it would have to cope with all of these, and more. And that’s actually OK as long as you know what data you need, but because the content system was dynamic too, I didn’t.
I knew that if I really knuckled down I could create a really fancy generic query system where the complexity of each query could be communicated and passed from the ContentProvider to the DataProvider and back again. But this would end up slowing the system down, and I’d have a foot-long white beard by the time I’d finished. So I had to make a compromise, and from now on, Byron will only support a MySQL database.
I wanted to allow the support of any database that can interpret SQL (a “programming” language for databases), but there are limitations which I won’t go into, so it’s MySQL or no SQL. Hey, if it’s good enough for WordPress it’s good enough for me!