site pages vs application pages

I have read few blogs and took out good information about Application pages and site pages.
Also I have mentioned the actual reference url.

*****************************************************
Referenced by:   http://www.codeguru.com/cpp/misc/misc/tools/article.php/c9581
*****************************************************

SharePoint Ghosted and Unghosted Pages

Each .aspx page is rendered by one of two possible parsers. When a request is received for an .aspx page, the SharePoint isapi filter determines who will handle the rendering of the page—Asp.net orthe SharePoint SafeMode parser. The first parser, Asp.net, requires the least amount of introduction. The second parser is unique to Windows SharePoint Services.

The intent of this discussion is to cover the differences between the two parsers. To be very clear, this discussion applies to pages which come from the main application root of a SharePoint virtual server. Pages which originate from either the “_layouts” or “_vti_bin” virtual directories can be excluded from the discussion.

As everyone knows, all pages within SharePoint are stored in the database. This effectively means that for each document, you will find a row in the docs table for that document. The actual file is stored in the Content column. This is true for all files. However, there is one exception – some .aspx pages don’t actually have their content stored in the database. Instead, these pages reference files which exist on the server’s file system. These pages are considered ghosted pages.

From a technical standpoint, ghosted pages are those rows in the docs table which have null values for the Content column and a non-null value for the SetupPath column which points to a file on the file system itself. The referenced file essentially serves as a template and content source.

What pages are ghosted? For example, the default home page is a ghosted page. Any web part pages created the via New Web Part Page user interface also ghosted.

As you can see, I’ve described ghosted pages as the exception to the rule. What does it mean if a document doesn’t reference a template on the file system? Or, more to the point, the Content column actually contains data? These pages are known as unghosted .aspx pages and they are routed through the SafeMode parser.

What does is the main difference between the SafeMode parser and Asp.net? Code compilation.

As everyone knows, Asp.net will parse a page on first render and compile it into an assembly. The SafeMode parser does NOT compile pages. It is designed to interpretatively parse a page and create the object structure of the page. In the event inline server-side code is detected, the SafeMode parser will not allow the page to render. Additionally, the only objects within the page (i.e. controls marked as runat=server) which can be instantiated are those items found in the SafeControls list.

Can a page transition from a ghosted state to unghosted? Yes.

Ghosted pages become unghosted once a file has been modified. If a page is updated using FrontPage 2003, web folders, or the modification of custom document library fields, the Content column of the given document row is populated with the page contents. All uploaded .aspx files are automatically unghosted.

Are there other differences between SafeMode and Asp.net? Yes.

Although the SafeMode parser was designed to be serve as replacement for the Asp.net parser, it does not offer identical functionality. The key differences between the two parsers are listed below:

  • SafeMode does not offer AspCompat functionality.
  • SafeMode does not compile; therefore, all compilation directives are ignored.
  • Session State exists; however, in SafeMode once you turn it on, all unghosted pages are forced to participate in Session State. Unghosted pages do NOT have the option to opt out of using Session State.
Why are there two types of rendering engines? Security and scalability.

The SafeMode parser ensures unghosted pages are not allowed to run code. This security feature prevents a user from injecting code into page which may maliciously, or unintentionally, bring down a server, snoop data, etc. Consider the permission levels associated with updating a page vs. the number of users within a WSS server—if you’re the admin, you would probably be extremely wary of giving anyone the “Add and Customize Pages” right knowing that they would be able to freely execute server-side code if the SafeMode parser didn’t exist. With our current behavior, once a page is transitioned from a ghosted to unghosted state, the admin knows that page cannot influence the behavior of the server.

Additionally, without the SafeMode parser, all pages would have to be routed through Asp.net which would mean all pages would be compiled and their associated assembly loaded into memory. Imagine a site with thousands of operational pages… the memory requirement would be huge. The current design limits page compilation to a very small number of pages relative to the actual number of pages within a WSS-extended virtual server.

How can you tell if a page is ghosted or unghosted? Quite simply—you can’t.

There is no way to determine the state of your page. Unfortunately, this functionality simply didn’t make its way into the product. In an ideal world, you would never need to know if a page is ghosted or not. However, we don’t live in an ideal world.

Is it possible to “reset” an unghosted page to its original ghosted state? No.

