WSS as a Development Platform

In one sense, WSS works against professional software developers because it empowers users to create and customize their own sites. In minutes, a user can create a WSS site, add several lists and document libraries, and customize the site’s appearance to meet the needs of a particular business situation. An identical solution created using ASP.NET would likely take a developer weeks or months to complete.

In another sense, WSS provides professional developers with new and exciting development opportunities. As with any other framework, the out-of-the-box experience with WSS will only take you so far. At some point, you will find yourself needing to create custom list types and write code for custom WSS components such as Web Parts, event handlers, and workflows. What’s incredibly attractive about WSS as a development platform is that it was designed from the ground up with developer extensibility in mind. The WSS developer platform includes the object model, Web Part framework, Web services, and site provisioning model, providing a comprehensive framework for scalable portal applications.

Customization Versus Development

As you begin to design software for the WSS platform, it is critical that you differentiate between customization and development. WSS is very flexible for users because it was designed to support high levels of customization. As we have pointed out, you no longer need to be a developer to build a complex and highly functional site.

A sophisticated user can create and customize lists and document libraries. Users can also customize and personalize the appearance of their pages through the use of Web Parts. Advanced users can even provide an effective branding solution by using the SharePoint Designer to customize the master pages and Cascading Styles Sheets associated with sites.

You should remember that WSS records every site customization by modifying data within the content database. This is true whenever you create a new list or whenever you customize an existing list by adding new columns and views. It’s also true for all types of site customization you can perform using Microsoft Office SharePoint Designer.

The fact that all site customization is recorded as modifications to the content database is both a strength and a weakness for WSS. It is a strength because it provides so much flexibility to users and site administrators with respect to performing ad hoc customization. It is a weakness for professional software development because customization changes are hard to version and to make repeatable across multiple sites.

Think about a standard ASP.NET development project where all the source files you are working with live within a single directory on your development machine. Once you have finished the site’s initial design and implementation, you can add all the site’s source files to a source control management system such as Microsoft Visual SourceSafe. This makes it possible to have a very disciplined approach to deploying and updating the site after it has gone into production. You can also elect to push changes out to a staging environment where your site’s pages and code can be thoroughly tested before they are finally pushed out to the production environment.

As a developer, you should ask yourself the following questions: How do you conduct source control management of customization changes? How do you make a customization change to a list definition or a page instance and then move this change from a development environment to a staging environment and finally to a production environment? How do you make a customization change within a site and then reuse it across a hundred different sites? Unfortunately, these questions have very tough answers, and usually you will find that a possible solution isn’t worth the trouble.

Fortunately, as a developer you can work at a level underneath the WSS customization infrastructure. To be more specific, you can work with the low-level source files to create underlying definitions for things like lists and page templates. These low-level source files do not live inside the content database, but instead they live within the file system of the front-end Web server. Working at this level is more complex and has a steeper learning curve. However, it lets you centralize source code management and have a more disciplined approach involving code sign-off when moving pages and code from development to staging to production. This approach also makes versioning and reuse of code far more manageable across multiple sites, Web applications, and farms.

For the remainder of this book, we will differentiate between customization and development according to these criteria. WSS customizations are updates to a site accomplished by making changes to the content database, generally through the Web browser or the SharePoint Designer. A site customization never requires touching the front-end Web server. WSS development, on the other hand, involves working with files that must be deployed to the file system of the front-end Web server. WSS development includes creating page templates and list definitions, as well as creating components deployed in compiled assemblies such as custom Web Parts, event handlers, and workflow templates. WSS development at this level is also referred to as developing provisioning components.

Keep in mind that development requires a degree of control over the front-end Web server because of the need to push out files such as page templates and assemblies. If you work in a WSS environment where you are not permitted to make any changes to front-end Web servers, you will not be able to deploy any of your development efforts. In such an environment, you will be restricted to using only customization techniques that can be accomplished by making changes to the content database.

Although customization provides users with a great deal of flexibility, development is far more powerful. It’s a much better approach for creating reusable WSS solutions, as well as the best way to optimize the response times and throughput for high-traffic sites. Developing provisioning components with WSS is the primary focus of this book, whereas discussions of customization and related tools such as the SharePoint Designer will be secondary.

Development Opportunities

