Creating templated site for WSS 3.0: Templates vs Site definitions vs Features

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.

Read more on this article...

SharePoint troubleshooting

A significant part of building a product is actually proving it works the way your customer expects. Doing so you inevitably perform debugging and performance testing. Issues are expected and tackled until satisfaction. It`s all a standard approach where troubleshooting exists, but as a part of the development.

The real purpose here, of SharePoint is to serve your clients. Maintaining and supporting a living environment is a vital necessity. Troubleshooting your clients` issues needs to be your top priority beside anything else. But doing so might not be as easy as it sounds. So we`re going to take a look at few ideas on troubleshooting from that perspective.

The following scenarios are brief examples of various client issues with conditional obstacles for the one doing the support. Those may be due to various onsite arrangements or possible environmental limitations.

Online evaluation

Quite often clients issues are related to lost permissions to content, lost data or certain inability to perform a task. At ground basis you need to be prepared where to look at first. Usually basic support can be performed by a site collection admin that only has the online access to the SharePoint portal. It`s quite limited area as it goes for clearing back-end issues, but we`ll take a look at what can come in handy when it`s a frontend case.

Check effective permissions action

When utilized it can right on the spot identity access levels and reveal those user suspects. Bad thing is that it`s only available for MOSS, but for WSS 3.0 it`s always a close alternative to use that tool.

Audit logs

You do have when in MOSS only, but that`s the only trace you can find on the SharePoint portal itself. There are several reports all as downloadable content. The important task here is to have those auditing configured in advance. True to say it`ll cause a performance impact, but having it set on sensitive data will payoff. Audit settings are configured per sitecollection.

Usage reports

Deserves to be mentioned as it might bring additional idea of what a particular user has been doing. The down-side is that you need the usage reports turned on and collecting data.

Recycle Bins

For missing data always check the sitecollection root recycle bin. Most of the data can be restored back throughout it. Or at least it`ll get you the user that decided to go for a clean-up.

Backtracking

A client should never know what is going on behind the scenes. But that`s only in a better reality. Your users are still capable of causing that SharePoint to mishandle. I`ll skip discussion about how you need to treat code exceptions, but in our case we`ll assume that an user breached expectations, and got one. You having the main responsibility for generic maintenance need to troubleshoot it. It might be an easy one, but how do we start? Log files .. correct, except that we are not looking into an immediate case that just had printed its logs. What we`re looking for is buried in thousands of lines within our daily logs.

I`ll skip some definitions of various logs that are available within a SharePoint environment, assuming you are well known with them.

So our entry point is nothing else but the system`s Event Log, where perspectively we had an Error message debriefing what happened. Rarely it`s enough to solve the case. What we`re looking for is how to gather more data. A logical continuation would be to realize how that issue was caused. For that reason we`ll need to find what exactly the user made to produce it. And there`s the fun part. As long as you are on the same machine, there`s an IIS logs, where all incoming request are kept. Digging through them will give you an entry point for SharePoint to play with. The matching we are looking for is the date-time of the event, but keep in mind that IIS logs might have been exported with UTC timing. Your IIS have a separate log file per each webapplicaton and you need to search them all. A near match in few seconds difference will give you the user`s playground. Now simply redoing the issue will generate you enough data in all other logs (at their very end)(SharePoint logs would be essential here as well) so you can tackle the issue accordingly.

update:

Investigation on issues wont actually solve them, so eventually you`ll have to bring in the brute force. It`s meaningless to emphasize that relying on pure log files reading is cumbersome, so we all greatly benefit from a bunch of tools. There are many great articles demonstrating how and when to use such. I`ll put some that deserve to be checked out.

Tools for troubleshooting applications (including SharePoint)

Simplifying SharePoint debugging by creating a toolbox

Hope that those ideas will give you some direction for your troubleshooting sessions.

Read more on this article...

ChartPart for SharePoint

By Hristo Yankov

If you would like to generate some charts in Microsoft SharePoint 2007, after a quick search you will find that there is no such out-of-the-box functionality. You shouldn't worry, though, as there is a free web part available at Codeplex, which has everything you need for your list-based charting needs. It is called "ChartPart for SharePoint" and is available here.