This ties into the previous answer. Straight out of the box, there is no way to return a page to its original ghosted state.

*****************************************************
Referenced by:     http://srisharepointdevelopment.blogspot.com/2011/07/app-page-vs-site-pages.html

*****************************************************
Application Pages:

1.These are the normal .aspx pages deployed within SharePoint. Most common of them are the admin pages found in _layouts folder.

2.These are deployed either at the farm level or at application level. If they are deployed within _layouts folder or global SharePoint Virtual Directory, then they can be used by any SharePoint application (available at farm level), otherwise they can be deployed at application level only by creating a virtual directory.

3.These are typical ASP.Net aspx pages and can utilize all of the functionalities available within ASP.Net including code-behind, code-beside, inline coding etc.

4.These are compiled by .Net runtime like normal pages.

5.They can only use master pages available on file-system not within SharePoint Content Databases and for the same reason, you will notice that _layouts pages can only use Application master page deployed within _layouts folder and cannot use any of your custom master page deployed within SharePoint masterpage library.

6.If you deploy your custom ASPX pages within _layouts folder or within SharePoint application using a virtual directory, you will not be able to use SharePoint master pages and have to deploy your master page within the virtual directory or _layouts folder.

7.Application Pages cannot use contents as this concept is associated with SharePoint Page Layouts not with ASP.Net.

8.Since application pages are compiled once, they are much faster

9.Normally application pages are not web part pages, hence can only contain server controls or user controls and cannot be personalized by users.

10.Easiest way to deploy your existing ASP.Net web site within SharePoint is to deploy its pages as Application Pages within SharePoint. In this way you can convert any ASP.Net web solution as SharePoint application with minimal efforts.

11.SharePoint specific features like Information Management Policies, Workflows, auditing, security roles can only be defined against site pages not against application pages.

12.Application pages can be globalized using Resource files only.

Site Pages

1.Site Pages is a concept where complete or partial page is stored within content database and then actual page is parsed at runtime and delivered to end-users.

2.Pages stored in Pages libraries or document libraries or at root level within SharePoint (Wiki pages) are Site Pages

3.You must be thinking why we should use such pages? There are many reasons for this. One of the biggest catch of the SharePoint is the page layouts, where you can modify page once for a specific content type and then you can create multiple pages using the same page layout with different contents. In this case, contents are stored within database for better manageability of data with all the advantages of a data driven system like searching, indexing, compression, etc and page layouts are stored on file system and final page is created by merging both of them and then the outcome is pared by SharePoint not compiled.

4.Site Pages can contain web parts as well as contents placeholders, and all of them are stored per page-instance level within database and then retrieved at run time, parsed and rendered.

5.Another advantage is they are at user-level not at web-application or farm level and can be customized per site level.

6.Since their definition is retrieved from database, they can utilize master pages stored within SharePoint masterpages library and merged with them at run time for rendering.

7.They are slower as compared to Application pages as they are parsed everytime they are accessed.

8.SharePoint specific features like Information Management Policies, Workflows, auditing, security roles can only be defined against site pages not against application pages.

9.Since they are rendered not compiled hence it is not easy to add any inline code, code behind or code beside. Best way of adding code to these pages is through web-parts, server controls in master pages, user controls stored in “Control Templates” folder or through smart parts. If you want to add any inline code to master page, first you need to add following configuration within web.config:

PageParserPaths
PageParserPath VirtualPath=”/_catalogs/masterpage/*” CompilationMode=”Always” AllowServerSideScript=”true” IncludeSubFolders=”true” /
PageParserPaths

10.To add code behind to SharePoint master pages or page layouts, refer to this MSDN article

11.Since Site pages are content pages, hence all SharePoint specific features like Information Management Policies, Workflows, auditing, security roles can only be defined against site pages.

12.Variations can only be applied against Site pages for creating multilingual sites.

13.”SPVirtualPathProvider” is the virtual path provider responsible for handling all site pages requests. It handles both ghosted and unghosted pages requests as shown below

*****************************************************************
Note: This article information may not be perfect since its just copied from other blogs.

Thanks!
Avinash

calendarMarch 21, 2012 · cardInfoyen · commentsNo Comments
tagTags: , , ,  · Posted in: MOSS, SharePoint

Leave a Reply

Spam Protection: , required

myworldmaps infoyen