Why customized pages are parsed using no-compile mode?

 Posted by ArticlesMaint on 9/24/2009 | Category: SharePoint Interview questions | Views: 3806

We had discussed previously two types of pages site pages and application pages. Site pages can be customized while application pages are standard pages like ‘settings.aspx’ which is common across sites.

When a user customizes a site page a customized version of the site page is saved in the content database. This provides lot of flexibility but it has its own disadvantages. We can customize site pages using ‘SharePoint Designer’.

Now let’s try to understand how a customized site page which is saved content is processed. Customized site pages are processed in six steps:-
• Step 1:- The user requests a customized page.
• Step 2:- SharePoint HTTP handler i.e. ‘SPVirtualPathProvider’ picks the request and shoots a query to the content database to fetch the page.
• Step 3:- Site page is retrieved and sent to the SharePoint handler.
• Step 4:- The site page data is given to the ASP.NET parser. Please note this ASP.NET parser is not the one which IIS uses. This is made especially for SharePoint.
• Step 5:- Parser parses and gives the output to the handler.
• Step 6:- Handler finally gives the output back to the client.

Below is the reason why non-compiled pages are more efficient then compiled pages.

Compiled pages Non-Compiled pages
Once the compiled ASP page DLL is loaded it gets unloaded only when the App Domain gets recycled. It can be loaded and unloaded. In this scenario the memory management is more efficient.

Asked In: Many Interviews | Alert Moderator 

Comments or Responses

Login to post response