Day two of SocialFront for Umbraco development and it's immediately obvious that our priorities have changed slightly. The experience of developing day one, along with our research and interest in loosely-coupling our data layers lately, meant that we were both keen to de-couple the SocialFront API from Umbraco as much as possible. I'd recently had a brush with IOC and survived, barely, so we spent a good hour first thing discussing our options. As good duct tape programmers IOC is pretty hardcore for us, but we're open to new ideas!

We spent a good bit of time discussing namespaces, coding standards, naming conventions, cross-site scripting issues and the like. We have basically gone from the coding frenzy of day one to a much more architecture or high-level discussion of what we are trying to achieve. I think we'd like SocialFront to be a social networking platform that isn't just for Umbraco, but for any existing platforms you'd care to use, or build for yourself. So we are developing for Umbraco for sure, but keeping the flexibility there so that developers can use whatever platform they like. Flickr for images? Go for it - just write your own image provider. Custom database for content? Ditto.

Some references that we used:

http://msdn.microsoft.com/en-us/library/ms972370.aspx

and

http://www.devx.com/codemag/Article/36275/0/page/3

After a lot of discussion we spent the second half of the morning developing our ideas for abstraction, and creating interfaces as proof of concept for what we are trying to achieve. We discussed some thorny issues such as this: what happens to the XSLT side of things if we want to allow developers to create their own providers to store content? One of the nice things about Umbraco is how simple it is to use XSLT for displaying data. But is it possible to recreate that with other data sources? How would you go about implementing the $currentPage variable for example? This is not an area that we know much about!

In the afternoon we spent a good hour arguing about architecture and thrashing out our options. Then we spent the rest of the afternoon and early evening implementing our architecture, and abstracting away the membership provider. This means that you can now use pure SocialFront API calls to log members in and out, register them, forgotten password, etc, regardless of your choice of membership provider. It works with Umbraco out of the box, but you can easily develop your own membership provider to suit your requirements. This is the beauty of this project - we hope that we'll get interested developers with unique requirements implementing alternative providers and feeding back into the project. That's the idea anyway!

So where are we now? We are now at a point where we have a SocialFront API with 'pluggable' providers which can be changed using the web.config. There isn't a lot more functionality there than there was after day 1, but we are much more prepared for the possible demands that developers will undoubtedly put on it. Day three will hopefully happen in January, and our aim would be to release an Umbraco package at that stage. For those of you who've expressed interest in the project - thanks, and please bear with us. We'll get there!