The Vodka Content Management System is a service based, multitier setup with the clients getting access to all content and member information via services. In turn, the services communicate with each other as well as their respective data stores. One of the goals of designing Vodka is to implement objects in a way that is easily extendable. To accomplish this, all content is managed in terms of the text data (XML) and its meta data (title, author, date stamps, et al).
The problem is how this data is transformed into its two main uses: HTML and .NET Objects. The question is where these transformations take place. In order to transform an XML file into HTML, the code needs access to an XSL file. The problem with this is that it too, is treated as a piece of content. It is regulated in exactly the same way with the same level of security. Thus it can be seen that this service should remain on the server. This is where it currently sits, so what is the problem?
The problem remains that it shouldn’t be a server side operation! That is slow! It requires more implementations than necessary and furthermore it builds a bad dependency on the server for specific implementation.
Sounds like you want it to be ajaxy. Have a standard template html and .js file that downloads the two pieces of content (xsl and xml) and transforms them then displays them. Make your server content such that no item changes and there is no expiration date and you can save a lot of traffic with caching even though your content is dynamic as the template, the xsl, the .js and probably a .css only has to be sent once.
Well Vodka is not a CMS in the common sense of the terminology. I am not supplying any client side software initially because that isn’t the goal of my senior project.
Rather Vodka is just the services that a client would connect to and consume. The problem I have run into is that because I know the clients will want the content in HTML form, I have built in translation functionality.
My solution to this will to support external template factories. If the client has their own local (or remote) templating provider, they have always been welcome to use that. They can grab the XML from the content and just go with that.