Tackling the problem in the previous post I have decided to rely on providing more options than necessary. I have to remember that because Vodka is not client software, I have to write it as if the client software will be as simple as possible. The goal of Vodka is to give developers a way of setting up a software based CMS with great ease.
To do this, I have built in services that can be implemented and exposed via WCF as well as built in implementations of these services. If you had the binaries for Vodka, you could reference FocusedGames.Vodka.Services, create a class in a Service project and inherit from ContentService or MembershipService. After deploying the project, you can treat it like any other WCF service reference.
The original question dealt with translation services however, is it a client or server responsibility? You would generally make it client side because you may wish to get a different template for the content or change how translation is done. This is on par with most CMS software installs out there but there is a problem. Templates in the Vodka backend are treated as standard items of content. It then would require two calls to the service: one for the template and one for the content. You would also have to know how the template is extracted from the content item. This is a bad idea as it increases server load unecessarily.
The answer is simple: abstract it and keep it server side. The idea here is that the developers can plugin their own template provider into the service when setting it up. This will allow them to point to another service, a local directory or hardcoded templates. If no plugin is used, the service will continue on its standard course, grabbing the template from the standard content data store.
You may be asking why you would ever want to use a custom provider to point to a second service. Let’s say you have a ton of websites that you all want to look the same. For instance Microsoft may have microsoft.com, msdn.microsoft.com, creators.xna.com, xbox.com, et cetera and may want them to all use the same templates for items. They could use a provider to point to a single template service removing the need to change 5+ templates on 5+ servers.
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.
The provider model’s goal is to allow for the abstraction of implementation to the nth degree by allowing for the choice between separate implementations of the same functionality. This design pattern is incredibly common in Microsoft’s ASP.NET, especially in the realm of security. Developers can choose between different providers for membership, roles and authentication for a single site. The point is that the core functionality of the site does not change, only the implementation. Below is a quick snapshot of how such a model is used in Vodka.
The driving force behind the provider model is the abstraction of the implementation. This is done via an interface.
1
2
3
| public interface IAuthenticationProvider{
bool Authenticate(string username, string password);
} |
What gives the provider model its meat and bones is the different implementations of the above interface. The two implementations below represent two authentication backends: an ActiveDirectory installation and an Sql database. Although the meat has been stripped from these two classes, it is clear that their implementations would differ enough to have the two separate classes. Read more »
My senior project involves the study of highly extendible systems for the internet, mainly content management systems/solutions. I am building mine in ASP.NET 3.5 on WS2008, SQL2008 and .NET 3.5 (which includes WCF). The goal is to build a system that has plug-and-play services and is both quick and easy to use. Today I got the very first part of this system up and running and can be reached at jsedlak.homedns.org.
There is a lot of work to be done, but the base code (being built into FGF) is coming along very nicely. Once I can figure out security, the project should simply expand exponentially provided I have the time (ugh!). The two main [sub]projects here are FGDN (Focused Games Developer Network) and a simple CMS similar to that of WordPress, SharePoint, et al. The first is designed to allow users to submit bugs, feature requests, etc. easily much like Microsoft’s Connect. The latter is pretty self explanatory.
Because I am building this all as one interconnected solution, I have also started working on the idea that users that exist in Vodka [may] have access to many other parts of Focused Games. Primarily this means FGDN but also the SVN repositories. A user (you) can apply for access to one or more of the repositories I currently use for my source code. Once you are accepted, you are also connected to any other Vodka service I create. Pretty nifty, eh?
December 3, 2008 8:08 am | 
Subscribe
