Before we get into the nuts and bolts of customizing pages and applying branding to sites, let’s take a step back and quickly look at how branding and page rendering work in SharePoint.
The SharePoint page model is based on the ASP.NET model—that is, each page refers to a master page that defines a number of placeholder controls that can be overridden with custom content. By using master pages, you can apply a lot of global branding by customizing the appropriate master page. All pages that make use of the master page will automatically incorporate the changes.
This might seem like all you need to know in order to brand SharePoint—you can simply make the changes you need in the master page and the job’s pretty much done. Unfortunately, however, it’s not quite that simple. Although master pages are undoubtedly a good thing when it comes to maintaining consistent site design, one of their drawbacks is that as more and more placeholders are added, the pages become more and more difficult to customize. Placeholders may contain content for some pages and not for others, or, some pages may hold a little content while others hold a lot. Creating a design that can accommodate all these variables is challenging, and as the number of placeholders increases, so do the challenges. Within SharePoint 2010 are two main master pages: v4.master, which is used by most of the pages generated by SharePoint and is found at %SPRoot%/Template/Global, and Simplev4.master, which is used as a failsafe for a few pages such as Login.aspx, Error.aspx, and AccessDenied.aspx. As you can imagine, given the extensive functionality of the platform, v4.master contains many placeholders. Along with these main master pages are also a few others such as Applicationv4.master, mwsdefault4.master, and dialog.master, which are used to support specific aspects of functionality.
CAUTIONDo not change the V4.master page in the Global folder. Doing so could seriously damage your SharePoint installation and may require a reinstall to fix. Generally speaking, you shouldn’t need to customize any of the built-in master pages. Each site can make use of a custom master page for both application pages and usergenerated pages.
Creating a Custom Master Page
Although every site has a master pages gallery, and master pages stored there can be bound to a site using code or manually via SharePoint Designer, only the master pages that are stored in the root site of the site collection can be bound to sites using the SharePoint user interface. This allows site collection administrators to retain control of the master pages that are available throughout a site collection. Bearing this in mind, let’s create a new site collection for the purposes of this demonstration:
We’ve specified that our custom master page should be used for all publishing pages within our demo site. Before we can see our master page in action, we need to add a new publishing page. Navigate back to the site home page and then, from the Site Actions menu, select New Page. Type the page name as My New Page and then click OK.
A new publishing page that uses our custom master page will be added to the site. If no changes were made to the master page, we’ll see a basic rendering of the page contents. In this example, you’ve seen how to create a custom master page for use with publishing pages. If you want to create a master page that can be used to replace the system master page, you can follow the same process. However, rather than creating a page using the From Content Type button, you can copy the v4.master page and rename it before making customizations. The Publishing Master Page template does not contain all the placeholders that are required by a system master page.
Using Master Page Tokens
You’ve seen the process for creating master pages using SharePoint Designer as well as how to specify the default publishing master page for a site. But what happens if you’re not using a publishing page, or if you want to use a specific master page for a particular page on your site? Using SharePoint Designer, you can specify the master page to use on a page-by-page basis. While it’s perfectly acceptable to use a standard path for a master page reference, such as this,<%@Pagelanguage="C#" MasterPageFile="~/MyMasterPages/default.master%>
the SharePoint page rendering engine also includes two dynamic tokens that can be used to refer to master pages. By using dynamic tokens, you can change the value of the token and therefore change the master page that is applied to all pages using the token. Pages with a hard-coded master page path would each have to be updated any time the master page changed.
The following dynamic tokens are available:By default, both of these tokens refer to;/_catalogs /masterpage /default.master.
Their values can be changed programmatically using the SPWeb object or by using SharePoint Designer as follows:
In addition to the dynamic tokens ~masterurl/default.master and ~masterurl/custom. master, SharePoint also provides two static tokens, ~site/<your master page name> and ~sitecollection/<Your master page name>. These tokens refer to the master page gallery at the site level and site collection level, respectively.
Take a look at the v4.master page, and you can see that the page comprises a number of different controls, such as SharePoint:SPRibbon and SharePoint:SPLinkButton. To a certain extent, truly mastering SharePoint branding and user interface design comes down to knowing what all of these controls are and how each one can be customized. However, before we start thinking about how to master UI customization, we need to pay particular attention to one other control: SharePoint:DelegateControl. A delegate control is a SharePoint-controlled placeholder. All master pages make use of ContentPlaceHolder controls to dictate the areas of the page that can be populated with content that’s defined in the content page. The delegate control does the same thing, except the content is determined by the configuration of the SharePoint site that is hosting the page. One example of this is the search box functionality that appears on most pages. This is defined on the v4.master page as a delegate control with the ID SmallSearchInputBox. Depending on which features are enabled on the site, this delegate control may be implemented using a Microsoft. SharePoint. WebControls. SearchArea control or a Microsoft. SharePoint. Portal. WebControls. SearchBoxEx control. The configuration of a delegate control is done via an Elements.xml file that is usually deployed as part of a feature. If we wanted to replace the search box on all pages of our site, we could create an elements file with XML similar to the following:
The creation and deployment of elements files is covered In this, the main point that you need to know is that delegates are configurable place holders and can be used to swap out page markup or controls. In this sample, we’ve created a delegate that loads an assembly; you can also create a delegate that refers to a user control by setting the ControlSrc attribute of the Control element rather than the ControlClass and ControlAssembly attributes. One other important attribute of the Control element is the Sequence attribute. Because it’s possible that a given site may have more than one definition for a single delegate, the Sequence attribute is used to determine which one takes priority. The delegate with the lowest number will be displayed.
Cascading Style Sheets
Although master pages do the job of determining how the markup for the completed page fits together, best practice dictates that the styling of the completed markup is the job of Cascading Style Sheets (CSS). In much the same way that master pages can be configured at the site level, so can style sheets. Using the Master Page option in the Look and Feel section of the Site Settings menu, you can specify an alternative style sheet for all pages on a site.
Themes have been around for a while as an option to customize the visual appearance of SharePoint. Introduced in SharePoint 2003, the themes that were available in SharePoint consisted of a custom style sheet that could be applied to a site by a site owner. Although this approach worked well, it did have a drawback in that style sheets could be created only by web designers with some experience of styling the SharePoint platform. Given the complexity of the built-in style sheets, this was no easy feat. With SharePoint 2010, things have moved on considerably. It’s no longer solely the domain of a developer to create custom styles; nontechnical users can now create and modify styles easily by using the SharePoint user interface.
Themes from a User’s Perspective
An important consideration when it comes to themes is that they are now packaged using an OpenXML file format. As a result, themes can be created in and shared among many Office applications. For example, you can create a theme in Microsoft Word and export that theme for use in SharePoint. To see how themes work from a user’s perspective, navigate to the demo site that we created earlier. From the Site Actions menu, select Site Settings. Then, from the Look and Feel section, select Site Theme.
NOTE Customizing themes using the user interface requires the SharePoint Server Publishing Infrastructure to be activated at the site-collection level. Using the controls in the Customize Theme section of the page, shown next, you can specify colors and fonts for a number of standard text types and preview your custom theme.
Themes from a Developer’s Perspective
Users can customize themes by overriding a number of standard elements such as Accent 1 or Hyperlink. Let’s look at how the new SharePoint theming engine takes this information and converts it to CSS for use by the user interface. Out of the box, themes are stored in the %SPRoot%TemplateGlobalListsThemes folder, and, as you can see by examining the contents of this folder, they are packaged with a .thmx extension using the OpenXML format. (We’ll look at OpenXML in a bit more detail in Chapter.) Effectively, an OpenXML file is a ZIP archive containing a number of XML files and other content such as images. It is generally considered best practice to refer to style sheets within the SharePoint platform using a CssLink control and a CssRegistration control. You can see examples of these controls in the v4.master page. The CssLink control acts as a placeholder for the output of CSS links for a page and is generally placed in the header, whereas a CssRegistration control can be used anywhere within a page or in the child objects that make up a page, such as user controls and web parts. The CssRegistration control contains details of a particular style sheet that should be linked to the page. At runtime, before the page is output, the style sheets referred to by all of the CssRegistration controls within the consolidated control hierarchy of a page are collated and output by the CssLink control. You can see this in action if you look at the output for any SharePoint page without a theme applied; in the header of the page, you’ll see tags such as these:
This dynamic generation of CSS links is leveraged by the SharePoint 2010 theming engine. If you apply a theme to a site and then look at the output HTML, you’ll see that the CSS links have changed to these:
Notice that the style sheet links have changed and now refer to the _themes folder for the current site. When a theme is applied using the user interface, the SharePoint platform automatically generates style sheets and image files based on the theme and stores these files within the _themes folder. You can see the generated output by browsing to the referenced folder using SharePoint Designer.
Supporting Themes in Custom Style Sheets
One of the properties of the CssRegistration control is EnableTheming. As its name suggests, this is a Boolean value that dictates whether the referenced style sheet should be replaced with a themed alternative if a theme is applied to a site. When creating custom style sheets, you’re not required to support themes—after all, maintaining a consistent style may be the aim of a custom style sheet. However, to use themes in a custom style sheet, you will need to create some additional markup. Looking at Core.Css (%SPRoot%/Layouts/1033/ Styles/Core.Css), you can see a few interesting comments, such as these:
These comments are used by the theming engine to generate style sheets and images dynamically that make use of the various attributes of the theme. Notice that by using the RecolorImage tag, you can recolor images based on theme colors. You have to admit, that’s pretty clever!
Share Point 2010 Related Interview Questions
|Web Services Interview Questions||XML Interview Questions|
|Share Point 2010 Interview Questions||ASP.NET Interview Questions|
|Share Point Administration Interview Questions||BizTalk Admin Interview Questions|
|Microsoft Office SharePoint Server (MOSS) Interview Questions||Biztalk Server Interview Questions|
|Asp Dot Net Mvc 4 Interview Questions||Biztalk Esb Toolkit Interview Questions|
|InfoPath Interview Questions|
Share Point 2010 Tutorial
The Microsoft Sharepoint 2010 Platform
Developing With Sharepoint 2010
Presentation Layer Overview
Client Object Model
Infopath Forms Services
Enterprise Content Management
User Interface Customization
Application Services Overview
Service Application Framework
Word Automation Services
Data Access Overview
Linq To Sharepoint And Spmetal
Business Connectivity Services
User Profiles And Social Data
Packaging And Deployment Model
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.