Consistent development of Master Pages, Page Layouts and User Controls in MOSS 2007

Page Layouts form the presentation layer in Publishing Sites of MOSS 2007. In fact they are very close to the Web Forms as we know them from ASP.NET except that Page Layouts in SharePoint don’t contain any content.

One of the things that Page Layouts and ASP.NET Web Forms have in common is using custom User Controls and Web Controls. This concept provides developers with high extensibility, code reusability, and allows them to encapsulate custom functionality instead of using in-line coding.

Using custom controls in a Page Layout is very easy. Assuming your assembly has been marked as safe and the trust level allows it to run, all you have to do is to reference it using the <yourprefix:ControlClassName> </yourprefix:ControlClassName> syntax, where yourprefix is defined by the reference to the assembly.

Looking at the Page Layouts shipped with MOSS 2007, you will find the way the MOSS team suggest you reference assemblies with your custom controls:“

<%@ Register Tagprefix="SharePointWebControls"
Namespace="Microsoft.SharePoint.WebControls"
Assembly="Microsoft.SharePoint, Version=12.0.0.0,
Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

This allows you to use all custom controls stored in the Microsoft.SharePoint.WebControls namespace by using for example:

<SharePointWebControls:FieldValue id="PageTitle" FieldName="Title"
runat="server" />

There is something wrong with that approach however: consistency. To use the approach I’ve presented above, you have to register the tag prefix separately in each single Page Layout. If you’re working on a big solution, with many Page Layout and many developers, you will have to make some agreements, if you want to deliver the Page Layouts in a consistent way.

Looking at MOSS itself you’ll find out that it’s not going to work. Compare the contents of the BlueBand.master Master Page and ArticleLeft.aspx Page Layout. What you see is that there are actually two different tag prefixes used for the Microsoft.SharePoint.WebControls namespace. While the Master Page refers to it as ‘SharePoint’, the Page Layouts use the ‘SharePointWebControl’ tag prefix.

Depending on how complex your solution is and how many different namespaces you’re using, using inconsistent tag prefixes might cause some serious maintainability problems. There is however a way to avoid it.

Referencing custom controls in a consistent way

You can define a tag prefix for custom control in the web.config of your Web Application. You can do this by adding an <add /> node in the configuration/system.web/pages/controls section:

After defining a tag prefix as showed on the picture above, you will be able to use one and the same tag prefix to reference your custom controls in all Master Pages, Page Layouts and User Controls in the particular Web Application! Another benefit of this approach is that it will make the code of your assets look cleaner as it will move all the references to the web.config. Like this the developers and designers working on the assets will have more overview of the contents and less ‘noise’.

There is however one serious downside of this approach. SharePoint Designer (SPD) doesn’t recognize externally referenced assemblies, so if you’ll be using web.config to store the references, SharePoint Designer will not provide you intellisense or design view of your controls.

If you’re used to working with SPD you will definitely think twice before using web.config to store the references to your custom controls. On the other hand, if you’re more of a developer than designer and are not afraid of typing a little more, you might just be able to benefit of that approach.

I think we all would agree that the best of it all would be if the SharePoint Designer Team would fix this issue in SPD, and leave the choice to us whether we want to keep the references in the asset or we want to store it in the web.config of the Web Application.

Technorati Tags: SharePoint, SharePoint 2007, MOSS 2007, WCM