Customized versus Uncustomized Site Pages in SharePoint 2007
I taught our SharePoint developer class last week, and a couple people who were relatively new to SharePoint had a hard time understanding the difference between Customized and Uncustomized Site Pages. I explained the process a couple times and add the explanation here for others who may share the same confusion.
Let’s say I’m creating a new Visual Studio project for a SharePoint Feature. This Feature includes a page template and will provision an instance of the page template into the virtual file system of the current site when the Feature is activated.
Provisioning an instance of the page means that SharePoint will update the content database to indicate that there is a new page in the site. The database will also contain the path to the the page template in the SharePoint system folders and a placeholder for a customized version of the page. Originally that placeholder will be empty, indicating that the page is in an uncustomized state. If a user requests the page, SharePoint will see that it is uncustomized and will go to the system folders, load the page template, compile the page template into a DLL, and use the compiled image to render the page. If there is an instance of the same page template in another site, and that instance is also uncustomized, requests to this second page will use the complied image when rendered.
Later, a user may come along and edit one of the instances of the page template with SharePoint Designer (they may change fonts or styles, add text, add web parts, etc). When they save their work, SharePoint Designer will put the updated markup for the page instance into the placeholder in the database mentioned earlier. That is, the page for the site the user was editing is now in a customized state. When a user requests this page, SharePoint will load the markup from database and dynamically parse it using the no-compile mode feature that was introduced with ASP.NET 2.0. Customized pages do not get complied.
Finally, let’s say that the site page in question supports web parts. While we refer to the act of adding, removing, or editing web parts as a customization of the page, it is not a customization in the context being discussed. Information about web parts is stored separate to the page in the content database, so the act of adding a web part to a page using the browser interface does not put the page into a customized state.
For more information, check out Inside Microsoft Windows SharePoint Services 3.0 and Understanding and Creating Customized and Uncustomized Files in Windows SharePoint Services 3.0 on MSDN.
Technorati Tags: SharePoint