WMS: Rethinking our need for CMSTraditionally, Content Management Systems are about Content. Whenever Data that is not simply a content page was going to be persisted in a CMS, you'd somehow fit it in a Content entity, keeping the thought process always at "how would it look to the end user", never treating it as actual data. Sure, there is the page-centric CMSes like DNN, and CMSes which try being data-centric. But when talking CMSes, you can either be too focused at solving your problem, in which case unless it is actual Content Pages that you are working with you will probably move away from CMSes anyway, or abstract too much to be a one-size-fits-all, which will always end up badly. There doesn't seem to be any middle ground.
This seems to be a problem with the roots of CMSes, the way they evolved, and with strong ties of it being always backed by a relational database. CMSes were always about "Content", not about "Data", and the relational model doesn't make your life any easier when you have actual data you want to work with (not just "display").
WMS: Redefining CMS
In today's reality, we might choose to continue bending terms and force all those types of systems under the definition of a CMS, sure, but this will most probably end-up in a multi-purpose data-to-ContentPage converter built on your MVC framework of choice, achieving nothing, really. Been there, done that.
Instead, I like to think of a WMS - Website Management System. I want this thing to help me deploy any website quickly and efficiently, allow me to manage my content AND DATA by providing admin screens, play nicely with my IDE, support multi-site nicely, and as a general rule won't stand in my way. This is mainly because I don't like building websites, I like building software that might be served to the world as websites. I don't like being a server administrator, either.A perfect WMS would have a gallery of modules I could easily integrate, so I could deploy a website, any website, with no hassle, getting full-blown admin screens for each module that are actually fit for managing the data used by the modules. No stretching or rounding corners. And whenever I'd want to add a new custom functionality to my website, I could just fire up my IDE, implement some interfaces, test, play with the new website locally, deploy, set 2-3 settings, and be done with it. An important thing to note about a WMS is that it does NOT manage data for you, and also the concept of Content is gone forever. A ContentPages module might exist, but it is going to treat all content-pages as data, the module's data. A WMS is not about persistence, and the only data access it does is for persisting configurations. It might manage data-access for the modules, but only to an extent of being a middleman for serving data requests, requests being created by the module itself. This is a design decision we have to make to make sure we do not pose limits to what we can do with modules; data has to be persisted independently of the WMS, but optionally orchestrated by it.
A WMS sounds like a great idea.
I've used Umbraco and felt dirty with its XSLT structure but trying something like BrickPile, I was too confused by all the abstractions. I'd like a nice easy to understand structure too.
One major problem I have with CMS's is getting the custom stuff into source control. A WMS should also help solve this problem.
@Phil, I'm not sure I understand but did you get confused when trying out BrickPile?
In Orchard, the content called a Page is defined as "something" which has a Route, a Title and a Body. Similar idea.
what you describe about wms looks like django for me, except that django does us relational database