AspAlliance.com LogoASPAlliance: Articles, reviews, and samples for .NET Developers
URL:
http://aspalliance.com/articleViewer.aspx?aId=1720&pId=-1
SharePoint Application and Site Pages - Part 1 of 2
page
by Steven Barden
Feedback
Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days): 32168/ 84

Introduction

This article will focus on the concepts of the two main page types that can be found in SharePoint 2007 (WSS): Application pages and Site pages. Since this is a WSS level objective, as opposed to MOSS, you will not need MOSS to review the information provided. Windows Server 2003, WSS and Visual Studio 2005 are all that is needed, with no additional add-ons.

There are two primary types of pages found in a WSS application, Application pages and Site pages. The first type, Application Pages, is generally aspx pages that you will find used across multiple Sites. They are usually the "behind the scenes" administrative type pages. Secondly, Site Pages, are the pages that are used inside an individual site. These are mainly the user level pages that make up the site, for example, the index page. When you enter a site as a user you will probably be viewing Site Pages (like Default.Aspx). In the same way, when you use the administrative pages of a site (like Settings.Aspx), you will likely be working with Application Pages.

Site Pages

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.

The SPVirtualPathAdapter

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.

Wrapping up Site Pages

Furthermore, for security reasons, Site pages are not allowed to run inline code and are marked as not to be compiled. This is done, in-part, so a person with database administrator access cannot place malicious code in a Site page. As a whole, site pages will make up the majority of the pages in a SharePoint site. They are the main pages used by users and designed to be manipulated my users. The next section on Application pages and their differences will cover more on the differences and why.

So, in short, and following the information above, an un-customized Site Page that can be stored as a template and combined with data from the content database is called ghosted, so long as it is not customized. If this page becomes customized to the point that the whole page must be stored in the database, it is called un-ghosted. Site pages tend to use the ~/_masterurl/default.master pages to maintain a consistent look and feel.

Application Pages

As for Application pages, you will find that they are not usually directly part of your Site. Often, standard users will not even see the majority of these files. As stated above, these are generally used as administrative pages. As such, it is common for only administrators to work with these pages. Like Site pages, Application pages generally use a master page to enforce a consistent look and feel, but in this case they will mostly use the ~/_layouts/application.master page.

Which brings up a common question… can you make Site and Application pages look exactly the same? Of course the answer is yes and no. Quoting roughly from the MSDN TechNet, you can create custom application pages to add user interface components to a custom solution, based on Microsoft Windows SharePoint Services 3.0. But unlike Site pages (for example, the default.aspx page), a custom application page is deployed once per Web server and cannot (easily) be customized on a site-by-site basis. So, in many cases, it is likely that your Application pages will look like all other Application pages. They may be made to look like a sites Site pages by using the same Master page, but they then may not look like others Sites. This becomes the problem in trying to make your Application pages look the same to all Sites, as long as the sites look different. It is a common complaint of SharePoint by non-developers who say "we go through the effort to make a whole new look and feel, but certain pages, like error pages, still look like SharePoint, no matter what we do." Now, with that said, you can programmatically change the Master page used in the Application pages to match your Site and Site pages, but there is likely to be a lot of work on your part… in fact there would be a lot of Application page code manipulation. This is what would be needed to make the Application pages of a site make that look like that site, rather than the generic, basic blue you always get in most SharePoint websites. Once you realize the amount of adaptation, then testing required, you would likely do well to ask your manager if he or she really wants to pay for all of this work.

Now before I continue, I want to warn you that the word "layout" is about to be used several times. There is no link between these words in the context of this writing. I recommend for the time being that you simply look at them in different meanings and not think too deep into it.

Now we will look at some differences about Application pages. First off, they are based in the virtual directories in relation to each site. This is what makes them available to every Site because they are common to each SharePoint website, and because they affect the layout of the Application pages versus the look and feel of each site, as described in the Site pages section previously. If you open the IIS controls for the site you are working on, you will see that there are many virtual directories, most of them with an underscore. The two illustrations below are common examples of what you will find when viewing the WSS site settings. The first illustration is intended to display the layout of a SharePoint site while the second layout illustration is intended to display the location of where these virtual directories point to.

