Site Page :
- Site pages are pages that are created, edited, and customized by end users.
They are primarily used for the content in a site.
Site pages come in two types—a standard page and a Web Parts page.
A standard page contains text, images, Web Parts, and other elements.
A Web Parts page contains Web Parts in Web Part zones. They have a predefined layout that uses Web Part zones.
Both types of site pages are edited using a Web browser or Microsoft SharePoint Designer.
Site pages are provisioned from a template page that is stored on the file system of the front-end Web server. When a site is provisioned, SharePoint Foundation creates a pointer to the instance of the page template on the file system. This allows SharePoint Foundation to avoid repeatedly creating copies of the pages, which are provisioned each time a site is created.
When a user customizes a site page, the template for the page is then stored in the content database. The page is retrieved from the content database every time it is requested by a user.
A customized page can, however, be reset to the original template page through the Web browser or a tool such as SharePoint Designer.
Customized site pages cannot contain in-line server code. The set of controls that are allowed to run on the page is governed by the safe controls list in the <Drive>:inetpubwwwrootwssVirtualDirectories<port number>web.config file.
It is a recommended best practice to avoid using server-side code on site pages when developing site definitions. If a user later edits or modifies that page, the code will no longer run.
The following are general rules for using server-side code on a site page.
- If the page is uncustomized, server-side code is supported on the page.
- If the page is customized, server-side code does not run, and the page does not render. This includes the code-behind for the page itself.
An administrator can add a PageParserPath setting in the web.config file that allows server-side code to run on pages stored at a specified path. This can be a single, specific page or an entire directory of pages.
Adding PageParserPath settings gives anyone who can upload pages to the specified folders the ability to write arbitrary, full-trust code to the server. Administrators should use extreme caution when providing these settings and understand the security implications to this action.
The following sample shows a PageParserPath setting that uses a wildcard. Adding this PageParserPath will allow anyone with permissions to the master page gallery to upload server-side code. Use extreme caution when adding this type of PageParserPath setting.
<PageParserPath VirtualPath=”/_mpg/*” CompilationMode=”Always” AllowServerSideScript=”true” IncludeSubFolders=”true”/>
Application Pages :
Application pages are used to support application implementations in SharePoint Foundation.
Application pages are stored on the file system of the front-end Web server in the %ProgramFiles%Common FilesMicrosoft Sharedweb server extensions14TEMPLATELAYOUTS directory and exist for every site in a Web application.
This folder is mapped to an Internet Information Services (IIS) virtual directory called _layouts. Every site and subsite will have access to the application pages by using the _layouts virtual directory.
For example, http://myserver/_layouts/settings.aspx and http://myserver/subsite/_layouts/settings.aspx access the same application page on the front-end Web server unlike site pages, which are an instance for the specified site.
* Application pages are not subject to the same restrictions as site pages. They allow in-line code without restriction.
* They cannot, however, use dynamic Web Parts or Web Part zones or be modified using SharePoint Designer.
* Modifying the default application pages is not supported in SharePoint Foundation. Custom application pages can be added to a subdirectory inside the _layouts folder.