That at the moment, is my biggest feature request for SharePoint vNext. Why you might wonder? Well.. currently I’m working on a project where we use SharePoint as an application platform. The first thing you do when creating an application is to set up an architecture right? One of the key things in SharePoint architecture is the choice for sites and subsites vs. sitecollections. Now just to let you know, this is not going to be a post about the whole sites vs. sitecollections thing but more a post about the things you need to consider when building an application using SharePoint.
For our application we came up with the following architecture :
The main advantages using this architecture are :
Now we also came up with another architecture :
Main advantage of this one is :
- Manageability of contenttypes and sitecolumns (pushing down changes of ContentTypes)
Basically what you want is a mixture of the two architectures.. Since contenttypes and sitecolumns are bound to a sitecollection, they cannot be inherited by ‘child’ sitecollections.
So the main challenge the past few weeks was to come up with an idea or solution to make this happen. The investigation began on what the ideal solution would be. Making use of the Content Deployment functionality or use ‘default’ OM approach. After having a quick chat with Chris and Serge, I was investigating this technique which I’m quite new at (never did much more than creating backup and restores of SPWebs) and my colleague investigated the ‘default OM’ approach.
Things we found or came across while researching for the proper solution :
- When a new sitecollection is being created and is being provisioned by the features, there must be an extra step to check if an update exists on the parent sitecollection to make sure whether or not apply an update on the just provisioned contenttypes and sitecolumns.
- Do we make changes to the feature files on the fileserver to make sure the contenttypes are always up to date? (not supported by MS)
- If we create an extra step/check why bother using .xml files to provision contenttypes and sitecolumns at all? Why not do it all in code?
- How do we handle changes to contenttypes or sitecolumns that are made by an user on a child sitecollection? Do we overwrite the changes next time an user decides on the parent sitecollection to change something?
- When using ContentDeployment only the listcontenttypes are changed and not the ‘master’ siteconttentype. So if we create a new list based on the sitecontenttype, this contenttype will be outdated.
A lot of questions that needed to be answered.. One solution to our problems could be to introduce a whole bunch of custom field controls that would be lookup fields to a list on the parent sitecollection to make sure every contenttype is using the same set of columns and values. But given the fact that we do have a lot of contenttypes and sitecolumns it would mean a lot of work to make this happen. So we decided to come with another architecture that is a mix of the first two :
Using this architecture we introduce the ‘semi-parent’ sitecollections how have subwebs. By doing this we have the ability to make changes to the contenttypes using the OTB mechanism and avoiding the 2000 security principal limit (a bit). The only drawback is that instead of letting the user change the contenttype on one place (the parent sitecollection), the user needs to change the contenttypes on the ‘semi-parent’ sitecollections as well. The reason why opted for this solution was
- We gained more insight in how many users are going to use the system and the need for unique permissions per web was not there. Everyone had the same rights on each web so we could make use of inheritance.
- The solutions we came up with didn’t really feel good enough to take it into production.
So the conclusion of this post is that if we would really like to use SharePoint as an application platform we really would like to have the ability to introduce contenttypes and sitecolumns on a webapplication level to make sure that every child sitecollection can inherit those contenttypes and sitecolumns. And/or make our features upgradeable to make sure if we don’t have webapplication contenttypes and sitecolumns that we can upgrade our manifest files and the existing lists using the contenttypes and sitecolumns are updated.
If you are wondering about what the OM code looked like, check out the Synchronize Content Types and Site Columns between teamsites post from Sander de Koning (which I discovered today.. a bit too late but good to see that we were on the right track ;)