Todd Bleeker's 12 Hive

All MindsharpBlogs

Are you pondering what I'm pondering?

My Links

Post Categories


Blog Stats

Ghosted vs. Unghosted

There are at least four reasons (listed from least important to most important) that Mindsharp is a "ghosted-pages only" shop:

4. Separation of data and logic. The OOB SharePoint pages separate what I call the plumbing and custom chrome (direct-mode page) and the data in an elegant way. The page is a standard ASPX page stored in the Site Definition on the file system and all state (data and metadata) are stored in the database. I know that it is somewhat of an "ivory tower" position, but unghosting breaks that separation putting logic into the state store. But maybe you aren't philosophical, so...

3. Ghosted pages are performant, unghosted pages are not. I yield that this is probably trivial but on a common page hit frequently by thousands of people every day, it could certainly prove significant. How many of us moved from ASP classic to ASP.NET to get the 30% boost of a compiled vs. sequentially processed page. Unghosted pages are not JIT-compiled and are processed sequentially by the safe-mode parser rather than JIT compiled and retrieved from memory using the .NET parser. Ghosted has to be faster. But maybe your hardware meets that bar, so...

2. Ghosted pages yield master page-like functionality today, unghosted pages break that functionality today and tomorrow. SharePoint direct-mode pages behave similar to tomorrow's ASP.NET 2.0 master pages. Unghosted pages are stored as static snapshots of the page upon which it was originally based and can even abort if the direct-mode page was heavily modified or contains certain in-line script. But maybe master pages aren't important to you, so...

1. I speculate that ghosted pages will easily upgrade from SharePoint 2003 (v2) to v3 and unghosted pages will likely fail catastrophically. Here's why: Since unghosted pages support almost any kind of alteration that the end user wants to make, I doubt that there will be tools that can handle the conversion from unghosted to v3 master page. I wouldn't want to write one. Given that most pages are unnecessarily unghosted by an unknowing public, many will find themselves with a tremendous task when it comes time to upgrade. They will be sorting through potentially thousands of pages trying to determine which pages truly needed to be different than the direct-mode page (unghosted) and how they can be re-customized in v3. This could add weeks or even months to some upgrades. If we scrutinize alterations today and put them into components (the SharePoint model) we can avoid unghosting except for circumstances where unghosting costs outweigh the alternatives.

These reasons are compelling enough for me. So far, I haven't found a single reason that compelled me to unghost any pages in our environment. It just isn't necessary and the cost is potentially far too high for me. But each company must decide whether they will allow unghosting on their own. As for me and my house, we will not unghost.

<Todd />

posted on Thursday, July 21, 2005 5:53 AM


# Todd muses about the presentation issue too... 7/21/2005 2:56 PM Andrew Connell [MVP MCMS]

# Overriding Style at the Page Level WITHOUT Using FrontPage 10/7/2005 8:55 AM Josh Meyer

# Style Under Cursor CEWP 10/25/2005 3:02 PM Todd Bleeker's 60 Hive

# FlexListViewer-webpart: display lists of other sites without using FrontPage 2/17/2006 7:44 AM Portals

# Guidelines to Centralize SharePoint Style/Script Customizations 3/10/2006 4:25 PM Todd Bleeker's 60 Hive

# Guidelines to Centralize SharePoint Style/Script Customizations 3/10/2006 4:38 PM Todd Bleeker's 60 Hive

# re: Ghosted vs. Unghosted 9/22/2006 10:22 AM Jeff Rush

I've been doing my best to prevent any unghosted pages on my latest SP project, but came across an issue where renaming pages created by create basic page or create web part page unghosts the .aspx page. I understand why this is the case, but does anyone know how to prevent that?

# re: Ghosted vs. Unghosted 9/22/2006 2:10 PM Todd Bleeker

Alas, modifying the properties of these "documents" will also needlessly unghost the page. : (

I am unaware of a way to prevent this behavior except not to modify the name or other properties. However, since these are in document libraries, you could theoretically write an event sink to handle the update event and reghost the page. This could, in effect, maintain your ghosted only environment.


<Todd />

Comments on this post are closed.
Protected by Clearscreen.SharpHIPEnter the code you see: