Custom Site Definitions Article

Kris has been working on an article discussing Custom Site Definitions within SharePoint published in the online .NET Developers Journal.

Do we need to create custom site definitions in order to avoid upgrading problems? That is a question I have heard so many times. My answer is always two-fold.

Yes, you avoid upgrading problems since you isolate the modifications in your own site template. It is of course more difficult and requires a lot of knowledge on the underlying XML (CAML) infrastructure, but once you can do it, it is a good approach. Kris his article is a good start, but do not underestimate the additional work you will have to do.
No, because you will have those upgrading problems anyway. Suppose that Microsoft adds new features to their existing site definitions, your own work will have to be modified again to incorporate those changes. If the changes are big, you will probably end up redoing a lot of stuff anyway.

So, my advice is always, think before you act. When you dive into the customization of site definitions, you are starting something you could regret in a couple of months. Well, that is my feeling anyway. How about yours?

posted on Sunday, February 20, 2005 7:43 AM

Comments

# re: Custom Site Definitions Article

Bil Simser

I'm somewhat torn between the two. Like you said, the Xml and CAML customization requires a lot of work and understanding however it is very powerful (I cant' create new field types without it). We've built a few solutions using .stp files and that works ok but then there's that SQL overhead.

The problem I have is that, at the end of the day, no matter what solution you have you will still have to write some kind of upgrade tool. Lets say the business requirement changes that needs a new field or change of how some information is kept. Whatever approach you took, you now have 150 sites deploying using it. The only way that I know of to move from v1 of the solution to v2 is to build some kind of tool that would interrogate the sites, determine if they have the new feature, then update them.

Quite a tough problem IMHO that needs a more elegant soluiton.

Posted @ 2/20/2005 4:54 PM

# re: Custom Site Definitions Article

Joris

I actually prefer doing site modifications through site definitions even though it definitely costs a lot more work initially. Portal development projects are however subject to a lot of change requests and when you start modifying at the foundation (the xml site definitions) it will save you some time later on in the project.

Posted @ 2/21/2005 8:10 AM

# ííííííí

qwertz

Posted @ 2/22/2005 6:02 PM

# re: Custom Site Definitions Article

Gery Dorazio

Patrick,
Most of what I have seen so far on site definitions goes through the standard recommendations that MS has in their SDK but from slightly different perspectives. Kris did a nice job in his article and I have also asked him this question and am waiting for a reply. I would like to also ask you though...:

The site definitions method does not indicate how the WSS admin and shared pages would be customized to be the same as the new site definition...e.g. logos and layouts in the header initially. They all appear to have the nav bar in what WSS has delimited as the AlternateHeader. This however does not include the title area or logo image on these pages.

Can you shed some light on this situation. At the moment it is irritating because it appears that since MS has created these common admin and shared pages one is stuck to their layouts which can be contradictory to the new site definition and really then only presents a half way to really making a true new site definition. Would appreciate letting me know if I have missed the mark here or some best practices approach that I should look at.

Thanks,
Gery
gdorazio@enque.net