Site pages vs. Application pages AND ghosted

There’s so many Sharepoint things I want to blog about, I’m having a hard time writing posts that aren’t long and rambling with multiple topics. You’ll be amused to know that I drafted a post a couple nights ago that I titled:

“((‘Customizing vs. Developing,’ OR ‘Site pages vs. Application pages’) AND ‘What does ghosted mean?’) OR (‘How does Sharepoint render any given page?)'”

I know it’s silly to have boolean logic in a title but I couldn’t resist.

But that post suffered from this rambling syndrome (which I’m already prone to), so it won’t see the light of day. Instead, I’m going to try to break it down into smaller consumable bits.

So … let’s talk about the difference between site pages and application pages.

Site pages are pages which live in the Sharepoint database.

Application pages are pages which live on the server’s file system. Application pages usually also execute code, but not always.

In past posts, I’ve mentioned the fact that most everything in Sharepoint is stored in a sql database, not in the file system. Sharepoint adds to this illusion, by using URLs that make the end user *think* there is a file system behind all the pages they access.

On a well-used Sharepoint server, the majority of pages are site pages. However, on a freshly installed Sharepoint server, most of the pages are application pages. You might have noticed that every Sharepoint site has a handful directories which are identical. They are virtual directories, and each points at the same directory. And in fact, these underlying directories are real–holding actual files on the file system of the Sharepoint server. The actual files in these “real” directories (served via virtual directories on every site) happen to be the .aspx pages that are called 90% of the time any user is interacting with Sharepoint. These files are actually code, grabbing content elements from the Sharepoint database, and rendering a page with that content. For example, if you go to any document library, you’ll get the ‘AllItems.aspx’ page.

That’s the same exact page almost every list in Sharepoint calls to display what’s in the list.

Why would Sharepoint do this? Well, it turns out that this is one of the reasons why Sharepoint can scale to support ungodly numbers of sites. A majority of page requests are hitting the same hundred pages which are cached in memory, with a bit of content elements getting filled in from the (fast) sql database.

Sharepoint Designer is one tool that can be used to create and edit Sharepoint pages. In fact, it’s the primary tool that most people will use. *Every* file that Sharepoint Designer creates or modifies becomes a site page. In other words, Sharepoint Designer can’t be used to create or edit a physical file on the Sharepoint server. And as a side note, there is no offline mode for Sharepoint Designer–it only edits live Sharepoint sites (which has some implications you might want to plan around). If you edit a page which happens to have a physical presence, then unbeknownst to you, behind the scenes a copy of that file is stored in the Sharepoint database specific to your Sharepoint site, and the link from your site to that page which usually sends users to the physical file, now sends them to the file in the Sharepoint database. As an example, if you edit the default.master (which you should never do), you aren’t editing the default.master in the file system. Instead, you’ve created a special custom version of the default.master stored in the Sharepoint db which is linked to from your site. In other words, Sharepoint changes the link from the physical file to the virtual file in the database (and makes a complete copy of your edited version to put in the database).

There are ways to create application pages (i.e. pages on the physical file system), but I’ll refrain from going into that now. I’ll also refrain from delving into master pages.

I will mention that an application page (i.e. it has a physical presence) that has been customized so that it becomes a site page is called “ghosted”. This term is an unfortunate one, because it doesn’t have any obvious meaning. Microsoft is apparently trying to kill off the ghosted/unghosted terminology, replacing it with customized/uncustomized (which are so much more obvious in meaning), but they’ve shot themselves in the foot within the Sharepoint framework (the code which Sharepoint developers rely upon) by hardcoding that terminology there which will likely perpetrate the unfortunate terminology.

Leave a Reply

Your email address will not be published. Required fields are marked *