Microsoft Office SharePoint Server 2007 (MOSS) provides a rich platform for Web Content Management (WCM) development. In... more

Microsoft Office SharePoint Server 2007 (MOSS) provides a rich platform for Web Content Management (WCM) development. In this book, you?ll learn the benefits of having the latest version of SharePoint built on ASP.NET, the features provided in Windows SharePoint Services 3.0 (WSS), and the additional functionality of Microsoft Office SharePoint Server 2007 (MOSS). You?ll learn the details of the Shared Services Provider (SSP) and Microsoft.SharePoint.Publishing namespace and see how Microsoft listened to developers to improve code reuse and how you deploy custom code in SharePoint 2007. You?ll learn how to build a SharePoint farm containing multiple servers using load-balanced Web front-end (WFE) servers. You?ll put many other SharePoint 2007 improvements to work including several list improvements to list columns, content types, and list templates. You?ll see the benefits of ASP.NET 2.0 master pages and the ASP.NET 2.0 navigation provider model for SharePoint. Accessibility remains a key SharePoint strength with the Accessibility Kit for SharePoint. And you?ll implement solutions using SharePoint Web Parts, workflow, search, and see the role of authentication and authorization in your site.

Ever since the advent of the World Wide Web in the early 1990s, there has been a focus on publishing information. Indeed, the very first Web sites were set up by scientists at CERN, the European Organization for Nuclear Research, so physicists around the world could publish information in a consistently accessible way. Since then, the Web has moved to more than publishing; this started with transactional Web sites, and led to collaboration, social networking, and aggregation-focused sites, to name a few, and all of these are addressed by Microsoft Office SharePoint Server (MOSS) 2007, if not by this book.

Even as the technology has evolved, the need for Web publishing remains pervasive. For example, transactional Web sites publish catalogs and terms of sale; collaboration and social networking sites publish usage guides and ground rules. Therefore, Web publishing remains a core function of any public, extranet or intranet Web site, even if it is more than just “brochureware.”

Take a moment to consider this book, which is the product of a modern and technically advanced publishing company. In addition to the authors, there are many other contributors to this book. Someone selected the topic as part of the publisher’s catalog and developed the title and “brand” for the book; other people designed the cover and page layout; editors checked for quality and consistency, and still other people typeset and printed the book.

Publishing a Web site is no different: People in specialized roles each want to control particular aspects of the final product. However, unlike a book, the Web site is being constantly updated, and people associated with the site want the freedom necessary to change their aspects of the site without affecting one another. For example, an author may want to add a new page, an editor may want to reorganize several pages, and a branding manager may want to change the colors and logo of all pages, all at the same time. The final “product”—a connected set of Web pages—needs to reflect the input of each of these contributors at any given point in time.

This is the problem solved by Web Content Management (WCM). A WCM system organizes the content and design from all of the site’s contributors, allows for versioning, editing, and moderation, and stitches it all together for the end user.

Consider a typical Web page. The banner, color scheme, and general look and feel are part of the branding of the site. Some sort of navigation is probably visible, revealing the organization of the site. In addition to the site navigation, there may be listings of content such as a “front page” list of articles or other topics. These are another form of navigation, one which cuts across the formal structure of the site to highlight contextually relevant content. Authored content—that is, content written by an author and possibly run through an editorial process—may appear in one or more sections of the page, along with images that may require acquisition and approval. Syndicated content, such as news feeds and advertisements, might also appear. Down at the bottom, in the fine print, there may be a legal notice or other disclaimer. Within a typical organization that has a Web site, different people will want to manage each of these aspects of the same Web page, all while the site is up and serving customers.

In the bad old days, the approach to managing a Web site was to edit Web pages and associated files on the file system of each Web server. This approach is simple enough at first, but makes it very hard to modify things such as branding, navigation, or legal disclaimers that appear repeatedly on many Web pages. Moreover, if the authored content is stored in the same files as branding, navigation, and other page features, in the course of editing a paragraph an author could accidentally modify the wrong thing and break the page entirely. This led to the role of Webmaster, a person to whom all Web site content and other changes are fed, and who knows the intricacies of HTML and CSS and any other page programming. The Webmaster’s job quickly became a tedious one—copying, pasting, and reformatting content submitted via e-mail and in documents. As the single gatekeeper for all aspects of a Web site, Webmasters often were seen as bottlenecks by contributors whose changes had to wait at the end of the queue.

