Tales from the Evil Empire

Currently, DecentCMS stores content items in the file system, which is just fine for small sites, and makes editing and deploying them quite easy, even though there is no admin dashboard yet. Creating a content item is done by simply creating a file in one of the supported formats: JSON, YAML, and Snippable YAML + Markdown.

Philip asked an interesting question on the DecentCMS forums: “are there plans to allow for theme settings”? That is a great question, and I’m happy to report that the system already allows for it, that I was able to verify that it works, and that it was ridiculously easy.

It seemed like a good idea at the time: wingdings for the web, collections of vector glyphs that are easy to include in your pages. Except that a web page is not a Word document. Now that SVG is properly supported by all half-decent browsers (you don’t have to support browsers and OS’s that Microsoft won’t, do you?), why are we still using icon fonts? Let’s recap.

The default mechanism to store content items in Decent CMS is to use files under the /sites directory. This can be replaced with database storage, of course (the first provider I’ll implement after the file-based one will be CouchDB), but the file storage has some unique advantages. While it’s obviously not something you’d use on a big site, being able to xcopy contents, and deploy contents with a simple ftp client is very powerful. Being able to look into folders and find content items as single files that can be modified with a simple text editor is extremely comfortable.

Identity is a funny thing. It’s one of those concepts that we use all the time, but that are tremendously difficult to pin down precisely. To keep things “simple”, in philosophy and in physics, it’s about equivalence relations. In computer science, I’d say it’s more like a bijection between two categories of objects. The difficulty is that you can only approximate real identity this way: by definition, an object is only identical to itself. What we call identity in code really is a proxy for identity, a substitute for it that usually takes less bits to represent than the object itself. The difficulty when building an identity algorithm is twofold: you need to be able to deterministically extract an id from an object, and the id needs to be different when the objects are different. In other words, same yield same ids, and distinct yield distinct ids. Of course, this can be made more complicated with mutable objects. The constraints are in fact very close to those of a good hashing algorithm.

The content type system in Orchard is one of the reasons for its great flexibility. The ability to build your own content types from building blocks that are just the right size is essential to building a great CMS. Orchard has content types that are made of content parts, that can have properties and fields. Parts are aspects of a type, such as title, comments, or body, that there can be only one of per type. Fields are named, and there can be any number of each type of field per content type. Confused yet? There’s a reason for all this, of course, but in DecentCMS, I’ve opted for a simplified version.

There are a few things that nobody should ever do. One of these things is to write a new CMS. So about four months ago, I decided to write a new CMS using Node.js. It’s called DecentCMS, and I’ve had insane amounts of fun building it so far.

After all these years, JavaScript still occasionally trips me up. Today, I built a test that was failing mysteriously. I use Chai to write my assertions, and that particular test was failing to agree that the array I had constructed was deeply equal to its theoretical value. WebStorm’s test tooling has a diff visualization for deep object or array equality, and this was showing the arrays as equal: