Go to page: 1 2  Printer Friendly Version

This is important when speaking about the impact of customizing pages because the impact of customizing pages can be observed at either the site collection or site level. In the case of a WSS site or a MOSS site without the WCM functionality turned on the changes that you make to a web form page or master page are seen within that site. In the case of a WCM enabled MOSS site the changes are seen across the site collection -- but no further.

This is because WCM references master pages and page layouts from the root web of a site collection, rather than from the current web. This helps to ensure consistency and can be a great help when making changes with SharePoint designer.

The net effect is that if you have a WCM enabled web site with a single site collection in your environment -- which is possible for some WCM enabled sites designed to interact with the outside world, you may not be able to see an effective difference between having customized pages in SharePoint and having customized the pages on the file system.

Note: You would want more than one site collection in order to break apart the content databases into reasonable sized recovery chunks. Right now the guidance is ideally for 50 GB or smaller content databases. Since a site collection must exist solely in a single content database that means that when you get 50GB or more of content you'll need to split the site collection.

Having Your Cake and Eating It Too

It may be that you don't have one site collection or you're not using the WCM functionality in MOSS -- but you still want to use SPD to do your editing because it is a good editing tool. There is a way to fit the pieces together to get the benefit of SPD without losing the global nature of changes to the files on the file system. The answer is to use SPD to do your editing but instead of doing a save back to the site, do a save as to the file system somewhere and then move this file into the correct location on the server.

Even if you decide to (or accidentally) save files back to the server, you can right click on the file and revert the file to the state that it's in on the file system -- after you make a backup of course. This provides solid flexibility to test your changes out in a safe playground area before trying to apply them to all pages.

Workflows

Up until this point in the article we've been focused on web editing. That's certainly the feature that comes to mind most quickly when people think of SPD but it's not -- by far -- all that SPD can do. One of the other important features in SPD is the ability to create workflows. While configuring the out of the box workflows is easier than even developing a workflow with SPD, building SPD workflows is more flexible than the OOB workflows.

However, the ease of use that comes with the ability for SPD to create workflows comes with a cost. The SPD developed workflows are not able to be transferred from one list to another. They are created with internal GUID identifiers for lists which make them difficult to move.

So while developing workflows with SPD is good for prototyping and one-off scenarios, it doesn't work for a workflow that you need to use over and over again.

Advanced Data Queries

The DataViewWebPart -- which can only be created through SharePoint designer is a great tool for integrating and displaying non-SharePoint data on a SharePoint site with minimal effort. Often times it's the only way to get the results you need without writing code. In fact, this feature alone -- a design surface for creating data view web parts -- often can justify using SPD.

The downside, which is relatively minor, is that pages tend to get customized while developing the DataViewWebPart. The solution is to develop the web part on a scratch page, export it, import it on to the page you want it on and delete the page you created it on. The result is a data view web part with what you want -- without the mess of having customized a page.

Summary

Of course, SPD has many other features which haven't been covered here. The Microsoft Office site for SPD allows you to explore the complete list of features. The point here is that SPD has a great set of tools if you're willing to accept their limitations. You should feel very comfortable unleashing SPD for your pilot -- it's a great tool for rapid prototyping. You should feel less comfortable if you're designing the corporate intranet and you need the entire site to have the same look and feel. But by using techniques to minimize the amount of customized pages that are being created, and accepting the limitations, SPD can be a welcome addition to your toolkit.

Go to page: 1 2  Printer Friendly Version