Figure 1

Figure 2

Notice especially the _layouts virtual directory. I wrote a previous article on building an empty Feature, specifically for the purpose of describing one way to create an empty Feature (http://aspalliance.com/1640_Developing_and_Deploying_a_SharePoint_Feature__Part_1.all). That article discusses how to layout your project for the specific purpose of emulating the structure of a SharePoint project to make the deploy process move along smoothly. In this case you would do the same, including a mock LAYOUTS directory in your solution that will line up with the layouts directory used in the real SharePoint environment. When you create your own application pages, this is where the pages will be put, so they deploy to the properly corresponding location in your Site. Then you should make your own specific subdirectory, based on your project name or such, to ensure that your pages do not collide with existing pages.

More about Application Pages

With the information stated above, you can see why the application pages will tend to take on a look and feel of their own and why it is so hard to make the Application pages match multiple Sites when those sites use different looks. Now, that said, there are several positive aspects to Application pages. First is that they are file based. Second, they allow in-line scripting where Site pages do not. Finally, they are, by default, compiled into individual DLLs and loaded into memory. In all, it is a fact that they are more powerful and run faster than Site pages.

So why not make a site that runs on all Application pages? Well, it probably could be done, but there are drawbacks to this idea, some which even challenge the idea of using SharePoint in the first place. Application pages do not allow user customization. So, for example, you will not be able to use Share Point Designer, or at least not in the way it was intended to be used to connect to a SharePoint site and manipulate Site pages. Furthermore, it will be more difficult to take advantage of web-parts and lists.

The development and deployment of Application pages is a fairly manual process, as you will later see. You may ask, what if I have a site that will not need Site page features and is going to primarily be a non-user-adjustable site? The initial answer is two-fold. Yes, you can do this, but then, are you really in need of SharePoint? Why not just use ASP.NET alone and avoid SharePoint all together?

That being said, I can make a few examples of where an all Application page site would be useful. The first example is to ask if this is an initial use of SharePoint in your environment. I have asked instructors and others with far more skills in SharePoint than myself a similar question because I can foresee, and have run into, the idea of converting an existing site to SharePoint, while still facing concern or outright hostility from others. For example, you may be in a place that does not yet use SharePoint. So your argument may be that you can or would convert an existing site to an Applications page based SharePoint site, and then slowly "reach out" into SharePoint and pull in functionality. The pages from the original site will of course need to be modified, but it seems to me that this could be one way to make the argument to use SharePoint. Another all-Applications page argument may be that a particular Site does not need a lot of user interaction or web-part usage. Perhaps it will even hook other SharePoint sites and the idea of "speaking SharePoint object model" as well as ASP.NET is useful. No doubt it can be done, but you need to decide if this is what you want.

But again, in the favor of one of the above mentioned ideas, using Application pages to get started, rather than just straight ASP.NET, you may want to consider the ability to deploy functionality as Features, thus pushing your skills along with the needs that just happen to creep in (smile). Another argument to toss around is that with an all Applications page-based site you will not need to build web-parts yet. Along with that, to build a Site page driven Site, you almost must build a master page with user sections and web-part containers. The effort level is higher to satisfy users who may not even need to be included yet. After that, development debugging can be more difficult, at least in part due to the fact that your Site Pages are, by default, held in the content database.

 

Conclusion

On Application pages, you can see some reasons for and against their use. As for the basic comparison of these pages or their use, I would not stop with this reading as there are other points made by other authors who will bring up information I have left out or may be more useful to your case, certainly about the underlying parts that drive these pages. Both types of pages have their purposes. I would simply be cautious in determining what pages are best used as Site pages and what are best used as Application pages. We will cover some example information next.

 


Product Spotlight
Product Spotlight 

©Copyright 1998-2024 ASPAlliance.com  |  Page Processed at 2024-03-28 10:32:59 PM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search