IBM Computer, Laptops and Servers

... more Office SharePoint Server (MOSS) 2007 includes a Publishing Portal site definition that can be used to create new Publishing site collections. It includes all of the elements required by the MOSS Web Content Management (WCM) architecture, which consists of content types, master pages, page layouts, style sheets, images, and Web Parts, which together are used to perform various publishing tasks. It also includes a document library for holding the published pages, some default field controls, and sample content. Creating a new Publishing site typically begins by creating a new Publishing site collection based on the Publishing Portal site definition, and then carefully removing the parts not needed. This can be a tedious, error-prone, and time-consuming process. At first glance, it is not obvious which parts are extraneous and which parts are critical to the underlying WCM framework. If the wrong file is deleted, either it has to be replaced or the process has to start from scratch by creating the site collection again. What is needed is a minimal site definition that can be used as a starting point to create new Publishing site collections. This template would contain all the essential elements, excluding the extraneous sample content. That is what this chapter is all about. What are the available options for creating a minimal Publishing site definition One approach might be to create a new Publishing Portal site, remove the parts not needed, and then save it as a site template from within the SharePoint browser interface. This is the general approach to use when creating a reusable site template for other sites. Unfortunately, this approach won t work, as Publishing sites cannot be saved as site templates. In order to understand why, this chapter takes a closer look at the fundamental elements of a Publishing site to see what happens when a new Publishing site is created. During this process, the chapter develops an alternate approach that fully leverages the tools provided by Windows SharePoint Services (WSS) 3.0 for building custom sites. The custom site definition created will tap into the special extensions for provisioning new sites that is used under the covers by the Publishing framework when a Publishing Portal is created. Chapter 6: Site Columns, Content Types, and Lists At the core, all content in a SharePoint site is stored in lists. This includes things such as master pages, ... more At the core, all content in a SharePoint site is stored in lists. This includes things such as master pages, images, style sheets, XSL styles, and content pages; even page layouts (in the case of Publishing sites) are stored in SharePoint lists. Similar to tables in a database, lists are composed of columns, or fields. One of the challenges with Windows SharePoint Services (WSS) 2.0 with respect to lists was that the list templates were not very dynamic. In addition, many aspects of lists were not reusable. Such is the case when defining types of data within a list as well as the columns in lists. Microsoft addressed these issues by introducing a few new concepts. First, list columns can be defined as site columns, or templates, that can be used across multiple lists. Second, the type of data can be abstracted from a list into a new entity called a content type. Content types can then be added to a list either through the definition of the list or through the browser interface, by a site administrator. Lists can even contain multiple content types facilitating the storage of heterogeneous types of data within a single list. Finally, list templates can now be associated with sites not only at the point of site creation, but also at any time thereafter thanks to the addition of Features. This chapter covers each of these three site elements in depth, including a detailed look at the different options available to administrators and developers for creating these different elements. All three of these site elements are basic WSS 3.0 constructs found in all SharePoint sites. Regardless, Publishing site developers must have a solid grasp of these concepts in order to create professional solutions leveraging the capabilities of Microsoft Office SharePoint Server (MOSS) 2007 Web Content Management (WCM). Chapter 7: Master Pages and Page Layouts One of the biggest improvements to Windows SharePoint Services (WSS) 3.0 from the previous version of SharePoint is the... more One of the biggest improvements to Windows SharePoint Services (WSS) 3.0 from the previous version of SharePoint is the adoption and utilization of ASP.NET 2.0 master pages. In previous versions of SharePoint, the look and feel customization of a site involved editing numerous files depending upon the level of customization, that could involve hundreds of files! Thankfully, SharePoint s adoption of master pages dramatically reduces the number of files involved in customizing or branding a SharePoint site. In addition to master pages, Microsoft had to come up with an easy way for content owners to choose among different page types and renderings without developer involvement. In effect, the content owner needed the capability to pick a template and fill in the content using a familiar Web interface. To achieve this, Publishing sites leverage page layouts, which act as templates. Developers and designers create page layouts that define where the editable regions of a page are placed, as well as the overall rendering of the page. Content owners then choose from the available page layouts when creating new pages. This chapter covers the relationship of master pages and page layouts within Microsoft Office SharePoint Server (MOSS) 2007 Publishing sites. It also takes a look at a new capability in WSS 3.0 that enables developers to easily add or remove components to and from pre-defined areas within SharePoint sites. Chapter 8: Navigation Every Web site, regardless of the underlying technology used to implement it, uses some sort of navigation.... more Every Web site, regardless of the underlying technology used to implement it, uses some sort of navigation. Properly implemented navigation makes a Web site usable and the content within the site findable. SharePoint sites are no different, including Publishing sites. Thankfully, not much is unique when it comes to navigation in sites based on Windows SharePoint Services (WSS) 3.0, including Publishing sites, because SharePoint is completely dependent upon the navigation provider model included in ASP.NET 2.0. This chapter explains what the ASP.NET 2.0 navigation provider model is and how SharePoint implements it. Also covered in this chapter are the various customization options available to site owners, administrators, developers, and designers. Because SharePoint is completely dependent upon the ASP.NET 2.0 navigation provider model, this chapter does not go into great depth about creating custom navigation components. Instead, readers are encouraged to review ASP.NET 2.0 documentation on this subject. Chapter 9: Accessibility Accessibility is a popular and relevant topic as more and more companies leverage the Internet as a vehicle for their... more Accessibility is a popular and relevant topic as more and more companies leverage the Internet as a vehicle for their business. With the growing popularity of SharePoint specifically, Microsoft Office SharePoint Server (MOSS) 2007, used as both a collaboration tool and to facilitate the creation of content-centric sites accessibility is now a very important factor in evaluating SharePoint for many organizations. In the past, SharePoint has not had a great track record regarding creating accessible implementations. One challenge involved in creating accessible SharePoint sites was that it required modifying many files. In addition, some of the underlying rendering components could not be customized easily and often it was not even possible. While the latest release of SharePoint does not ship conforming to any specific standards out-of-the-box (OOTB), the new layered architecture makes it much easier to customize the rendered output. This makes it possible to create accessible solutions that meet accepted guidelines. In addition, Microsoft has teamed with one of their partners in order to provide a jump-start on creating accessible sites. The Accessibility Kit for SharePoint provides not only a significant number of components that can be reused, but also a fantastic educational opportunity to understand some different approaches to creating accessible Publishing sites. This chapter does not walk through the process of creating an accessible site each site is very different and such an exercise would turn into a discussion about HTML. Instead, the goal of this chapter is to provide insight into what it means to create an accessible site, outline how to read and understand the various guidelines, and suggest some techniques that can be leveraged in creating accessible Publishing sites. Chapter 10: Field Types and Field Controls Windows SharePoint Services (WSS) 3.0 and Office SharePoint Server (MOSS) 2007 include many common field types that can... more Windows SharePoint Services (WSS) 3.0 and Office SharePoint Server (MOSS) 2007 include many common field types that can be used in site columns, content types, and lists. This list includes types such as single line of text fields, choice fields, date/time fields and Boolean yes/no fields. Chapter 6 demonstrated that developers must learn to utilize these fields in order to deliver the required functionality in any SharePoint application. Specific to Publishing sites, these field types are used in site column definitions, which are then used within content types that define the schema for types of content pages created on the site. The Publishing Features add additional fields to SharePoint, such as the Publishing HTML field that is used to provide the rich text storage capabilities, or the Publishing Image field that stores an image with specific formatting and settings within a content page. Thankfully, the same infrastructure that Microsoft leverages when creating field types is available to developers to create custom field types when the provided field types do not satisfy the needs of a project. In addition to creating custom field types that are used to store data, developers can also create custom field controls that define the presentation of certain fields and the editing experience. This enables developers to create the most unique and user-friendly content entry experience for content owners while at the same time optionally providing additional complex validation on the field during editing. Creating custom field types and controls is a complex and complicated subject that does not have a vast amount of resources or documentation. Many aspects of this area creating both field types and field controls are not heavily documented, if at all. This chapter demonstrates how to create a custom field type that also contains a custom field control in order to define a customized editing experience, as well as adding a design-time preview of the control and customized validation upon saving data in the field type. Chapter 11: Web Parts Microsoft first introduced Web Parts in Windows SharePoint Services (WSS) 2.0. Information workers and developers quickly... more Microsoft first introduced Web Parts in Windows SharePoint Services (WSS) 2.0. Information workers and developers quickly adopted Web Parts because they enable end users to modify the content, appearance, and behavior of pages through a browser. Not only could users easily modify the content and experience with the browser, but they could also modify pages for just their own experience, rather everyone s shared experience. In addition, developers could create two Web Parts that could be connected and pass data back and forth. A common use of Web Part connections is the Microsoft SQL Server Reporting Services Web Parts. One Web Part displayed a list of the available reports while the other took the selected report from the first Web Part and displayed the rendered report. Web Parts became so popular that the ASP.NET team decided to add a Web Part Framework to ASP.NET 2.0. The ASP.NET 2.0 implementation is different from the WSS 2.0 implementation in that ASP.NET 2.0 adds a new component to the page: the WebPartManager. The WebPartManager control is responsible for managing all aspects of Web Parts on the page. It knows what Web Parts are allowed on the page, what Web Parts are already on the page and which Web Part zones they are in, any connections that have been established between two Web Parts, as well as the personalization data for each Web Part. Personalization data contains all the settings, or values, set on the public properties, for a Web Part. This is very different from the WSS 2.0 Web Part Framework in that each Web Part maintained its own connection and personalization information and Web Part zones managed which Web Parts were in each zone. With ASP.NET 2.0, adding a Web Part Framework, the SharePoint team had yet another reason why they could change SharePoint s architecture (specifically, WSS 3.0) to be built on top of ASP.NET, rather than in a side-by-side model that was glued together using an ISAPI filter, as covered in Chapter 2. However, Microsoft could not turn its back on all the Web Parts developed for WSS 2.0, so it modified the existing WebPart and associated classes in the Microsoft.SharePoint namespace to serve as a backwardly compatibility wrapper to the new ASP.NET 2.0 Web Part model. In fact, the Microsoft.SharePoint.WebPartPages.WebPart class inheritance hierarchy has completely changed to inherit directly from the ASP.NET 2.0 WebPart class, System.Web.UI.WebControls.WebParts.WebPart. Microsoft Office SharePoint Server (MOSS) 2007 includes three special Web Parts that are available exclusively to Publishing sites. These three Web Parts are covered in the section MOSS 2007 Publishing Web Parts later in the chapter. Chapter 12: Leveraging Workflow Workflow has always been an important subject in the context of enterprise applications. Unfortunately, ... more Workflow has always been an important subject in the context of enterprise applications. Unfortunately, developers have historically been mostly limited to working with large and expensive workflow systems. Applications that did not rely on these third-party workflow engines required some form of workflow engine to be devised as their own implementations. These factors combined to make the workflow development story very murky for .NET developers. Thankfully, Microsoft created the Windows Workflow Foundation (WF). Not only can WF be shared across applications, but developers can also utilize it within their own custom applications. Windows SharePoint Services (WSS) 3.0 is a prime example of this in that it added workflow to the SharePoint platform by leveraging WF. This chapter begins by explaining the concepts and motivations behind WF in general. It then moves into the SharePoint WF story and how WF is incorporated within SharePoint. Finally, the steps for creating and deploying a custom workflow for use in a SharePoint Publishing site are covered. What this chapter does not contain is an in-depth discussion about WF or creating custom workflows that can be used outside of a SharePoint environment. Additional resources are provided at the end of the Creating Custom Workflows section for readers who want more information on WF or creating custom workflows. The workflow development story within a SharePoint environment does not vary much between versions of Visual Studio (2005 vs. 2008). When appropriate, any differences between the two are described. Chapter 13: Search Search is often an afterthought in an Office SharePoint Server (MOSS) 2007 Web Content Management (WCM) project.... more Search is often an afterthought in an Office SharePoint Server (MOSS) 2007 Web Content Management (WCM) project. While the out-of-the-box (OOTB) features provided by SharePoint are a significant improvement over no search at all, understanding and planning the end user search experience will result in a search site that help users find not only what they are looking for but what site owners want them to find. The decision to add search to a site should be considered carefully. Search is not a crutch to compensate for a poorly architected site. Proper planning of the site s hierarchy is vital to the user experience. A site that is hard to navigate by browsing will inevitably be a challenge to search. Conversely, a site that is well thought out and logically structured may not even need search. Consider that implementing search badly is worse than not providing search at all. Properly implemented search is an opportunity for advertising and intelligence gathering. Think of search as a site s personal greeter, the nice person standing at the door saying, Hi! What can I help you find today Visitors to the site will enter terms in the search box for things they want from the site whether it is provided or not! On an Internet site, this may present a competitive advantage and feature ideas; on an intranet it provides site managers with insight into what employees are looking for and thinking. For example, an employee who is searching for information about medical coverage for pregnancy may be considering expanding his or her family. Because a well-planned search site helps users find what they are looking for and shows them what they should look for, this chapter dives into the issues related to implementing search as part of a WCM project, whether it is Internet facing or a corporate intranet. Chapter 14: Authoring Experience Extensibility All Web content management systems provide content authors with a user-friendly and easy way to create and manage content... more All Web content management systems provide content authors with a user-friendly and easy way to create and manage content within a Web site. The capabilities offered in Microsoft Office SharePoint Server (MOSS) 2007 Publishing sites is no different. Content authors simply need to navigate to the section of the site where they want to add content, authenticate, and create new content using the provided browser interface. What if this experience is not enough Thankfully, SharePoint does not stop there. SharePoint, Windows SharePoint Services (WSS) 3.0, at its core is very extensible. Many opportunities exist for extending and replacing the functionality provided out-of-the-box (OOTB) in SharePoint. Thanks to the architecture of SharePoint 3.0, everything that WSS 3.0 has to offer is available to MOSS 2007 and thus, Publishing sites. Previous chapters have touched on the different customization options available to developers in providing a unique experience for content owners, such as page layouts, custom field controls, custom Web Parts, and custom workflows. This chapter takes the authoring experience a bit further and discusses some additional extensibility options available to SharePoint developers to customize the authoring experience Chapter 15: Authentication and Authorization A common component to all Web applications is authentication and authorization. Authentication is the process of ensuring... more A common component to all Web applications is authentication and authorization. Authentication is the process of ensuring that users are who they say they are, usually by looking up their account with a username and password combination. Authorization is the process of checking the specific rights indicating what a user can or cannot do within the provided context. Even in anonymous Web sites, the Web server authenticates users using a special anonymous user account that has been granted specific privileges. SharePoint sites specifically, Publishing sites are no different. SharePoint relies on ASP.NET 2.0 for authentication, using the ASP.NET 2.0 authentication provider model. Internally, it handles the authorization piece with its own collection of components. This chapter covers the details of the various components applicable to SharePoint security, as well as the process of customizing the ASP.NET 2.0 authentication provider model to change the default Windows authentication that SharePoint sites use to using a custom provider such as a Microsoft SQL Server database. In addition, some Publishing-specific security and permissions aspects are covered. Chapter 16: Implementing Sites with Multiple Languages and Devices It may not seem obvious that the same chapter would discuss both multilingual sites and sites for mobile devices, ... more It may not seem obvious that the same chapter would discuss both multilingual sites and sites for mobile devices, but both of these scenarios use the same capability built into the Office SharePoint Server (MOSS) 2007 publishing system: site variations. This feature enables the management of parallel site hierarchies for Web Content Management (WCM), and movement of content among them. First the multilingual scenario is examined, which explains how this is achieved; then their application in mobile device scenarios is addressed. Chapter 17: Content Deployment Content deployment is one of the key feature areas from Microsoft Content Management Server (MCMS) 2002 that has been... more Content deployment is one of the key feature areas from Microsoft Content Management Server (MCMS) 2002 that has been brought over to and extended within Office SharePoint Server (MOSS) 2007 to enable flexible, powerful, fast, efficient, and secure deployment of Publishing sites. In a nutshell, content deployment is the copying of content from one site collection to another, either within the same SharePoint farm or across farms. The most common scenario that content deployment targets is that of enabling content authoring within the internal network (a read/write environment) and content delivery to the Internet (a read-only environment). Once configured by an administrator, content deployment can take place without any manual intervention. While the main application of content deployment is for Internet-facing sites, it is an extremely flexible feature that can also be used with intranet sites and for deploying content across site collections on a single machine running MOSS. More complex uses include a three-tier deployment topology (authoring, staging, and production). While MOSS provides a comprehensive administrative user interface for configuring, running, and monitoring content deployment, it also provides an API that enables developers to customize deployments to suit specific needs, such as deployment across disconnected environments. Content deployment also features a capability called Quick Deploy that enables content authors to deploy single pages from within the authoring environment without having to wait for the next scheduled content deployment job to run. This chapter covers the core concepts of content deployment, paths, and jobs, and how they can be combined to provide granular control over content publishing. It also describes the content deployment user interface, and includes examples and a look at the content deployment API. Finally, the Windows SharePoint Services (WSS) 3.0 content migration APIs are covered, a key infrastructure enabler for Publishing sites. Chapter 18: Offline Authoring with Document Converters When people think of Web-based content management systems, they are usually thinking of an authoring experience revolving... more When people think of Web-based content management systems, they are usually thinking of an authoring experience revolving around the browser. While this provides a very easy way for many content owners and subject matter experts to create and manage the content in a Web site, at times this approach cannot satisfy all needs. Another approach to content management is using the familiar approach of thick clients such as Microsoft Office Word. Microsoft provided this capability in Microsoft Content Management Server (MCMS) 2002, the predecessor to Office SharePoint Server (MOSS) 2007 Web Content Management (WCM), by using something called the Authoring Connector, which worked with Word 2002. Unfortunately, the MCMS Authoring Connector was not widely used because it required a client installation. Even then, after it was installed, it was not the most reliable way to author content, and the browser-based approach was still the primary recommendation for content authoring a MCMS 2002 Web site. Microsoft elected to go in a different direction with offline authoring in MOSS 2007. This new approach works with the default installation of the Office clients. The new approach enables users to upload documents authored in a thick client, such as Word 2007, and then manually trigger a conversion process. The conversion process parses the document, generating an HTML version of it, and automatically creates a new page in the configured Publishing site. This process does not circumvent any security or workflow configurations; it simply automates the process of authoring content through the Web browser. Out of the box (OOTB), MOSS 2007 ships with four document converters, enabling administrators to configure the Open XML file formats for Microsoft Office Word 2007 specifically, *.DOCX and the macro-enabled flavor, *.DOCM. InfoPath files (*.XSN) can also be used in document conversions, as can XML files with a provided extensible style sheet (XSLT). The document converter framework included in MOSS is not limited to just generating HTML content for Publishing sites utilizing the MOSS 2007 WCM capabilities. This component is a piece of the bigger Enterprise Content Management (ECM) strategy within MOSS 2007. This means developers can create document converters to transform one file type (e.g., *.XSN) to another (e.g., *.PDF). Because this book focuses on the Web Content Management aspects of MOSS 2007, this chapter covers only that section. As with many other areas in this latest version of SharePoint, the document converter framework is completely configurable and extensible. Developers are free to create their own document converters with custom administrative and user settings pages so customers can meet the business needs of individual projects. The bulk of this chapter covers the process of creating a custom document converter, complete with custom settings pages. Before creating custom document converters, however, the chapter describes the process of configuring the document converter infrastructure and using the OOTB converters. Chapter 19: Performance Tips, Tricks, and Traps Prior releases of SharePoint focused on team-based collaboration sites, corporate intranets or extranets that typically... more monebaggasse