Prerequisites
In order to get it working on your server, you will need to have Microsoft .NET 3.5 SP1 and Microsoft Chart Controls for Microsoft .NET Framework 3.5 installed. The 'installation package' does not check for those prerequisites, so make sure you do that manually before you install. Most probably you already have .NET 3.5 SP1 installed, but chances are, the MS Chart Controls are not installed.

Installation
The deployment package consists of two WSP files (SharePoint solution deployment packages) - MSChartControls.wsp and ChartPart 2.0.wsp. First, you have to install the MSChartControls package. Login on your SharePoint server, start the Console (Start -> Run -> cmd) and type:
stsadm -o addsolution –filename MSChartControls.wsp
stsadm -o execadmsvcjobs 

STSADM NOTE: Of course, you will have to choose between the convenience of not typing the full path to the stsadm.exe file or not having to type the full path to the WSP. So, you have to be in one of the two folders and type the full path to the other file.

This will add the solution to the SharePoint Central Administration -> Operations -> Solution Management. You can either use the User Interface it provides to deploy the added solution, or you can continue executing console commands, like this:
stsadm -o deploysolution -name MSChartControls.wsp -immediate –allowgacdeployment
stsadm -o execadmsvcjobs 

Then, you have to activate the installed solution on Web Application level:

1. Go to Central Administration
2. Go to Application Management
3. Select Manage Web Application Features
4. Verify that you have selected the correct Web Application in the top right corner
5. Click Activate on the Microsoft Chart Controls Feature

Now, you have to do something similar for the other WSP (Chart Part 2.0.wsp):
stsadm -o addsolution -filename "ChartPart 2.0.wsp"
stsadm -o execadmsvcjobs 

Deploy the solution, either from Central Admin, or by using the console:
stsadm -o deploysolution -name "Chartpart 2.0.wsp" -immediate -allowCasPolicies -url <url>
stsadm -o execadmsvcjobs

Where <url> is the address of the web site you wish to deploy the webpart to. Now all you have to do is activate the feature on the selected Site Collection.

1. Go to Site Settings for your top-level site
2. Go To Site Collection Features
3. Activate the ChartPart for SharePoint feature
4. Now you can add ChartParts on every site in your Site Collection.

Usage
I created a new 'Web Part Page' on my site, to use for experimenting with the web parts. I chose 'Full Page, Vertical' layout template, as it  is one of the simplest and I preferred to have full width.

I chose to 'Edit Page' and clicked on 'Add a Web Part' link in the design mode of the page. A pop-up showing all available web parts appears and from there, I chose to add on the page the 'ChartPart' web part.

Once added on the page, you have to configure it. While the page is still in design mode, click on the little arrow down in the right upper corner of the web part. It will open a side menu. Click on 'Modify Shared Web Part'. This will open the options of the web part.

Here, you can set the title of the web part (as it will appear on the page it is added to), the web site to pull data from, the specific list and its view. Then you have to select X and Y "Series" column. A bit of explanation... Only Number fields can be choses as "X-Series". "Item Count" is always available to you. As "Y-Series" you have to specify a column of the SharePoint list.

To illustrate all this, I will configure my list to contain only two columns - "City" (single line of text) and "Population" (number field). Here is what my list looks like:

Now, I want to configure the Chart web part to visualize this statistics. I will set it up this way:

We click OK button and the generated chart looks like:

Customization
You can customize the chart in many ways. First. by selecting the 'Chart Type' for the chart. Choices are Column, Bar, Pie and so many others. Additionally, you can select 'Style' (Cylinder, Emboss, LightToDark, Wedge), which seems to work only on specific 'Chart Types'. For example, it clearly works on a 'Column' chart type. Here is the difference between 'Cylinder' and 'Wedge':

There is many other fine tunings you can do, like color palette, size and etc. Also what's really nice is that in the tooltip (when you hover a column in the chart) you will see an exact value, of the column.

Conclusion
ChartPart for SharePoint is a great component, if you want to visualize some statistics based on SharePoint list items. It is highly customizable, easy to install and use. Read more on this article...