MasterPage
Master page provide the consistent look across the site. you can use custom master page to provide the look and feel of your website. Master page contains the common area and the contentplaceholders. The v4 master page contains 33 content placeholder which further overriden by the page.
What is master pages
Master pages define the common layout and interface for SharePoint pages. The master page displays the persistent elements that you expect to see when you navigate from page to page on a site. These elements can include a company logo, title, navigation menu, search box, and the colors or graphics associated with the business or organization. On a SharePoint site, you might also expect to see a persistent sign-in link, the Site Actions menu, and the Ribbon commands. These elements are all stored in a master page
On a typical SharePoint Team site (based on one of the site templates included with SharePoint), you see that the top and left regions come from the master page, while the middle and right regions come from the content page, in this case, the home page
While the master and content pages are separate, they are merged together at runtime to display as a single web page in the web browser. Both pages are ASP.NET pages, but master pages have a .master file extension and they contain the necessary ASP code and content regions to render both pages on a SharePoint site.
Master page content placeholders
Master pages and content pages work together using a set of replaceable regions, or content placeholder controls. Each content placeholder (which appears as ContentPlaceHolder in the page code) represents content that can be overridden on the master page. Any page on the site can replace whatever is contained within the content placeholder by supplying a matching content control. That content control can even be empty, which would remove the element entirely from the rendered page.In the v4.master page in SharePoint 2010, there are approximately 33 content placeholders that are used to display content and functionality on a SharePoint site. You can see these controls when you open the master page directly. In SharePoint Designer 2010, you can use the Manage Content Regions feature to locate each content placeholder control on the page. You can view the control in both code view and the WYSIWYG editor. In the below example, you see the PlaceHolderSiteName control that is used to display the name of the site.
Another content placeholder that is particularly important is PlaceHolderMain because this is what gets replaced by each content page when that page is viewed in a web browser.
You can change the layout of content on a SharePoint site by changing the location of the content placeholder controls. You may, for example, choose to add more content to the right side of the page. You could do this by adding it to the right side of the master page.
Benefits of using master pages
Available master pages in SharePoint 2010
| Primary master page v4.master | Used for content and administration pages. Provides the interface and layout for SharePoint 2010. | Team Site home page, list and library pages, and site settings page. |
| Minimal master page minimal.master | Contains minimal SharePoint content, used for full-screen functionality or embedded applications. | The home and search results pages on a Search Center, pages that host Word or Excel web applications. |
| Publishing master page nightandday.master | Used for pages on a SharePoint Server publishing-enabled site. | The home page, about us, or press release page on a publishing intranet, extranet, or Internet-facing site. |
| 2007 default master page default.master | Used to support legacy SharePoint sites, which haven’t been visually upgraded to SharePoint 2010. | Home page, site pages, and list pages on a SharePoint 2007 site before visual upgrade. |
What’s new with master pages in SharePoint 2010
New master pages in SharePoint 2010,
Primary master page used for site and application pages
Master page layout uses DIV tags
Master page features in SharePoint Designer 2010
Restricting access to master pages
Customizing master pages
The colors, graphics, text formatting, and other layout properties are specified in one or more Cascading Style Sheets (CSS) that accompany the master page. Most of the styles applied to the default primary master page originate from the core SharePoint CSS file, corev4.css. To style the contents of a master page, you override these styles and introduce new styles in your own style sheets. In sum, designing and branding a SharePoint sites typically involves customizing both the default primary master page and the styles associated with that master pageSite Definitions and Configurations
A site definition defines a unique type of Microsoft SharePoint Foundation website. Several site definitions are built into SharePoint Foundation. A site definition can include more than one site definition configuration. A SharePoint Foundation website is based on particular site definition configuration. For this reason, you can think of a site definition as a family of configurations, although some families contain only one configuration.
The following are the four site definitions whose configurations can be used to create new websites.
The following are the four site definitions whose configurations can be used to create new websites.
- STS includes the site definition configurations for, Blank Site, Team Site, and Document Workspace.
- MPS includes the site definition configurations for Basic Meeting Workspace, Blank Meeting Workspace, Decision Meeting Workspace, Social Meeting Workspace, and Multipage Meeting Workspace.
- BLOG provides a site definition configuration for blogs.
- SGS provides a site definition configuration for Group Work Site.
- CENTRALADMIN provides a site definition configuration for central administration websites.
- TENANTADMIN provides a site definition configuration to support SharePoint Foundation site hosting features.
- WIKI provides a site definition configuration for legacy wiki sites that were originally created in an earlier version of SharePoint Foundation. Because standard site pages on SGS sites are wiki-enabled pages, users do not have to create sites that are specifically for wikis.
- GLOBAL provides a basic configuration used for initializing all other site configurations.
Site definition files are cached in memory on the server when first accessed at run time, which improves scalability and performance by reducing unnecessary data storage or retrieval, and by allowing uncustomized pages to be reused across sites. The information contained in these files is pulled from the cache for each subsequent request.
When site pages are customized, excluding browser-based customizations such as modifications to Web Parts, the pages and their contents are stored in the content database. Uploaded .aspx files are also stored in the database. The contents of customized pages are routed through safe mode parsing, which prevents unsafe server-side code from executing, and which depends entirely on the Safe Controls list—specified in the web.config file of the SharePoint Foundation application's subfolder in C:\Inetpub\wwwroot\wss\VirtualDirectories—to determine which controls can be rendered at run time.
Core Schema Files
The following are the prominent XML files that govern the structure and content of a site definition.
WebTemp*.xml Files
Identify the site definitions and configurations and provide information about how they appear in the user interface (UI) to users who are creating new websites.
Location: %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\1033\XML
Onet.xml Files
Define the navigation areas, specify the list definitions available in the UI, specify document templates and their files, define the base types for lists, and define configurations and modules for site definitions.
Location: %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\SiteDefinitions\site_type\XML
Site Defination :- New sites can be created from site defination. a new site defination can be created from the visual studio.net. A site defination contains the list defination, master page configuration and site action, web part configuration etc which is mendotry to create a site.
WebTemp*.xml Files
Identify the site definitions and configurations and provide information about how they appear in the user interface (UI) to users who are creating new websites.
Location: %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\1033\XML
Onet.xml Files
Define the navigation areas, specify the list definitions available in the UI, specify document templates and their files, define the base types for lists, and define configurations and modules for site definitions.
Location: %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\SiteDefinitions\site_type\XML
Each of these XML files uses Collaborative Application Markup Language (CAML) to define various aspects of a site.
The built-in WebTemp.xml file, and any supplemental WebTemp*.xml files that may have been deployed, specify which site definition configurations are available for creating sites. If you are creating a custom site definition, do not edit the original WebTemp.xml file. Instead, create a custom WebTemp*.xml file as described in How to: Create a Custom Site Definition and Configuration. SharePoint Foundation merges the contents of all WebTemp*.xml files when showing available site definition configurations in the UI. This simplifies installing and uninstalling site definitions, because their contents do not have to be merged into one WebTemp.xml file.
Onet.xml defines the top navigation and Quick Launch areas, specifies a basic set of list types that are available for creation, specifies document templates and their file types, and itemizes the files and "all user" Web Parts that are available for use in site configurations. The global Onet.xml file, from which all other Onet.xml files inherit, defines the base types for lists, which include Generic List, Document Library, Discussion Forum, Vote or Survey, and Issues List.
In addition, Onet.xml uses Configuration elements to define the site definition configurations in a site definition (such as STS and BLOG) and Module elements to define the modules in each site definition configuration. For more information about modules, see How to: Provision a File.
A Configuration specifies the set of lists, Features, and modules that are included when a site is created. For more information about site definition configurations, see How to: Create a Custom Site Definition and Configuration.
Site Defination :- New sites can be created from site defination. a new site defination can be created from the visual studio.net. A site defination contains the list defination, master page configuration and site action, web part configuration etc which is mendotry to create a site.
Site Template versus Site defination
This is really a common source of confusion among SharePoint developers. The fact that site definitions are located in a folder named SiteTemplates multiplies the confusion. Before going into direct comparison, let me define both:
Site Templates : Are snapshots of sites at a point in time. When a user customizes a site from the UI or SPD, the custom template consists of the difference between the original state of the site (determined by its definition) and the state of the site or list when the custom template is generated.
Custom templates remain tied to a particular site definition (for example, the site definition for SharePoint Web sites or Meeting Workspace Web sites), so that if the site definition is not present or is changed, the custom template cannot work.
Custom templates remain tied to a particular site definition (for example, the site definition for SharePoint Web sites or Meeting Workspace Web sites), so that if the site definition is not present or is changed, the custom template cannot work.
Site Definitions : As the name implies, A Site definition is "core definition of a site”. Each site definition emerges through a combination of files that are placed in the 12 hive of WFE during installation of SharePoint. Site definition files include .xml, .aspx, .ascx, and .master page files, as well as document template files (.dot, .htm, and so on), and content files (.gif, .doc, and so on).
Now to the fun part, the comparison :
Site Definitions
|
Site Templates
|
Files are on disk, better performance.
|
Files are in database, less efficient.
|
Highly customizable and extensible (XML and .NET code is much more flexible than UI)
|
Not easily extensible (You are limited by what UI offers)
|
Can provision multiple webs *
|
Can only provision one web
|
Complex to create
|
Easier to create
|
Requires admin access to server for deploying.
|
Installable from a Web UI by site owners.
|
Modifying the site definition after provisioning at least one site from it is not supported and might break existing sites.
|
Custom templates can be modified without affecting existing sites that have been created from the templates(**).
|
* This could be achieved using Provisioning handler (For more info, refer to http://spcodesnippets.codeplex.com )
** Please note that If the site definition on which the custom template is based does not exist on the WFE, the custom template does not work.
** Please note that If the site definition on which the custom template is based does not exist on the WFE, the custom template does not work.
On the surface, it appears that a site template has numerous advantages over site definitions; it is certainly easier to create and deploy, and you can change it without breaking sites that use earlier versions of the template because it is not centralized in the 12 hive. However, the fact that a site template contains everything about a site in a single file makes granular modifications of individual elements very difficult. For many projects, that is a good enough reason to suffer the additional complexity of site definitions.
However, site definitions present a different challenge. If you change an existing site definition in the 12 hive, you run the risk of breaking any sites that were created previously and use the existing definition. (Besides, this is not supported by Microsoft ) , The key is to adopt the same strategy as for the core WSS site definitions:
Keep the definition as simple as possible and use feature stapling for everything else. Feature stapling allows you to add a feature to an already existing site definition. You may think this would be a complete waste of time, because you can simply add the feature into the site definition using far less code than having a feature staple, but when I tell you that
Microsoft does not support modifying a site definition in any way after a single site has been provisioned from that site template, you may reconsider.
Features are not an alternative to site definitions. Features are a complement to site definitions. If you keep the site definition as simple as possible and use features for the majority of a site elements, you gain the benefits of granular control in the development environment while reducing the risks involved in making changes to production systems over the life of the sites.
How can we display a simple custom page in SharePoint?
Ok first thing there is no concept of simple page in SharePoint. There are two types of pages in SharePoint as we discussed in the previous article one is an Application page and the other is the site page.
Application page is a generic page while site pages are custom to a website. To just cool you off lets display a simple Application page first.
Some points to be noted about Application pages:-
Application page is a generic page while site pages are custom to a website. To just cool you off lets display a simple Application page first.
Some points to be noted about Application pages:-
· They are pages which are shared across sites like 'settings.aspx' , which will helps us set generic properties across sites in a site collection.
· The second important part is that we need to save application pages in 'C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS' folder. If you browse to the folder you will find SharePoint's own application pages.
Ok, what we will do is that to build confidence let's make a simple page called as 'SimplePage.aspx'. We are not doing anything great in this we will just write this simple sentence inside the page.
<b> Ohhhh I never Knew SharePoint is so easy </b>
<b> Ohhhh I never Knew SharePoint is so easy </b>
Once you have saved the page just browse to the IIS application and browse to the _layouts folder as shown in the figure below. If you open the page in browser you should see your display message.
Note: - For the next question you need to understand the concept of master pages. If you have not please read it once. Consistent look and feel is one of the most important factor in enterprise portal and SharePoint achieves the same using Master pages.
The above page does not look like a standard SharePoint page?
The above page does not look like a standard SharePoint page?
In order to get the SharePoint look and feel we need to inherit from a SharePoint master page. As a rule you should always inherit from a SharePoint master page so that your sites have a consistent look and feel. So let's modify our 'SimplePage.aspx'. To get the SharePoint style we need to inherit from the SharePoint master page 'Application.Master'.
We have now tailored the 'simplepage.aspx' source code as shown below. We need to do the following:-
· First refer the assembly using the 'Assembly directive.
· Refer the masterpage files as 'Application.master'.
· Import the sharepoint namespace. If we had used the behind code we would have imported this in the behind code itself.
· There are three placeholder one for title , one for centre area and one for the page title. We need to define the placeholders in the child page.
<!- First refer the assembly using the Assembly directive ->
<%@ Assembly Name="Microsoft.SharePoint,Version=12.0.0.0, Culture=neutral,PublicKeyToken=71e9bce111e9429c" %><!- Refer the master page from the _layouts directory ->
<%@ Page Language="C#" MasterPageFile="~/_layouts/application.master"
Inherits="Microsoft.SharePoint.WebControls.LayoutsPageBase" %><!-Import the sharepoint namespace ->
<%@ Import Namespace="Microsoft.SharePoint" %><!-This is the content holder for page title ->
<asp:Content ID="Content3" ContentPlaceHolderId="PlaceHolderPageTitle" runat="server">
Let's learn SharePoint....
</asp:Content><!- This is the place holder for data for main page area ->
<asp:Content ID="Content1" ContentPlaceHolderId="PlaceHolderMain" runat="server">
Oh its Damn Simple.....
</asp:Content><!- This is the placeholder for page title area ->
<asp:Content ID="Content2" ContentPlaceHolderId="PlaceHolderPageTitleInTitleArea" runat="server">
SharePoint is Simple.....
</asp:Content>
<%@ Assembly Name="Microsoft.SharePoint,Version=12.0.0.0, Culture=neutral,PublicKeyToken=71e9bce111e9429c" %><!- Refer the master page from the _layouts directory ->
<%@ Page Language="C#" MasterPageFile="~/_layouts/application.master"
Inherits="Microsoft.SharePoint.WebControls.LayoutsPageBase" %><!-Import the sharepoint namespace ->
<%@ Import Namespace="Microsoft.SharePoint" %><!-This is the content holder for page title ->
<asp:Content ID="Content3" ContentPlaceHolderId="PlaceHolderPageTitle" runat="server">
Let's learn SharePoint....
</asp:Content><!- This is the place holder for data for main page area ->
<asp:Content ID="Content1" ContentPlaceHolderId="PlaceHolderMain" runat="server">
Oh its Damn Simple.....
</asp:Content><!- This is the placeholder for page title area ->
<asp:Content ID="Content2" ContentPlaceHolderId="PlaceHolderPageTitleInTitleArea" runat="server">
SharePoint is Simple.....
</asp:Content>
LOL !...Your SharePoint page now looks like a page.
You can get the source of the simple inline ASPX file attached at the end of the article.
Some couple of points we need to take care regarding implementing behind code in ASP.NET are the following:-
· The first and foremost requirement is that behind code should be registered in to the GAC assembly. In other words we need to code the behind code in a separate assembly / namespace and then compile the same in a DLL. Later we need to register the DLL in GAC.
· Second we need to use the assembly directive to refer the behind code.
Step 1:- So the first step is to make two solution files one is the behind code which goes in separate assembly 'ClassLibrary1' namespace and the other is the ASP.NET web project which has the 'SimplePageCodeBehind.aspx'. We also need to register this DLL in a GAC. So you need to generate a strong name give to the assembly and register the same using the 'GACUTIL' provided by the .NET framework.
Step 2:- The behind code is in a separate assembly as need to register the same in the GAC. We have kept the behind code simple. We have create two label objects and set the value. One of the important points to be noted is that we have referenced the 'System.Web.UI' namespace DLL and 'Microsoft.SharePoint' namespace DLL. The other point to be noted is that the class inherits from 'LayoutsPageBase' class which belongs to 'Microsoft.SharePoint' namespace.
using System;
using System.Data;
using System.Configuration;
using System.Web;
using System.Web.Security;
// need to refer the UI objects of ASP.NET
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;
// Need to refer the SharePoint DLL
using Microsoft.SharePoint;
using Microsoft.SharePoint.WebControls;
namespace ClassLibrary1
{
// Inherit the behind code from 'LayoutsPageBase' class of SharePoint
public partial class _Default : LayoutsPageBase
{
protected Label lblSiteQuestion;
protected Label lblSiteAnswer;
protected override void OnLoad(EventArgs e)
{
lblSiteQuestion.Text = " How can we implement behind code in SharePoint ?";
lblSiteAnswer.Text = " We need to register the behind DLL in GAC";
}
}
}
We need to also register the above DLL in GAC. So we need to generate a strong name and register the same using GACUTIL.Step 3:- Now comes the UI part of the ASP.NET i.e. the ASPX page. Below is the code snippet which shows how the ASP.NET UI looks like.
The first thing to note is that behind code is not referred as code behind but is referred using the GAC public token key. In order to refer it using GAC key we need to use the 'Assembly' attribute for the same.
We have also inherited from the master page file i.e. 'Application.Master' so that we have a consistent look and feel.
The first thing to note is that behind code is not referred as code behind but is referred using the GAC public token key. In order to refer it using GAC key we need to use the 'Assembly' attribute for the same.
We have also inherited from the master page file i.e. 'Application.Master' so that we have a consistent look and feel.
<!-Refer the sharepoint assembly ->
<%@ Assembly Name="Microsoft.SharePoint,Version=12.0.0.0, Culture=neutral,PublicKeyToken=71e9bce111e9429c" %>
<!-Refer the behind code, Note that the behind code is coded in a different assembly and registered in the GAC ->
<%@ Assembly Name="ClassLibrary1, Version=1.0.0.0, Culture=neutral,PublicKeyToken=af6d081bf267e17e" %>
<!- In order to maintain consistent look and feel we need to inherit from the Application.Master page ->
<%@ Page Language="C#" MasterPageFile="~/_layouts/application.master" Inherits="ClassLibrary1._Default" EnableViewState="false" EnableViewStateMac="false"%>
Once we have referred the Assembly and set the Page attributes. Its time to fill the content in the placeholders defined in the master page 'Application.Master'.
<asp:Content ID="Main" contentplaceholderid="PlaceHolderMain" runat="server">
<table border="1" cellpadding="4" cellspacing="0" style="font-size:12">
<tr>
<td>Question</td>
<td><b><asp:Label ID="lblSiteQuestion" runat="server" /></b></td>
</tr>
<tr>
<td>Answer</td>
<td><asp:Label ID="lblSiteAnswer" runat="server" /></td>
</tr>
</table>
</asp:Content>
<asp:Content ID="PageTitle" runat="server"
contentplaceholderid="PlaceHolderPageTitle" >
SharePoint Behind code implementation
</asp:Content>
<asp:Content ID="PageTitleInTitleArea" runat="server"
contentplaceholderid="PlaceHolderPageTitleInTitleArea" >
When we want to implement behind code we need to register the same in GAC.
</asp:Content>
<asp:Content ID="Main" contentplaceholderid="PlaceHolderMain" runat="server">
<table border="1" cellpadding="4" cellspacing="0" style="font-size:12">
<tr>
<td>Question</td>
<td><b><asp:Label ID="lblSiteQuestion" runat="server" /></b></td>
</tr>
<tr>
<td>Answer</td>
<td><asp:Label ID="lblSiteAnswer" runat="server" /></td>
</tr>
</table>
</asp:Content>
<asp:Content ID="PageTitle" runat="server"
contentplaceholderid="PlaceHolderPageTitle" >
SharePoint Behind code implementation
</asp:Content>
<asp:Content ID="PageTitleInTitleArea" runat="server"
contentplaceholderid="PlaceHolderPageTitleInTitleArea" >
When we want to implement behind code we need to register the same in GAC.
</asp:Content>
Note: - Do not try to compile the project in VS.NET IDE. You can only compile the class assembly. The ASPX file you need to later paste it to the '_layout' directory i.e. 'C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS'.
Once you have copied the ASPX file and registered the behind code assembly in GAC, you can run and enjoy how it looks like.
kk
ReplyDelete