Go to page: 1 2  Printer Friendly Version

There are some tools I don't hand my son. He's five and frankly there are reasons why I don't want him working with chain saws. I occasionally need a chain saw to cut down a tree or cut up a fallen limb. But it's not a tool I'd ask him to use.

I feel the same way about SharePoint Designer (SPD) -- in the hands of some and in the right circumstances it can be a powerful tool capable of saving organizations money. However, in the hands of others, it can be a disruptive influence that makes it harder for organizations to have a well governed and used system.

In this article we'll walk through a high-level summary of SPD's features and how these features should and should not be used. At the end of this article you should be able to identify those situations where SPD can be helpful and identify situations where using SPD may be more of a hindrance than a help.

HTML Design

Perhaps the most obvious feature of SPD is seen from the perspective of its Front Page heritage. Even the product's predecessors were HTML designers. They were designed to make the process of editing HTML more usable for the masses. Over the years the tools have "grown up" to include professional-quality editing support. While there are competing products in the HTML editing space, SPD (and its sibling, Expression Web) has a solid set of tools for editing HTML.

Within the context of SharePoint how does this help? SharePoint is built on top of the ASP.NET 2.0 framework and includes both a maser pages and web form pages. Master pages provide a way to develop a consistent look and feel across the site. The individual web pages allow for different layouts and structures to support the needs of the content. SPD is a capable editor of both of these two core file types in SharePoint.

More From Intranet Journal

SharePoint Tutorial: Document Library Send To Feature SharePoint Governance, Part 1 SharePoint 2007 Tutorial: Sorting Out Site Collections If you want to comment on these or any other articles you see on Intranet Journal, we'd like to hear from you in our IT Management Forum. Thanks for reading. - Tom Dunlap, Managing Editor. FREE IT Management Newsletters bITa Planet CIO Update Intranet Journal Update Datamation IT Management Careers Datamation IT Management Update Grid Computing Planet HTML E-Security Planet Text E-Security Planet HTML DRM Watch HTML

When you're using Microsoft Office SharePoint Server (MOSS) there's a terminology change to be aware of. MOSS includes a feature called web content management (WCM). In this feature, there are page layouts to consider. These page layouts are the templates that content is put in. They are -- in essence -- the same web form pages that you might edit directly. The key difference is that they contain content placeholders into which content will be inserted by the WCM subsystem. So pages in Windows SharePoint Services (WSS) -- and non WCM MOSS sites -- are essentially the same as Page Layouts for WCM.

In addition to HTML editing, web site design today is controlled by cascading style sheets (CSS). SPD is a good editor of CSS sheets as well. In the SharePoint world CSS is very important because much of what is displayed is styled with CSS sheets. A great deal of customization of the look and feel can be done without ever editing a master page or a page itself.

From the perspective of working with SharePoint, SPD's key feature is probably its direct integration with SharePoint. It understands the APIs and what to do in order to get pages and content and how to return them safely to SharePoint. In this integration, there are, however, some hidden concerns.

Ghosting, Unghosting, Customized, and Uncustomized

SharePoint works more than a little bit of magic in order to provide users with an easily customizable platform to do work. It leverages both files on the file system and data in a database to virtually create many sites most of which share the same files on the file system. The net effect is that SharePoint gives the appearance that it's many files when in reality it's a relatively small number.

This is accomplished by a technique that used to be called Ghosting. SharePoint contains database entries for each site and each page in the site. By default these entries refer back to a file on the file system. The result of this is that there's good performance and the ability to impact changes on a massive scale just by changing one file. Since every site refers back to that one set of files making a change there has a global impact.

When a change is made with SPD, it cannot make a change directly to the file system. Instead it instructs SharePoint to maintain a copy of the file in the database. This process used to be called unghosting but in SharePoint 3.0 the preferred term is customized. Ghosted would be referred to as uncustomized.

The impact of this is that pages edited with SPD are specific to the site or site collection that is being used and therefore won't take effect over the other sites that might be based off of the same files on the file system. In short, if you want to make a system wide change to the look and feel -- you won't be able to.

Said more succinctly, using SPD to edit pages may lead to inconsistency issues since the changes that are made in SPD don't always take effect everywhere.

Site Collections and Sites

Some of you may be aware that there is a distinction within SharePoint between a regular site, what a developer is more apt to call SPWeb, and a site collection, what a developer is apt to call SPSite. The difference is that a site collection is a boundry object. It defines boundaries for different APIs and for storage as well. A site collection may only be stored in one content database. A site collection is the boundary for many APIs -- for instance, quotas, content querying, etc.

Go to page: 1 2  Printer Friendly Version