SP Dev part 2 : Understanding Sharepoint Custom Pages

NOTE: If you haven't read the first post in this series, I would encourage you do to that first, or check out the Sharepoint category. You can also always subscribe to the feeds.

The Sharepoint 2007 System introduces two types of pages the first type usually called Application Pages and other type called Site Pages.

As a sharepoint developer you should know both of these types of pages and when to use them, so let me define them here briefly and show some differences between them to help you decide which type of pages you will want to use when developing in sharepoint.

Application Pages

Application Pages are non customizable and are found in  the C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12TEMPLATELAYOUTS, its worthy to note that this physical directory is mapped to the virtual _layouts directory whenever WSS/MOSS creates a new Web application in the IIS. By using this mapping scheme along with some additional processing logic, the WSS/MOSS runtime can make each application page accessible within the context of any site in the farm.

When building custom application pages you should use the Microsoft.Sharepoint.LayoutsPageBase as a base class and should be content pages that reference to the ~/_layouts/application.master master page, Application Pages might include in line code or have a code behind file compiled in a dll, to deploy application pages they should be the LAYOUTS directory and all custom code dlls either in the GAC.[more]

Standard Application Pages in the WSS

Site Pages (Content Pages)

Site Pages can be customized on a site-by-site basis. default.aspx page in the Blank site is considered a site page as well as the AllItems.aspx used in lists. When customizing site pages this might lead to hundreds of versions of one site pages, site pages have only one physical version and all customized pages reside in the Content Database of the Web Application. This leads us to one important optimization point known as page ghosting, imagine that you have just created 100 new WSS sites from the Blank Site template. If none of these sites requires a customized version of its home page (default.aspx), would it still make sense to copy the exact same page definition file into the content database 100 times? Ofcourse not, rather than copying 100 version of the same page in the content database, the WSS runtime can load the page template from the file system of the Web server and use it to process any request for an uncustomized page instance. Therefore, you can say that 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.

Security consideration : Since the site page can be customized for every customized version, a copy must be stored in the content database, which in turn raises a security issue what if a user having an administrator permission and tries to write in line code within a customized version. This security concern is dealt in WSS by having a default policy that prohibits in line scripting in site pages. The default policy also runs site pages in a no-compile mode, which means they are not compiled into DLLs.



In this part I just scratched the 2 types of pages used in the Sharepoint System I have to say that there is more and more to talk about on this topic which I will write more through this series.







Leave a Reply

Your email address will not be published. Required fields are marked *