Site pages will almost always be built to use a master page
for the intention of maintaining a consistent look and feel, called
Default.Master. Remember that as opposed to SP03, SP07 truly sits on top of
ASP.NET 2.0, so you get the rich functionality of ASP.NET 2.0 before you even
get up to the SP07 "layer." The majority of these site pages will be
found in the database as opposed to the file system, which is where Application
pages are mostly found. It is not uncommon to find that an unknowing systems
administrator (or want-to-be) has destroyed a SharePoint website looking for
the Site pages. Worse than that, they may even find and mess up the Application
pages, thus affecting all Sites. Because Site pages are stored in the database,
in most cases you can only adjust them by way of tools like adjustable
web-parts or the SharePoint Designer.
Site pages are the safer of the two types of pages because
they are limited in what they are allowed to run. They cannot use code-beside
or code-behind pages and they do not allow in-line coding. As such they gain
their real power from the use of web-parts. You can very well use the Share
Point Designer to build a single page, drop web-part holders on it and so on,
but most often you will likely build a master page, then a template page, link
the two, and then build most of your Site pages from that template combination.
With that, let us touch on the topic of Ghosting, which can
be a very confusing topic for many developers. To begin to understand the real
purpose and power of page ghosting we need to take a step back, into an object
called the SPVirtualPathAdapter. In short, this is the system that allows
SharePoint to store pages in the chosen content database.
In a typical website a page is stored on the disk. But
SharePoint uses the SPVirtualPathAdapter to store pages in the database, in
effect acting as the disk-i/o sub-system. You may ask yourself why this is the
case, and the answer is quick to be supplied. The act of storing Site pages in
a database allows the Site, or more likely, Farm, to scale out to thousands or
tens of thousands of pages. But why?
Quite often, Site pages are generally templates with only a
fairly small amount of different data each. This data is stored in the
database, to be used in specifically located "place-holders" on the
user pages. Performing this functionality within a database is far easier than
doing so on a file system. This task would become far more immense if the files
were stored on disks, where they then needed to be manipulated from that point.
Think of it… you need to load the template, and then speak to the disk, which
picks up the data (assuming the template had already been stored in memory)
then merged. The same actions, using database technologies, is generally much
faster to extract the required changes via stored procedures, rather than
disk-i/o. Inserting the data retrieved from the SQL server into the templates
is then performed.
Now, to really get a handle for understanding the scale of
which SharePoint was designed to be capable of operating at, think of a single
Site, which may have thousands of minimally different pages, for example a
medical information display site or some other form of gigantic or
bibliographic type site. Thousands of those changes may be easily stored in a
database. But retrieving that information could be a significantly slower
process when stored on disk. Just the act of trying to index all of the files,
or break up (organize) and retrieve the information would be quite tough.
ADO.NET is an excellent system for receiving this information, and rapidly
integrating these template pages, as is SQL server for storing, indexing,
organizing, maintaining, backing up, restoring, and so on. But to do all of the
afore mentioned acts, just to then pull that data "up," parse it into
memory, and insert it into these pages is just not as good, much less as
mature, a system. And if you choose to use a file based system, how would you
do this? As small xml files that must be read and parsed from a file system?
No, "blasting the data fire-hosed style" is a much better way to go.
I think you are seeing the point here. Quite simply, it is faster and cleaner
using a database to fill the predetermined placeholders in Site pages. Which,
in a very round about way, best describes the use of the SPVirtualPathAdapter.
Site Page Ghosting
This leads into the question, what is page ghosting and why
do I care? Well, as for caring about it, one reason I know all too well is that
you will get asked about it in the interview process, so you had better know
it, why it exists and how it is used. But the main reason for Page Ghosting is
performance. A page is considered Ghosted if it is not
customized. This is very good for performance.
Ghosting does not mean that it has the same data as the next page, but it does
have the same layout, to use the same un-customized template. It is like many
cars coming off an assembly line. So long as they are the same and have
different people in it, a fleet mechanic should have an easier time maintaining
them. Once one or more are different (a V-8 versus a V-6, automatic, versus
standard) it is now different, thus it is going to cause someone more effort at
some time. As such, an un-ghosted page must be stored as a whole in the
database because separating the differences between the template and the
content is no longer as easy. When so many pages are now "called
upon," the odd-balls (un-ghosted) will provide a performance hit. It is
advisable to keep the pages in groups as ghosted as possible.