Our Blogs

Today I was trying to find a way to programmatically create a publishing page and start the default approval workflow attached to the pages library. The reason that I had to programmatically start the workflow (instead of relying on SharePoint to automatically start it for me) was because my code was running under the system account (in this case under a WCF web service IIS process) and, since SP1, SharePoint will not automatically start a workflow if the list item is being changed by the system account (see this blog post for more information).

SharePoint should be seen as another layer in the technology stack that your code will interact with. But just because you are using this layer you should not forget to follow good and proven design practices. The following points describe some of the principles that sometimes seem to be forgotten when using SharePoint:

MOSS has been the most successful server product Microsoft ever released. Sales are growing much faster than Microsoft ever expected and apparently the UK is outstripping worldwide growth (for more see this). Unfortunately this quick growth is also highlighting one of the major problems that everyone seems to be struggling with - deployment. I've been working with MOSS since Beta 2 and I have debated this issue with other colleagues and we are all in agreement: deployment is one of the biggest pains on any SharePoint project. It's one of the areas that will give you more problems and cost you more money. What is curious is that all companies adopting SharePoint seem to go through the same evolution path. Finding a way to measure where my customers are on this path gives me a good idea on the challenges that I will be facing when moving their projects forward. The kind of measure that I'm talking about it's called a Maturity Model so I called it the Deployment SharePoint Maturity Model (SDMM).

Ever wanted to use the same page layout containing a DFWP, and bind it to a local site list in each site of your site collection ?

In part 1 of this post I’ve talked about the principles behind the creation of a Deployment Baseline during the development of SharePoint based applications. In this post I’m going to talk about how we, at Collaboris. normally group and categorise the different artefacts to create this baseline.

One of the major lessons that I’ve learned so far with SharePoint development is how important it is to clearly define your Deployment Baseline from very early stages in the development lifecycle. In part 1 of this blog post I will describe the concepts behind this Deployment Baseline and in part 2 I will describe how in Collaboris we apply them to the development of SharePoint applications...

Those are the three most valuable artefacts of a project. Requirements should drive most (if not all) activities in a project. A project should be architectural centric and requirements driven... We have all heard these clichés before but how exactly does one manage requirements in an iterative process?

In the not so good old days of COM there wasn't an option - if we wanted a component we had to have at least one interface. The abstract server pattern was alive and kicking and the advantages of separating a service contract from its implementation were clear to all (at least to the ones using OO languages). In those days there was a clear distinction between a component (something providing services trough an interface) and a class.