Monday, December 28, 2009

Examining the differences between "Application Pages" and "Site Pages"

Hi all,

There are lot of differences between "Application Pages" and "Site Pages". To really understand these concepts, we have to examine the WSS 3.0 integration with ASP.NET. So, let's get started.

Q. What are the WSS 3.0 design goals and why we needed WSS in the first place?
A. When WSS 3.0 was not the market, ASP.NET developers had to contentiously create web-sites and they have to be monitored, updated and deleted. Apparently, it takes weeks (if not months) to develop full-fledged sites.

WSS 3.0 has a high-level design goals and are on top of the ASP.NET framework. The basic design goals are:

a) Requires sites to be created contentiously created, updated and deleted.
b) Site provisioning engine:
The act of the provisioning (a fancy word for creating) that allow site administrators to quickly create pages, lists, document libraries etc.

The bigger picture of WSS architecture are
i) Manageability
ii) Scalability

Site pages:

Concept of SPVirtualPathProvider and Page Ghosting: 

>> Strength of WSS over ASP.NET
Its the ability to provision and customize pages within a site WITHOUT to make changes to the local file system.

>> How its done??
Its possible to store customized version of .ASPX and .MASTER files inside the "content database" (SQL Server) and retrieving them on demand when they are needed to process on incoming page requests.

For e.g.

i) We modify the "default.aspx" page using SharePoint designer and save it.
ii) Behind the scenes, WSS will save to this page into "content database" (not in the file-system).
iii)WSS team created a virtual path "SPVirtualPathProvider" that is integrated with every web application.

Its able to retrieve an ASP.NET page from the content database along with ASP.NET run time for parsing.

Typically, web-sites and pages are stored on the disk. Contrary to SharePoint which capitalizes the concept of  "SPVirtualPathProvider"and stores in the content database. Therefore, "Site Pages" get the information from the content database and allows the Site scale out thousands of pages. 

The basic reason:

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.Moreover, if we have thousands of pages using database technologies, is generally much faster to extract the required changes via stored procedures, rather than disk-i/o.

Page ghosting: 

Definition (Ted Pattison):
"Page ghosting describes the act of processing a request for an uncustomized "page instance" by using a "page template" loaded into memory from the file system of the front-end Web server."

In short, a page is considered ghosted its NOT customized. 
There are couple of benefits of page ghosting:

i)  It eliminates the need to transfer the contents of a page definition file from the SQL Server computer with the content database to the front-end Web server computer.

ii) 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.

Therefore it makes is possible to process the home-pages for hundreds different sites by using a single page template.

iii) Its an optimization technique and supports page customization. 

>> Site pages are that support user customization.

>> Examples of "Site Pages" are
associated with lists and document libraries  default.aspx (home page), NewForm.aspx, EditForm.aspx, DispForm.aspx etc.

>> Users can customize and there is NO need to developer.

>> Customized versions (from users) stored in content database and NOT in file-system. The saving and retrieving of content from the database is provided using "SPVirutalPathProvider" class.

>> "Site pages" could exist either in customized(unghosted) or uncustomized(ghosted) state and they are stored in content database.

GHOSTED (uncustomized):
An un-customized Site Page that can be stored as a template and combined with data from the content database is called ghosted. (template + data)

UN-GHOSTED (customized):
Whole page must be stored in the database, it is called un-ghosted.(Whole page)

>> Site Pages DO NOT support in-line code .i.e. . This security feature prevents a user from injecting code into page which may maliciously, or unintentionally, bring down a server, snoop data, etc. 

>> Provides scalability but impact performance and Security
as compared to application pages.   However when page is customized, SPVirtualPathProvider retrieves the customized version of the page from the content database and passes it to ASP.NET parser. Now these pages aren’t compiled into assembly. They are processed by ASP.NET parser in no-compile mode.

Application Pages: 

 Developing application pages for SharePoint can be challenging. pplication pages are .aspx pages that reside in the _layouts folder on each web front-end server, and can be accessed from any site within SharePoint by using the /_layouts virtual folder (for example http://Server/SiteCollection/Site/_layouts/MyPage.aspx). The pages are usually used for administration pages to this end, and in some cases this is the only option.

More details about Application pages:

>> "Application pages" DO NOT support user customization.

>> 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.

>> They have to developed by a SharePoint developer.

>> They are file based and stores on "layouts" under 12 hive.

 >> 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.Thereby give better performance and security.

This post gives a detailed comparison between "Site Pages" and "Application Pages".
Developing an application page is not super easy and in next post, I will walk though to develop an application page.


No comments:

How to display Sharegate administrative dynamic reports via Power BI on SharePoint Online

After working in the SharePoint domain for a couple of years as SharePoint consultant , I am fortunate enough to help customers from man...