One of the interesting feature in SharePoint is you can customize it as you wish. SharePoint provides the different types of technique to customise. Most commonly used types are developing your own custom application page. In this article you can find the basic details of pages you can find in SharePoint.
SharePoint supports two types of ASPX Pages
- Application Page – also known as _layout page
- Content Page
Application pages–
Application pages are typically created to allow users to manage settings for lists, sites, and site collections. These pages are available across the server farm and are stored in the _layouts virtual directory of SharePoint Web sites. This allows these pages to run on any site collection in the farm. Application pages are commonly used when a page must be accessible at any level of a site hierarchy and contain functionality such as managing settings or cross-site reporting.
Application Pages are stored in a site’s Microsoft Internet Information Services (IIS) virtual directory and support application implementations. Application pages include pages with names such as create.aspx, settings.aspx, and other similar _layouts pages
These pages are stored in the virtual directory for the SharePoint Web application. The _layouts directory is also virtualized as a subfolder of every SharePoint site, and is exposed in a site collection or subsite, for example, http://MyServer/_layouts/Mysite.aspx or http://MyServer/a/b/c/_layouts/Mysite.aspx.
By default, If you installed MOSS 2007 then you can find the _layouts in the path C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\Layouts
Content pages–
Content pages are associated with SharePoint Web sites and typically provide content for that site rather than management capabilities. Content pages are stored either in the root of the site or in a library where they can be edited from within the SharePoint user interface or with Microsoft Office SharePoint Designer 2007. Pages that have not been customized, also known as uncustomized or ghosted pages, are stored on the front-end Web server. Pages that have been customized, also known as customized or unghosted pages, are stored in the SharePoint content database.
Content pages can be modified by end users by using tools such as Microsoft Office SharePoint Designer 2007, or uploaded using protocols such as WebDAV. When you create a SharePoint site, many content pages are created automatically, for example, default.aspx, allitems.aspx for your Web Part gallery, editform.aspx as an edit form for your announcements list, and several others.
Content pages are stored logically within their SharePoint sites, and most of the files are also stored physically in their associated SharePoint content database. However, not all content pages are actually stored in the content database.
Customized Content Pages
Windows SharePoint Services 3.0 supports page customization (also known as “ghosting”). However, Windows SharePoint Services stores customized pages differently from unmodified template pages.
Unmodified page template files are stored on disk on the front-end Web server, not in the content database. Customized pages—template pages that a user has modified—are stored in the content database.
In cases where Windows SharePoint Services provisions a page from a SharePoint template, instead of retrieving a page from the content database, the system creates a pointer to the instance of the page template file on the front-end Web server. As a result, Windows SharePoint Services avoids repeatedly creating copies of its content pages, which are provisioned each time a site is created.
This pointer to an instance of the template page on the front-end Web server is created only if the user has not customized the page. After a page is customized (using Office SharePoint Designer 2007, for example), the pointer is voided and the page itself is stored in the content database.
Using Server Side Code on Content Pages
The rules that govern the use of server-side code on content pages are unchanged from Windows SharePoint Services 2.0. That is, in-line server logic declared within SharePoint content pages is generally not supported. This applies only to in-line logic within the page, and does not include code behind Microsoft ASP.NET controls on the page. The set of controls that are allowed to execute is governed separately by the safe controls list.
Following are general rules for using server-side code on a content page:
- If the contents of a page are not customized, server-side code is supported on the page.
- If the contents of a page are customized, server-side code does not execute on the page, and the page does not render.
- It is a recommended best practice to avoid using server-side code on content pages when developing site definitions, because if a user later edits or modifies that page, the code will no longer execute.
An administrator can override the settings that support the general rules. That is, the administrator can add a PageParserPath setting in the web.config file that allows the execution of server-side code on pages stored at a specified path.
Similar Topics:
- Learn Sharepoint 14Hive folder structures
- SharePoint 2010 MSDN article collection for developer
- SharePoint 2010 migration tips
- Creating the custom theme in MOSS Branding
- Enabling IIS6 HTTP compression on SharePoint dynamic page
- Developer favorites SharePoint 2010 enhancements
- MOSS 2007 Best Practices
- Sharepoint 2013 Search components
- Infopath form to HTML using csharp
- Sharepoint best practices advantages of storing scripts in layout folder