As a developer, you have many different avenues for extending WSS. Over the next two chapters, we will discuss how you can create custom application pages and page templates to add functionality to a business solution. As you will see, some types of pages in a WSS site allow you to write managed code directly behind them; other types do not. However, even with the types of pages that do not directly support code, you still have the ability to write code in Web Parts and ASP.NET User Controls and then to use these components in your pages.

Enhancements to WSS 3.0 have added rich integration with ASP.NET master pages and Cascading Style Sheets (CSS). This provides a good deal of control when you need to brand a site that will be seen by customers or top-level management. There’s also tight integration with the ASP.NET navigation provider framework that makes it possible to create any type of custom navigation structure that you can create for a standard ASP.NET 2.0 application.

You can also develop many types of custom components for use within WSS sites. These components include standard ASP.NET server controls, Web Parts, event handlers, custom field types, and custom policies. The why and how of developing these types of components will be discussed throughout the course of this book.

As a developer, you also have control over how you store content within a custom site. WSS lets you define custom types for lists and document libraries, giving you control over which columns they contain and which views are available to users.

WSS 3.0 has added a valuable new innovation known as the site column. A site column is a reusable column definition that can be used across multiple lists. A site column defines the name for a column, its underlying field type, and other characteristics such as the default value, formatting, and validation. Once you have defined a site column, you can then use it as you define the schema for custom lists and document libraries. An obvious advantage is that you can update the site column in a single place and have that update affect all the lists where the site column has been used.

WSS 3.0 adds a second powerful innovation focused on content storage. It is known as a content type. A content type is a flexible and reusable WSS type definition that defines the columns and behavior for an item in a list or a document in a document library. For example, you can create a content type for a customer presentation document with a unique set of columns, an event handler, and its own document template. You can create a second content type for a customer proposal document with a different set of columns, a workflow, and a different document template. Then you can create a new document library and configure it to support both of these content types. The introduction of content types is very significant to WSS 3.0 because it provides an ability that did not exist in WSS 2.0 to deal with heterogeneous types of content in lists and document libraries.

Another great new development opportunity is to work with the new Office Open XML file formats. This new technology introduced with Microsoft Office 2007 provides you with the ability to generate and/or manipulate Microsoft Office Word documents and Microsoft Office Excel documents from server-side code within custom components such as event handlers and workflows. What’s nice is that the Office Open XML file formats eliminate the need to install and run a version of a Microsoft Office desktop application such as Office Word or Office Excel on the server. Everything can be done by programming against server-side libraries, which provide high degrees of scalability and robustness.

One of the most exciting areas of extending WSS 3.0 is in the area of workflow. WSS is built on top of Microsoft’s new Windows Workflow Foundation that is part of the .NET Framework 3.0. WSS adds an extra dimension on top of the Windows Workflow Foundation to provide a foundation for attaching business logic to list items and documents in a WSS site. WSS extends the basic model of the Windows Workflow Foundation by associating a task list and a history list with each workflow. This adds a degree of responsibility and accountability to workflows that are human-oriented in nature, such as a workflow for reviewing or approving a document.

Both WSS and MOSS ship with workflows that are installed and ready to use. WSS includes a simple routing workflow for things such as moderation and approval. MOSS supplies workflows that are more complex and are used to support features such as their Web Content Management approval process.

The creation of custom workflows represents an obvious extensibility point for developers creating business solutions with WSS and with MOSS. In addition to the standard support of the Visual Studio Extensions for the Windows Workflow Foundation, the Office team provides a WSS-specific workflow Software Development Kit (SDK) and a workflow starter kit including Visual Studio project templates for creating custom workflows targeted at WSS sites.

Security and site membership are two other areas that provide developers with opportunities for extending the standard WSS infrastructure. Previous versions of WSS were tightly coupled to Windows accounts and Microsoft Active Directory, making SharePoint technologies undesirable for Internet-facing sites. This is no longer the case with WSS 3.0. The new infrastructure for user authentication has been redesigned to sit on top of the authentication provider infrastructure introduced in ASP.NET 2.0.

If you don’t want to maintain user accounts for WSS users inside Active Directory, you simply need to build or acquire an ASP.NET authentication provider that’s been designed to store and manage user accounts in an alternative identity repository such as a SQL Server database. This architectural enhancement has led WSS 3.0 to gain much wider adoption as a platform for building Internet-facing sites.

