Still learning… (aka. SPD or not to SPD)

Sometimes one is so dense you just have to draw 'em a picture. So I did. I drew myself a picture to clarify my understanding of SharePoint's basic architecture and best practice re: site deployment.

First, in Figure 1 is displayed my understanding of the file system and the web application space. In the file system are a whole host of files which SharePoint may or may not access at runtime. Notable for my interest are the areas containing custom site definitions, features and themes.

In the web space, we have, based on a third-party recommendation, deployed web applications and site collections in a one-to-one correspondence, with each site collection containing any number of subsites.

Second, best practice for development of sites and site features dictates the usage of a solution package (Figure 2) which will contain things like custom site definitions, features and themes. When deploying these solutions (Figure 3), it is best to allow the solution package to update the file system with our custom sites and features and, where possible, use the features themselves to update other aspects, like a set of custom themes, aka. "feature stapling."

As time passes, upgrades are facilitated by this methodology because adding additional features or updates will simply involve deploying an updated solution package.

Thirdly, the most powerful method of customizing sites is through the management of a custom master page as shown in Figure 4. In my scenario, I'll have multiple site collections all deployed based on a custom site definition. These site collections will reference my custom master page. This master page becomes the key tool to control the branding of the site UIs and tell these sites where to access custom styling resources, like custom style sheets.

So far so good until I am forced to ask a really stupid question: How do I develop my custom master? SharePoint introduces an aspect I've never had to manage in the J2EE space (netbeans/dreamweaver/tomcat/etc.). This is the customized vs. uncustomized issue. Ug!

All the tutorials (when I can get them to work) and documentation assume SharePoint Designer. My understanding is that as soon as I try to develop my own master page with SharePoint Designer a copy gets "customized" into the content database and all references for my site collection get decoupled from the master page in the file system and pointed to the other renegade master page as in Figure 5.

How does one develop without causing a proliferation of renegade "customized" files?

Leave a Reply