As a WCM system, MOSS 2007 provides flexibility and independent control over all these aspects of a Web page. The Webmaster bottleneck is largely eliminated by giving control over the many aspects of a site directly to business users, information architects, developers, and designers. Instead of endlessly copying and pasting content, Webmasters can focus on system administration, site design, and development, enabling them to have a much greater impact than ever before.

... less

Before digging into Microsoft Office SharePoint Server 2007 (MOSS) Web Content Management (WCM) development topics, developers... more

Before digging into Microsoft Office SharePoint Server 2007 (MOSS) Web Content Management (WCM) development topics, developers must have a firm understanding of Windows SharePoint Services 3.0 (WSS). Of course, it is not possible to fully cover the subject of WSS development in a single chapter. It is a very large and far-reaching topic, as it is the foundation for everything in the SharePoint product stack. This chapter touches on some of the more important and relevant topics in WSS that are relevant to the WCM/Publishing topics covered in this book.

Note

For in-depth development and architecture coverage of Windows SharePoint Services 3.0, see Inside Microsoft Windows SharePoint Services 3.0 by Ted Pattison and Dan Larson (Microsoft Press, 2007).

... less

The previous chapter explained how core Windows SharePoint Services (WSS) concepts embrace and extend ASP.NET to provide... more

The previous chapter explained how core Windows SharePoint Services (WSS) concepts embrace and extend ASP.NET to provide the platform foundation upon which Office SharePoint Server (MOSS) solutions, including Web Content Management (WCM), are built. This chapter explores the additional functionality offered by MOSS, including aspects that are critical to a successful WCM implementation.

Before looking at MOSS itself it is worth briefly considering the Microsoft precursors to MOSS WCM, the lessons learned, which were applied to this release, the rationale for building WCM on the SharePoint platform, and the considerable opportunities offered by such rich integration.

This chapter begins by looking at the different features and editions of MOSS and then drills down into WCM-specific features. The WCM experience is demonstrated from the perspective of both the author and the end user. Also covered are the ABCs of publishing. In addition, the Shared Services Provider (SSP), a critical element of any Publishing site, is described. Finally, the chapter concludes with a brief tour of the Microsoft.SharePoint.Publishing namespace, covering the fundamental objects with examples of common uses within Publishing sites.

... less

In the second generation of SharePoint, Windows SharePoint Services (WSS) 2.0, Microsoft provided many different opportunities... more

In the second generation of SharePoint, Windows SharePoint Services (WSS) 2.0, Microsoft provided many different opportunities for developers to customize sites as well as augment sites using custom code. These various points of integration provided developers with many opportunities, but seasoned SharePoint developers became familiar with a few pain points with the second generation of SharePoint. These included issues such as promoting code reuse, incorporating new functionality or changes in existing sites, empowering site owners to add/remove this functionally without developer involvement, and deploying (as well as updating) custom code and files.

Thankfully, in the latest SharePoint release, WSS 3.0, Microsoft addresses these issues in two ways: Features and solutions. Features facilitate much more code reuse and provide developers with an easy way to not only introduce new and updated components and functionality into existing SharePoint sites, but also to empower site owners and administrators to implement it without developer involvement. The solution framework provides developers and administrators with a way to easily deploy custom code and files throughout a SharePoint implementation, including a SharePoint farm containing multiple servers such as load-balanced Web front-end (WFE) servers. This chapter explores the details of the Feature and solution frameworks, and provides some guidance on how to best create Features and WSS solution packages.

... less

Office SharePoint Server (MOSS) 2007 includes a Publishing Portal site definition that can be used to create new Publishing... 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.

... less

At the core, all content in a SharePoint site is stored in lists. This includes things such as master pages, images, style... 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).

... less

One of the biggest improvements to Windows SharePoint Services (WSS) 3.0 from the previous version of SharePoint is the adoption... 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.

... less

Every Web site, regardless of the underlying technology used to implement it, uses some sort of navigation. Properly implemented... 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.

... less

Accessibility is a popular and relevant topic as more and more companies leverage the Internet as a vehicle for their business... 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.

... less

Windows SharePoint Services (WSS) 3.0 and Office SharePoint Server (MOSS) 2007 include many common field types that can be... 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.

... less

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.

... less

Workflow has always been an important subject in the context of enterprise applications. Unfortunately, developers have historically... 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.

... less

Search is often an afterthought in an Office SharePoint Server (MOSS) 2007 Web Content Management (WCM) project. While the... 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.

