When You Need SharePoint Designer by jgreddy30


									When You Need SharePoint Designer

Robert Bogue


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
When you're using Microsoft Office SharePoint Server
(MOSS) there's a terminology change to be aware of. MOSS                      Newsletters
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 Intranet Journal Update
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.
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.


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.


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.

To top