2.7 Creating ASPX Pages
Those of you familiar with ASP.NET
might recognize the .ASPX extension; this is the core ASP.NET Web page.
Because SharePoint is built on ASP.NET, the individual pages within
SharePoint are of this specific type. What sets SharePoint ASPX pages
apart from other ASP.NET sites is that you get a lot of native
capabilities built into an ASPX page when you create it. For example,
SharePoint ships with a number of capabilities such as edit
functionality and Web Part capabilities, and when you create a new ASPX
page it derives parent features and loads and registers dependent
assemblies that are required to render the page and controls on that
page correctly. If you examine the following code in the default Web
Part ASPX page you can see that a number of directives exist that
register specific assemblies to the page. SharePoint requires that
these directives exist. Don’t worry; you won’t have to memorize what
all of them are. SharePoint Designer creates many of them for you by
default, so you can focus on page creation and customization.
<%@ Page language="C#" MasterPageFile="~masterurl/default.master"
Inherits="Microsoft.SharePoint.WebPartPages.WebPartPage,
Microsoft.SharePoint,Version=15.0.0.0,Culture=neutral,
PublicKeyToken=71e9bce111e9429c"
meta:webpartpageexpansion="full"
meta:progid="SharePoint.WebPartPage.Document" %>
<%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls"
Assembly="Microsoft.SharePoint, Version=15.0.0.0,
Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Register Tagprefix="Utilities" Namespace="Microsoft.SharePoint.Utilities"
Assembly="Microsoft.SharePoint, Version=15.0.0.0,
Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Import Namespace="Microsoft.SharePoint" %>
<%@ Assembly Name="Microsoft.Web.CommandUI, Version=15.0.0.0,
Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Register Tagprefix="WebPartPages" Namespace="Microsoft.SharePoint.WebPartPages"
Assembly="Microsoft.SharePoint, Version=15.0.0.0,
Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
You can create a simple ASPX page for SharePoint
without any of the frills that the Web Part pages deliver and the code
for this type of page would look more readable (see the following).
However, note that this page would not contain any of the standard
SharePoint controls and would not inherit the structure and style that
is laid out by the master page.
NOTE Web Part pages are a special type of ASPX page that provide structure using different Web Part zone layouts.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<%@ Page Language="C#" %>
<html dir="ltr" >
<head runat="server">
<meta name="WebPartPageExpansion" content="full" />
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Untitled 1</title>
</head>
<body><form id="form1" runat="server">
</form>
</body>
</html>
Although a couple of different paths exist for
creating ASPX pages for SharePoint, using SharePoint Designer 2013 is
the easiest. This is because not only is code like the preceding
created for you, but you can also use templates to create Web Part
pages — a special type of ASPX page that has Web Parts located in
specific ways on the page. You could alternatively use Visual Studio
2012 to create ASPX pages, but you would have to manually add the
preceding namespace registration directives and then manually add the
page to the appropriate page on the site. By default, SharePoint
Designer can save the ASPX pages you create in a number of places (for
example, the Site Assets library).
Beyond the assemblies that are registered through the directives, you also have HTML markup interlaced with ContentPlaceHolder controls and ASP.NET controls. Again, if you’re familiar with ASP.NET, then these concepts won’t be new to you. If you’re not, ContentPlaceHolder
controls and ASP.NET controls are how you render functional controls or
applications on the ASPX page. For example, one of the default ContentPlaceHolder controls is the search control, which is expressed in the following code:
<asp:Content ContentPlaceHolderId="PlaceHolderSearchArea" runat="server">
<SharePoint:DelegateControl runat="server" ControlId="SmallSearchInputBox"/>
</asp:Content>
Depending on the level of complexity of your ASPX
page, you might have more or fewer of the preceding controls — some
that work independently of one another or others that work
hand-in-glove with one another.
2.8 Creating Master Pages
Master pages are an ASP.NET creation
that SharePoint inherits from being built on ASP.NET. SharePoint uses
master pages to provide a consistent structure and layout for each of
the pages in a SharePoint site. Similar to a single CSS file providing
structure for many Web pages, a single master page can serve multiple
sites and define the look, feel, and behavior that you want for all the
pages of that site. Using the master page as the structural foundation
of your site, you can then add other content or custom applications or
Web Parts to your SharePoint site.
When you install SharePoint, it installs a single
master page to your SharePoint site by default. You can then create a
copy of the default.master
master page and customize it to your liking or add a new, custom master
page that provides the branding and behavior you want for your
SharePoint site. SharePoint Designer provides some great capabilities
for managing, creating, and editing master pages; for example, you can
edit and view your changes from within SharePoint Designer and then
check it in for approval to your SharePoint site.
When a user navigates to a SharePoint site, the
site or content page references a master page, which is then merged
with the page. This produces an output that combines the layout of the
master page with the content from the site page. The following bolded
code shows a token reference (the token being ~masterurl/default.master) to the master page that was used for that site:
<%@ Page language="C#" MasterPageFile="~masterurl/default.master"
Inherits="Microsoft.SharePoint.WebPartPages.WebPartPage,
Microsoft.SharePoint,Version=15.0.0.0,Culture=neutral,
PublicKeyToken=71e9bce111e9429c"
meta:webpartpageexpansion="full" meta:progid="SharePoint.WebPartPage.Document" %>
A master page is characterized by the .master
file extension. The master page itself can contain an array of objects.
For example, the master page can contain HTML, JavaScript, CSS, and
ASP.NET server controls. When you examine the syntax of the master
page, you’ll see text and controls that render a look and feel that is
specific to SharePoint. This is especially true when you look at the default.master master page, which includes all the breadcrumbs and default menu and navigation options that are specific to SharePoint.
However, you’ll also see a series of ContentPlaceHolder
objects (discussed earlier) within a master page, which define regions
where content or controls can appear. When you’re customizing
SharePoint master pages, you need to have a set of ContentPlaceHolder controls on the page, for example, global breadcrumb, top-level navigation, search, and title. You can add more ContentPlaceHolder
controls than are required by default; however, you cannot remove the
ones that are required or else your content or site pages might fail to
render.
The following code snippet shows some of the
different types of text and controls that you can find within a
SharePoint master page. Note that these are taken from the default.master,
which ships with all versions of SharePoint, so you can explore the
full set of code and controls that ship with this master page by
reviewing the file from within SharePoint Designer.
<title id="onetidTitle"><asp:ContentPlaceHolder id="PlaceHolderPageTitle"
runat="server"/>
</title>
<SharePoint:CssLink runat="server" Alternate="true"/>
<SharePoint:Theme runat="server"/>
<SharePoint:CssRegistration Name="minimalv4.css" runat="server"/>
<SharePoint:CssRegistration Name="layouts.css" runat="server"/>
<SharePoint:ULSClientConfig runat="server"/>
<span class="s4-notdlg">
<a href="javascript:;" onclick="javascript:this.href='#mainContent';"
class="ms-SkiptoMainContent" accesskey="<%$Resources:wss,maincontent_accesskey%>"
runat="server">
<SharePoint:EncodedLiteral runat="server"
text="<%$Resources:wss,mainContentLink%>" EncodeMethod="HtmlEncode"/>
</a>
</span>
...
<asp:ContentPlaceHolder id="PlaceHolderWelcomeMenu" runat="server">
<div class="lb ms-mini-trcMenu">
<wssuc:Welcome id="IdWelcome" runat="server" EnableViewState="false">
</wssuc:Welcome>
<wssuc:MUISelector runat="server"/>
</div>
</asp:ContentPlaceHolder>
...
<div>
<asp:ContentPlaceHolder id="PlaceHolderTitleBreadcrumb" runat="server" />
</div>
...
<div id="DeveloperDashboard" class="ms-developerdashboard">
<SharePoint:DeveloperDashboard runat="server"/>
</div>
...
</body>
</html>
When managing your master pages, be
mindful of any changes you make to the existing master pages. In fact,
avoid at all costs editing any of the default master pages that ship
with SharePoint and always copy and edit alternate, renamed copies so
you never lose a snapshot to which you can safely return. If you’re
going to be doing a lot of master page customization in the future,
start with a minimal master page (which contains the bare minimum set
of controls necessary for a SharePoint site) and add onto that as
practice to get familiar with how they work.
