There has always been some fight in the SharePoint community as to which is better: web templates, site definitions or features for creating a new SharePoint 2007 website. Some consultants even go further and claim that one or more of the approaches should be avoided at all costs. Hell, even at Microsoft are not on the same page and state different things in the bunch of MSDN articles they have on the topic for the different versions of SharePoint; the latest one is to use as much web parts as possible and avoid custom sites...
Here are some thoughts on possible choices in different situations you can get when choosing how to create a template for a new site:
Who is going to provide the template - developer or a business man?
Obviously business people would be more familiar with SharePoint Designer and working with it gives you an stp template. On the other hand developers didn't embrace much SPD but keep to the good old Visual Studio IDE and use some free tools for packaging like WSPBuilder or VSeWSS. It seems to be generally easier for them to stick to features and/or site definitions depending on the requirements.
Would the template be used for automatically creating many different sites?
Let me give you an example of such situation: you need to create different site for the different clients a company can have based on a web service call or some file. Each site would probably need to be similar in look, feel and functionality, probably branded differently and may be populated with various client-specific data. I'd use a bare-bone site definition with features so that if I need to upgrade certain functionality, I'd just upgrade the particular feature which is responsible for providing it.
Is it going to be in need for continued upgrading?
We all understand the consequences of unghosting and try to avoid it where possible but at some point in time, a task or a project might require changes to a site. Site definitions are not easy to be upgraded, especially customized ones. SPD gives options for reghosting before upgrade but this is usually not quite what you'd need because the changes have been done with a reason, then why roll back. The easiest way to get through this pain for me is by using features. The feature that needs to upgrade can be coded smart enough to check for these inconsistencies and act accordingly. It won't be easy but in most cases is doable.
Is being able to create and deploy it fast an issue?
Having all tasks for yesterday is something like life these days. But there are situations where things need to move real quick. Consider having a intracompany conference in several days and you need to build up a site for today. You can go with site definition and features but digging in those xml declarations and actually coding the features will take time and time is what you don't have. Then you should stick to SPD and export a template which will contain all the information for the conference, announcement lists, document libraries and custom design which will be needed.
How large is the site?
Small site will most likely again mean that going through the pain of site definitions is not worthy. SPD is again your choice. But a big site with many subsites, functionality, communication probably would be a good place to go with bare-bone site definition and different features. This will allow you to debug and later maintain easier.
Client likes default templates?
There are times when clients like or are just used to working with the default SharePoint templates which ship with WSS 3.0 or MOSS 2007. Then the best way to add functionality to it is either with web parts or features but remember to never modify its site definition, otherwise you are getting into troubles.
Conclusion
SharePoint Designer 2007 is definitely not the best tool on the block but there are times where it can come in handy and fast give you a nice template for the brand new site. As developer I am more used to writing code in Visual Studio than defining hardly able to debug xml schema or not much coherent code coming by SPD this is why the introduction of features in WSS 3.0 was probably the most useful feature to me which was easy to get used to the small event system and create pluggable pieces of functionality. Web parts are also great for packaging functionality but on a more granular page level while features are more global and interesting way for developers to push business needs to sites. Unfortunately, creating a new site by features would still need a back-bone host site definition but this inconvenience can be considered more of a small time-consuming obstacle than a real show stopper.
No comments:
Post a Comment