Frontpage 2003 can hurt your WSS sites
I'll start by providing a little background and explain the concept of a site definition in Windows SharePoint Services (WSS). Once you truly understand what makes up a site definition, I can then discuss what really happens when you begin to customize pages in a WSS site with Front Page 2003.
1. WSS 站点及其内置站点定义的基本结构
The fundamental architecture for WSS sites is based upon site definitions. In physical terms, a site definition is a directory structure that exists within the file system of every front-end Web server inside a WSS deployment. When you install WSS on a front-end Web server, the installation program copies the directories for the standard built-in WSS site definitions to the following path.
C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\TEMPLATE\1033
WSS automatically installs two standard site definitions named STS and MPS as shown in figure 1. If you install SharePoint Portal Server 2003 (SPS), there will be these two WSS site definitions and also several additional site definitions created by the SPS team whose names all start with the "SPS" prefix.
Figure 1: WSS provides two built-in site defintions named STS and MPS.
The directory structure for each of these site definitions contains a Web Part page named default.aspx. For example, the default.aspx that is directly located inside the STS site definition directory is used to define the standard home page for all SharePoint sites created from WSS sites templates such as Team Site, Blank Site and Document Workspace.
In addition to the default.aspx home page, the directory structure for a site definition also contains a bunch of XML files that contain a special XML-based language called Collaborative Application Markup Language (CAML). These XML files and the CAML contained within them is what truly makes up the definition for a WSS site. Hmmm, this is probably why there are called site definitions!
For example, each site definition contains a file named onet.xml that contains CAML-based information about the structure of each and every site created from that site definition. By customizing onet.xml, you can add elements to the top-level NavBar of your sites. You can also add or remove available list types and configure which list instances are automatically created when a new site is created from that site definition.
There is also a CAML-based XML file for each list type named schema.xml. The CAML in schema.xml is what SharePoint's core architecture uses to define the structure of a list type. For example, the schema.xml file for a specific list type defines the name and type of each of its columns as well as the standard views associated with the list type.
Now here's a critical point about site definitions. A site definition defines the exact structure of a site when it is initially created. However, as soon as users begin to customize a site using the browser or Front Page 2003, the site begins to drift away from what is defined by its underlying site definition. However, WSS is able to track how each site deviates from its underlying site definition by recording the customizations within the content database.
Let's look at an example. Imagine that you and I each create a separate site from the Team Site template. We will have identical sites initially. That's because both neither of our sites has been customized to be any different from the underlying STS site definition. However, once I begin to add custom Web Parts to my home page and you create a new custom list, our sites begin to drift apart from each other and from the underlying STS site definition. All the while, WSS is recording our customizations inside the content database.
2. Page Ghosting-WSS提供的一个重要特性
WSS provides an important feature known as page ghosting. Here's how it works. When you and I each create a new WSS site from the Team Site template, the home page for both of our sites is defined by the default.aspx file in the STS site definition. Due to the fact that there is really nothing initially different about the definition of default.aspx between your site and my site, it would be inefficient if WSS copied the exact same file into the content database for both of our sites. Even worse, think about a WSS deployment with 10,000 Team Sites? It would really be wasteful to insert 10,000 identical copies of default.aspx into the content database.
Page ghosting allows WSS to maintain a single copy of default.aspx within the STS site definition and use it whenever it needs to render the home page for any site. WSS simply loads this ghosted page into memory on each front-end Web server and uses it whenever its needed. As long as your site doesn't require a customized version of default.aspx, WSS will use the ghosted version that it has cached in memory.
While the page ghosting feature of WSS provides some nice performance benefits, its real value is that it makes it possible to make sweeping modifications to existing sites that have already been created. If you open up and modify the default.aspx file of a site definition and save your changes, you can effectively change the appearance and behavior of every site that has been created from that site definition. This includes existing sites as well as sites created in the future. The key point is that working directly with site definitions provides a reliable (yet grungy) way to make a set of sweeping changes to a large number of existing sites.
3. Unghosted Page-使用Frontpage 2003编辑default.aspx会导致unghosted版本的default.aspx页面存入content数据库
Now, here's the problem with Front Page 2003. Let's say you open your site with Front Page and then open default.aspx in the page designer. If you modify default.aspx and save your work, Front Page does not save your changes back to the default.aspx file in the underlying site definition. Instead, Front Page saves a custom version of default.aspx back in the content database. Now your site has what is known as an unghosted version of default.aspx. In fact, you don't even need to make actual changes for Front Page to unghost a Web Part page. If you simply open default.aspx in page designer supplied by Front Page and click the Save button, your site now has an unghosted version of the page.
Now, finally, I can explain where unghosting can hurt you. Let's say I want to make a change to the home page of everyone's site. To do this I go back and modify the default.aspx file in the underlying site definition. My changes are then applied to everyone's site except your site. Why is that? Because you are the only one with an unghosted version of default.aspx. Since you have an unghosted page, your site no longer stays in sync with changes made to the underlying site definition.
4. Conclusion
Don't get me wrong. I am not saying that Front Page 2003 has no value to SharePoint developers. If I am working in a WSS deployment that has a single site or just a handful of sites, Front Page 2003 can be a really effective tool for quickly branding and customizing Web Part pages. I can even use Front Page to create a highly-customized site and then use it to create a user-defined site template. This site template makes it possible to create as many sites as I would like with the same look and feel.
The problems start with Front Page when you need to work in an environment with many existing site. Front Page requires you to make changes to one site at a time. Furthermore, you are required to open each existing site while in the production environment and perform what's akin to open heart surgery. If you make one mistake and hit the Save button, your phone is going to start ringing off the hook (been there, done that!).
If you want to make a change to the home page of 1,000 existing site, Front Page isn't the right tool. You need to work at the level of customizing site definitions. When you work in this space, you have seen that Front Page can even get in the way and cause problem due to unghosting.
---------------------------
本文属于转载
URL: http://msd2d.com/newsletter_tip.aspx?section=sharepoint&id=69a4775a-0063-4e24-a9eb-f853ac4f584e
Submitted By: Barry Kouda
Posted On: 8/24/2004