... less

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

... less

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.

... less

It may not seem obvious that the same chapter would discuss both multilingual sites and sites for mobile devices, but both... 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.

... less

Content deployment is one of the key feature areas from Microsoft Content Management Server (MCMS) 2002 that has been brought... 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.

... less

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.

... less

Prior releases of SharePoint focused on team-based collaboration sites, corporate intranets or extranets that typically had... more

Prior releases of SharePoint focused on team-based collaboration sites, corporate intranets or extranets that typically had a finite audience. Even though the total potential audience for a team site or corporate intranet is not as significant as an anonymous site, performance was still an issue with SharePoint sites. The same is true in the most recent release of SharePoint in both Windows SharePoint Services (WSS) 3.0 and Office SharePoint Server (MOSS) 2007. The added capability of hosting content-centric anonymous sites on the SharePoint platform makes performance even more of an issue today.

The significant architectural change in the SharePoint foundation, i.e., being built on top of ASP.NET 2.0 rather than in a side-by-side model as in WSS 2.0, provided the most significant performance benefit to the platform. This change facilitated the removal of the ISAPI filter from Internet Information Services (IIS) that glued SharePoint together with ASP.NET 1.1 and was the cause for a significant drag on the performance of any SharePoint 2.0 site.

MOSS 2007 provides additional performance optimization opportunities above and beyond what WSS 3.0 offers out of the box (OOTB). Site administrators and developers can take advantage of ASP.NET 2.0 caching techniques to reduce the burden on SharePoint Web Front End (WFE) servers as well as SQL Servers. This chapter covers the different caching techniques, as well as ways to extend and customize them for your specific needs.

Caching is not the only issue when it comes to performance. SharePoint 3.0 is a very powerful and flexible application. One of the downsides in providing this flexible and powerful environment is that SharePoint commonly generates rather large page sizes for low-bandwidth users. Thankfully, opportunities exist to control and reduce a page’s size, or payload, for all requestors based on different conditions, such as whether they are anonymous or authenticated users. This chapter explores some of the different options available to assist in reducing the page’s payload.

Finally, most performance issues that arise are caused by poorly written custom code that has been integrated into a SharePoint site. This chapter describes a few coding techniques that all SharePoint developers, especially Publishing site developers, should be aware of when creating SharePoint sites in order to avoid common pitfalls in custom solutions.

... less

As covered in this book and many others, Windows SharePoint Services 3.0 (WSS) can be used to host not only traditional collaboration... more

As covered in this book and many others, Windows SharePoint Services 3.0 (WSS) can be used to host not only traditional collaboration sites, but also content-centric sites. However, many organizations may require some sort of functionality or custom application to be embedded within a SharePoint site. For instance, a SharePoint Publishing site may need to have a newsletter subscription and management application or an event registration system. In past versions of WSS 3.0 it was not very easy to incorporate custom applications into a site.

Thankfully, WSS 3.0 greatly expands on the number of options available to developers to build custom applications in SharePoint sites, both collaboration and Publishing sites. This chapter covers different techniques and options developers can utilize to incorporate custom ASP.NET 2.0 applications into SharePoint sites. In addition, many common questions that come up when building applications in SharePoint are covered in this chapter, such as when to store data in SharePoint lists compared to a custom database and how to customize the navigation.

While incorporating custom ASP.NET 2.0 applications into SharePoint sites is one option, another option is to use WSS 3.0 as the application development platform. In this case, the application is built on top of SharePoint, rather than being integrated into an existing collaboration or publishing site.

One thing not included in this chapter is a large number of code snippets and screenshots demonstrating the different techniques. That’s because the techniques have been covered extensively throughout other chapters in the book and repetition does not add value. Therefore, this chapter contains references to other chapters throughout the book. Similarly, this chapter does not walk through the development of a custom application, as each application is very different and has unique business requirements. Think of this chapter as more of an overview of different options and possibilities when creating custom applications in SharePoint sites.

Before reading the rest of this chapter it would be helpful to adopt a particular mindset regarding the development of SharePoint sites (if it is not already apparent). SharePoint development is unlike traditional ASP.NET 2.0 development in the sense that instead of building large applications, developers build many smaller components and integrate them into a larger solution. For example, creating a custom list or content type with advanced custom workflows and event receivers involves building many little components, rather than a single large component. The sum of the components yields a much larger and valuable component than the individual pieces.

... less