Writing User Controls with SharePoint in mind

I was recently out doing some work for a client – wrapping some user controls they had written in web parts so they could be used in SharePoint. While the design was fine for their web-site, they didn’t work properly in SharePoint due to lack of planning.

Due me a favor when writing controls – plan on them not being used for one specific purpose in one specific site. Plans change.

On to the things to look out for…

1) Don’t overload the constructor of a User Control.

There really isn’t a need for it and it causes headaches when it is time to use the control in SharePoint. While it may seem to work fine inside your own web project, in order to get the user control in a Web Part, the ascx has to be loaded. This means a call to Page.LoadControl(“path to ascx”) which automatically calls the default (empty) constructor. So, there is already an instance of it.

If the control relies on a constructor other than the default to work, then I have to use reflection to get it and constructor the item again. This is bad and I don’t want to write that code.

The way this is supposed to work is:

a) I call Load Control to get an instance of the ascx and cast it to the correct type.

b) Then I set the properties I need to set.

c) Then I add it to the control collection.

d) Then OnInit automatically runs – and that is where you put the code to initialize everything based on the properties that where set.

2) Don’t hard code paths to resources like images, css, javascript, etc. (unless they are embedded in the DLL).

This will actually make all your future development easier. It is really nice when someone decides to change the path to where images are stored – to only have to change a setting somewhere.

All you have to do is have a property that takes a relative URL to where the resources are. Do a separate one for images and CSS, because in SharePoint, I’m going to put them in different locations. They will not be in the same location as if you when you write your own site, because SharePoint already has specific places where these things go.

3) Don’t make calls to the web.config file. Have all settings as properties set by the Parent.

In SharePoint, there is a big chance that I’m not going to put settings in the web.config. I don’t really like to do it. I would much rather they be in a config list somewhere that any site admin could access. Even if they really should be in the web.config, it probably won’t be under the setting name you chose. “ImagePath” is not a unique enough setting name to play well on a site where you don’t know what code the admins will be loading.

4) If you can avoid it – don’t load data from databases or web services, have the Parent do that and pass the results in.

For some calls in SharePoint, we might need to Impersonate or run with elevated privileges. It is much easier to handle these situations if the data is loaded in the web part and passed to the user control, than if the user control does all the work.

Really, the point of the user control is just to display data. It is better to seperate concerns and let another piece of code figure out how and when to get the data.



With a little foresight and planning, wrapping user controls from your web-site in web parts for SharePoint should be a breeze.

While I have focused on SharePoint, though, it really is bet to follow these practices anyway. It will make changing and maintaining your own web site that much easier.