For example, ASP.NET 2.0 ships with the forms authentication provider that allows you to maintain user accounts inside a SQL Server database. This authentication provider can be configured for use in a WSS 3.0 site. With little effort on your part, you can put a WSS site on the Internet that allows unknown users to register themselves as members. ASP.NET 2.0 provides you with convenient support for creating and maintaining user accounts, and even allows users to change and reset their passwords. When you use forms authentication, you can use the same programming techniques to manage user accounts in a WSS solution as you would in an ASP.NET 2.0 solution.

Introduction to Features

Though there are many different avenues for custom development in WSS, you should start off by learning about features. Features are a new developer-focused innovation that has been added to WSS 3.0. Features provide a mechanism for defining site elements and adding them to a target site or site collection through a process known as feature activation. The element types that can be defined by a feature include menu commands, link commands, page templates, page instances, list definitions, list instances, event handlers, and workflows.

At a physical level, a feature consists of a directory created within a special WSS system directory located within the file system of each front-end Web server. The directory for a feature contains one or more XML-based files that contain Collaborative Application Markup Language (CAML). By convention, each feature directory contains a manifest file named feature.xml that defines the high-level attributes of the feature, such as its ID and its user-friendly Title.

Besides the feature.xml file, a feature usually contains one or more additional XML files (for example, elements.xml) that define the actual elements that make up the feature. The directory for a feature can also contain several other types of files for things like list definitions and page templates, as well as other kinds of resources such as graphics files, Cascading Style Sheets, and JavaScript files.

One valuable technique for getting up to speed on features is to examine the standard set of features that ships as part of the basic WSS installation. An example of what the FEATURES directory looks like after you have installed WSS is shown in Figure 1-11. As you can see, each feature has its own directory. Also note that the Site Features page will look very different if you have installed MOSS because there will be more than 100 features.

image from book
Figure 1-11: Many stock aspects of WSS, such as collaboration lists, are implemented as features.

At the end of this chapter, you will see how to create and deploy your first custom feature. Once you have created a feature, you then must install it with WSS at a farm-level scope. Once a feature has been installed with WSS, it can then be activated within the context of a site or a site collection using an administrative page accessible through the Site Settings page.

Throughout this book, we will continually introduce new features to solve a particular problem such as branding a site with a custom master page and Cascading Style Sheet. Other features will demonstrate how to provision new page instances and how to make components such as Web Parts and custom workflows accessible within a site.

While a custom feature allows a developer to define one or more elements that can be activated inside the context of a site or site collection, WSS also provides a developer with the ability to define the entire blueprint for a site by creating a custom site definition. The development of custom site definitions allows a developer to take control over every aspect of a new site such as its branding, its initial set of lists, and which features it uses. Chapter 9, “Solutions and Deployment,” is dedicated to working with site definitions.

Programming Against the WSS Object Model

Another important aspect of WSS development is programming against the WSS object model. The core types provided by the WSS programming model are exposed through a standard WSS assembly named Microsoft.SharePoint.dll.

Let’s look at a simple example. Imagine you have just created a console application, and you have added a reference to Microsoft.SharePoint.dll. The WSS object model exposes an SPSite class that serves as an entry point into the WSS object model at the site collection level. Each site within a site collection is represented as an SPWeb object. Each list within a site is represented as an SPList object. Here’s a simple example using the WSS object model to access the top-level site within a target site collection and discover all its lists.

  using Microsoft.SharePoint; namespace Hello_WSS_OM {   class Program {     static void Main() {       string sitePath = "";       // enter object model through site collection.       SPSite siteCollection = new SPSite(sitePath);       // obtain reference to top-level site.       SPWeb site = siteCollection.RootWeb;       // enumerate through lists of site       foreach (SPList list in site.Lists) {         Console.WriteLine(list.Title);       }       // clean up by calling Dispose.       site.Dispose();       siteCollection.Dispose();     }   } } 

You should observe the two calls to the Dispose method at the end of this code example. Several object types in the WSS object model, such as SPSite and SPWeb, use unmanaged resources and must be disposed of in a timely manner. If you fail to do this and simply rely on the garbage collector of the .NET Framework to reclaim memory, your code can cause problems by consuming far more memory than it needs. As a rule of thumb, when you create a disposable object, you are also responsible for calling Dispose on it. However, object references obtained through the WSS Web application’s SPContext should not be disposed.

Inside Microsoft Windows Sharepoint Services Version 3
Inside Microsoft Windows Sharepoint Services Version 3
ISBN: 735623201
Year: 2007
Pages: 92 © 2008-2017.
If you may any questions please contact us: