I want to describe the development process involved in creating a web part for a Sharepoint site, hopefully to dispel the belief that it’s difficult and time-consuming. What I want to demonstrate is that it’s actually very simple – no more difficult than creating a custom control in ASP.Net 2.0 – provided you have set up your development infrastructure correctly.
Development infrastructure is where most of the pain associated with Sharepoint development really exists, which is why following this article I’m going to continue with a series describing how you can set up the various parts of your infrastructure to enable friction-free development.
This post, however, will show you exactly how friction-free it can be. I’m going to show the steps to build a basic web part and deploy it to your sharepoint solution in a repeatable and reversible way. I’ll also give a tour of how to customise the look-and-feel of a Sharepoint website using the Sharepoint designer. The purpose of this is show to illustrate that developing with Sharepoint isn’t really that much different to developing for a standard ASP.Net 2.0-based website.
Development
Watch me create and deploy a brand new web part to a Sharepoint server:
1. This is my out of the box Publishing Site template
2. I’m going to add a web part to my site by adding a new class to my visual studio project
3. My class must inherit from Microsoft.SharePoint.WebPartPages.WebPart. I’m going to override the Render method to make the web part output some text. Note how similar this is to an ASP.Net custom control.
4. I build the project. A post-build step creates a CAB file which can be deployed to Sharepoint. This packages up my new features/webparts so that I can manage their usage within Sharepoint and easily repeat/reverse this deployment process.
5. I run a script to deploy the CAB file to Sharepoint.
6. In Sharepoint I add the Web Part to a page. If I haven’t deployed this web part before I need to Import the web part from the Site Settings menu first.
7. And there it is!
This development process is so simple and repeatable, it’s just like a standard ASP.Net website. What’s more when I set up source-control for my visual studio solution I can set up a continuous integration environment to automatically deploy my changes for me.
Layouts
Now I’m going to change the layout for this page. Most developers seem to believe this is an almost impossible task, or at least much more painful than editing a regular ASP.Net 2.0 Web Forms page. Well, watch:
1. My page layout
2. I open up Sharepoint Designer and browse to the page I want to edit and double click. Sharepoint Designer asks me if I want to edit the content for the page or the layout for the page. I select layout. Here’s what I see:
There are a lot of controls on the page. Most of them have the prefix SharePointWebControls, so we can pretty easily see what they’re doing and we don’t have to be afraid. Otherwise this is just like a standard ASP.Net Web Forms page – it has stuff inside ContentPlaceHolder controls. Sharepoint assigns this page layout a master page at runtime.
3. See those ugly tables in the PlaceHolderMain ContentPlaceholderControl? I’m going to change those to divs:
4. And now I’m going to edit the master page for this page layout. I know that the master page I want to edit happens to be BlueBand.master, because I chose it within the SharePoint Site Settings menu. And I also know that all master pages can be found in /catalog/masterpage in SharePoint Designer. I’ll change the tables there to divs too.
5. I check-in the changes to these files (SharePoint automatically provides versioning on these files because they’re actually in the SharePoint database – more on that in another post) and reload my site homepage:
Not such a visually impressive example, I know, but I just wanted to demonstrate that editing a SharePoint website isn’t really that different to building an ASP.Net website, and it’s no more difficult.
In future posts I’m going to walk through how to set up the infrastructure to be able to enjoy the development experience I demonstrated in the first section, and I also hope to demonstrate some ways to make layout editing more enjoyable, like by removing as much of the .Net cruft as possible and make your pages generate something more like semantic markup.
