Web Content Management
SharePoint is predominantly a web-based development platform. Of course, as you’ll see in later chapters, much more is going on behind the scenes than simply generating and publishing web pages; fundamentally, the fact remains that the main user interface for SharePoint is rendered via HTML. Web content management, therefore, touches upon a number of fundamental aspects of the SharePoint platform itself. In this section, we’ll look at how web content is generated by the SharePoint platform and then move on to look at how the generation of such content can be managed using the techniques that you saw earlier in this in relation to managing other types of content.
Although SharePoint is based on ASP.NET, the mechanism by which pages are generated is a bit different from the traditional ASP.NET page rendering model.
TIPIn practically every SharePoint book you’ll ever read, somewhere you’ll find an assertion to the effect of “SharePoint is based on ASP.NET; therefore, SharePoint pages can be customized using the same tools and technologies that you’d use to generate standard ASP.NET pages.” Although this is undoubtedly true, it is not quite as simple as it seems. At a fundamental level, SharePoint is based on ASP.NET, but in practice, building web applications using SharePoint is probably 20 percent ASP. NET programming and 80 percent SharePoint-specific programming. This is a critical consideration if you’re new to SharePoint.
SharePoint makes use of master pages, an ASP.NET concept, but with a slight twist: SharePoint master pages must have certain placeholders defined. While we can add custom placeholders, as we might if we were creating an ASP.NET site from scratch, the mandatory placeholders that are defined by SharePoint host all of the content that is generated by the SharePoint platform. As a result, master pages are of limited value when it comes to customizing specific pages. More often than not, an entire site or even site collection will make use of a single master page.
Page Layouts and Content Types
A more effective way to control the layout of SharePoint-managed content is through the use of page layouts. Page layouts are a SharePoint-specific concept and are used in conjunction with master pages to compose a complete web page. If we were creating a standard ASP.NET application, we may define a master page with common elements such as a header and footer. We would then create an ASP.NET page that referenced the master page and replaced the content of any placeholders defined on the master page. To a certain extent, page layouts in SharePoint work in the same way. However, the key difference is that if we were using ASP.NET, we’d enter content directly onto the page; when using SharePoint, the content for the page is retrieved from the SharePoint content database and is added to the page using field controls. In effect, a page layout acts as a template for pages that are created from a specific SharePoint content type. It is the content type that determines which fields are available to be included in the page layout. Each SharePoint site contains a Master Page gallery containing both master pages and page layouts. Only master pages and page layouts that are stored in the root site of a site collection can be used to create new pages. Although most content in SharePoint can be accessed by selecting Site Actions | View All Site Content, the Master Page gallery can be accessed by selecting Site Actions | Site Settings and then selecting Master Pages under Galleries. If the site is not the root site, select Go To Top Level Site Settings under Site Collection Administration, and then select Master Pages under Galleries.
Field Controls and Columns
This takes a deeper look at how the SharePoint data structure is built up. From a page-rendering perspective, you need to know that a content type specifies the fields that are present for a particular piece of content. For example, a sales invoice may contain a customer reference, an invoice date, and an invoice amount. To a certain extent, a content type is also a template, with the difference being that a content type defines a template for the storage of data, whereas a page layout is a template for the presentation of data. Each page layout is bound to a single content type, although more than one page layout can use the same content type.
You’ve seen how a page layout is analogous to a content type from a presentation perspective. When it comes down to showing actual data on the page, each column or field also has a default field control, and this control provides the default user interface used to display or capture data for a specific field. For example, our sales invoice content type defines a Customer Reference field. The Customer Reference field may be of type Customer Lookup. When the page is displayed in read mode, a Customer Lookup field might render the name, address, and reference number of the customer. However, when the page is in edit mode, the Customer Lookup field type may provide customer search facilities, allowing the user to find the appropriate customer. Behind the scenes, the data required by the Customer Reference field is stored within the SharePoint content database in the same way as data entered in a SharePoint list. For an example of how to create custom fields and field controls.
Now that you have a good understanding of how a SharePoint page is composed, let’s move on to look at how these capabilities come together to deliver web content management in SharePoint 2010. One of the first requirements of any web content management system is the ability to publish content and, more importantly, to allow editors and administrators to control the publishing process. As described, by using custom workflows, you can implement practically any business process that may be required. The main difference between creating web content and other document managed content is in the primary user interface. Other types of managed content commonly make use of a specific tool such as Microsoft Word, which has rich functionality for the creation and layout of word processing documents. However, generating web content is a different story. With rich client applications such as Word, the content creator is free to use all the features of the product without having to consider how the finished result will be rendered to the reader, since the reader will be using the same client application. Web content, on the other hand, must accommodate a much wider audience, and limitations must be in place regarding how the content is presented and, therefore, on the functionality exposed to content creators. Defining these limitations and enforcing them is an important difference for a web content management system. To see how SharePoint 2010 addresses these issues, let’s work through a demonstration.
Create Page Content Type
We start by creating a page content type:
Create Page Layout Using Content Type
Now that we have a custom content type with an additional column for product information, we can create a page layout that uses this data structure.
Edit Page Layout Using SharePoint Designer
Although we’ve created a page layout based on our content type, by default no fields other than the page title will be displayed. We can edit the page using SharePoint Designer to show how pages are constructed.
The toolbox includes many controls, most of which will be familiar toASP.NET developers. However, an additional section, SharePoint Controls, contains the items that we’re interested in for the purposes of this demonstration. Within SharePoint Controls are a few sections that warrant some further explanation.
Data View ControlsAs you’ll see throughout this book, for the most part, document libraries and lists are rendered on the page using a Data View web part. Effectively, the Data View web part makes use of an Extensible Stylesheet Language Transformations (XSLT) template to transform XML-based data from an SPDataSource control. SharePoint Designer makes it easy to create XSLT templates by providing a full WYSIWYG interface, and as part of this, Data View controls can be dragged onto the Data View web part design surface to include specific fields in the template.
Server Controls (SharePoint) Server controls are SharePoint-specific custom controls. These controls inherit from the Microsoft.SharePoint.WebControls.SPControl and are registered as safe for the web application to which SharePoint Designer is connected. Page Fields (from <ContentType Name>) Page fields are derived from the columns that are bound to the content type on which the page is based. In our example, we created a custom content type named Product Page. The page fields that are shown in the toolbox are the default field controls that are bound to that content type.
Content Fields (from <ContentType Name>) Content fields work similarly to page fields and are grouped separately for convenience rather than because they are fundamentally different. The main difference is that content fields are generally based on field types that are enabled by the SharePoint Publishing feature.
Create a Web Page Using Layout With our layout page in place, we can now create new web pages based on the layout. You’ll see how page creation works from a content creator’s perspective. Before we can allow users to create pages on our site, we need to enable the SharePoint Server Publishing feature.
When the Publishing feature is enabled, a Pages document library is automatically added to the site. All new pages that are created are stored in the Pages library by default. Since we’ve created a custom content type that we’ll use for our pages, we need to add this content type to the Pages document library before we can create pages using it. Take the following steps:
We can now create new pages using our custom layout and content type.
Customize the Page Editing Experience
You’ve seen how easy it is to create pages using page layouts and also how custom page layouts can be used to control the formatting and layout of pages within a site. However, one of the key administrative and editorial requirements of a web content management system is the ability to restrict the type of functionality that is available to content creators to ensure that any created content properly adheres to organizational standards.When we created our page layout and dragged our Product Description field onto the page, a RichHtmlField control was added automatically. The various properties of the RichHtmlField control are the key to customizing the editing functionality for content creators.
For security reasons, it’s considered best practice not to make an internal SharePoint farm accessible via the Internet. Of course, this does not mean that SharePoint is not suitable for Internet usage; indeed, the opposite is true. It simply means that you need to take care to ensure proper segregation between public Internet content and private internal content. One common approach to this segregation is to create a public SharePoint farm that is responsible for displaying Internet-facing content only while also having an internal farm that is responsible for the generation and management of content. Effectively, the public farm is a read-only copy of specific elements on the internal farm. SharePoint facilitates such segregation by including a comprehensive Content Publishing API.
Web Parts and Fields
Earlier you saw how field types and page layouts are used to render web-based content in SharePoint. However,these are not the only ways to add functionality to a page. Another tool, the web part, can also be used. A web part is a user-configurable control that can be added to most pages within SharePoint. The key difference between a web part and the field types that you saw earlier is that a web part is not bound to the underlying content type of the page—that is, the web part is not used to capture or display the value of a specific field. Instead, each web part has a number of properties, and the configuration of these properties determine its behavior.
Content Query Web Part
When it comes to generating content management solutions, one of the most useful web parts is the Content Query web part. It can be used to extract specific data from various lists and libraries within a SharePoint farm and display them within a page. This functionality allows for the dynamic generation of web pages. For example, a company may require a list of the top five most popular products on a particular page. While it would be possible to create a content type and page layout to store this information and then manually update the page each day, a much better approach is to create a basic page that uses the Content Query web part to execute a query that returns the top five products and then formats the results for display on the page.
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.