Matthew McDermott

Designing Mashups with Excel and Visio

Business Intelligence and reporting have been two of the most important functions of data management systems over the last several decades, and as technology changes, the means for reporting and creating dashboards has evolved to meet the changing needs and capabilities in the market. In today’s world, the availability of services such as geographic mapping and social networking on a global scale has led to the redefining of how information is organized and portrayed on the Web. In many cases, dashboards now need to provide a high level of relevance, far beyond a simple tabular report or even charts, and the information expressed should be cohesive and dynamic, allowing the user to incorporate the data they need with external systems that complete a picture for them. This new dashboard for the Web is known as a mashup, and in SharePoint 2010, Microsoft has provided a framework for completing their services that they refer to as Composites. With tools such as Visio, Excel, and PerformancePoint Services, SharePoint has a full feature set for reporting. This chapter will address some aspects of how to extend the out-of-the-box experience from Visio and Excel to quickly create a mashup.

Leveraging Content Types

“A better place to put our content” is the most common and fundamental reason that organizations give when implementing SharePoint. For all of SharePoint’s rich capabilities, a SharePoint solution is of very little value without good content. An event in a calendar, a policy document in a library, a news article in a pages library—these are all first and foremost content, and they are each defined and managed within SharePoint using content types. This chapter explores the importance of content types and the role of managed metadata to ensure that SharePoint can become that “better place”—not just a glorified file system and content dumping ground.

SharePoint Solution Deployment

This chapter will focus on best practices for deploying your SharePoint 2010 customizations developed with Visual Studio 2010 SharePoint 2010 tools. This chapter does not provide an introduction to the Visual Studio 2010 SharePoint 2010 tools that automate much of the work to create features and solutions (WSP files). It is assumed you already know what SharePoint features and solutions are, and that you have a good hands-on working knowledge of how to create these in Visual Studio 2010. Rather, this chapter will demonstrate some best practices that will encourage you to carefully plan out the structure of your Visual Studio solutions, SharePoint features, and SharePoint solutions. Here are some of the best practices that will be covered in this chapter: 1. Think deployment first! Plan your Visual Studio Solution, SharePoint solution, and SharePoint feature strategy carefully. 2. Plan to maintain your application with feature versioning and feature upgrading. 3. Define your feature and solution activation dependencies. 4. Automate the provisioning of your solutions and features with PowerShell. 5. Defined lists should be backed with schema defined in content types. 6. Sign all of your Visual Studio projects with the same Strong Name Key (SNK) file 7. Feature Stapling is a great way to enhance out of the box site definitions.

Claims-Based Authentication in SharePoint 2010

This chapter is indented to give the reader an overview of the new claims-based authentication method available in SharePoint 2010. The claims world beyond SharePoint is large and varied. This chapter will not teach you everything there is to know about dealing with claims in SharePoint. This chapter will discuss when to use claims authentication, some of the most common steps to implementing it, and how to avoid some of the common pitfalls with working with claims. While not every possible scenario is covered, it should serve as a good foundation to help you avoid some of the common pitfalls.

Extending SharePoint Using Event Receivers

This chapter covers techniques to extend SharePoint 2010 functionality using event receivers. It starts with a discussion of common business scenarios for event receivers. It also describes situations where you may want to avoid using event receivers. You will then learn the core architecture of event receivers, their types, and categories. Various approaches to develop, deploy and register event receivers are covered with hands-on exercises. Later parts of chapter covers areas like common issues with event receivers and how to avoid them. Throughout the chapter best practices are highlighted while working with custom event receivers.

Public-Facing SharePoint Sites

These are questions I get all the time in the field, usually coming from customers who have already had some level of exposure to SharePoint. Organizations have been adopting SharePoint and it’s been spreading throughout their business areas, gaining a lot of traction with users. People like what it is doing for them, so the progression to looking at it for public-facing web content is a fairly natural one.

SharePoint and Windows Phone 7 Development

The introduction of the Windows Phone 7 mobile platform is a significant step forward from the more business-focused Windows Mobile 6.5 platform. Windows Phone 7 is a consumer-focused, marketplace-driven environment where the specifications, design, and capabilities are tightly controlled by Microsoft. Microsoft’s goal for Windows Phone 7 is to enable developers to create applications using tools common to the rest of the .NET platform like Visual Studio 2010, Silverlight, and XNA.

Practical Document Management with SharePoint 2010

SharePoint has grown to be unanimously acclaimed as the best collaboration platform on the planet. The latest iteration from Microsoft, SharePoint 2010, has seen the fastest adoption rate of any version due to the rich feature set and agile ribbon-based user interface (UI).

The SharePoint 2010 Client Object Model

In previous versions of SharePoint, developers accessed content and performed operations via server side code called Server Object Model and/or used SharePoint Web Services. Now Microsoft has introduced a new way for developers to communicate with SharePoint Foundation 2010; this third way of writing code is known as Client Object Model. (SharePoint Server Object Model and SharePoint Web Services are still options). The Client Object Model (Client OM) API can be used in .NET based applications, Silverlight applications, and in ECMAScript (JavaScript) that executes in the browser. Although the Client OM API is not as rich as the Server Object Model, it has its own benefits, such as an object-oriented way of accessing SharePoint content without the complexities of Server Object Model and SharePoint Web Services, no packaging and deployment hassles, easy access to content stored in SharePoint list/libraries, quick and easy scripting, etc.

Bridging the Office-SharePoint Gap

In previous versions of SharePoint and Office there was always a clear divide between client- and server-based capabilities. Although Microsoft introduced the term “Microsoft Office System” in 2007,the true integration has been a challenge. Even today, when using the 2010 wave of the product cycle, I’d argue that true integration works in some scenarios but leaves a lot to be desired in many others. However, the landscape is changing and the role of the client environment and operating system is slowly changing to a model where users canuse many different devices on a common server or even a cloud-based set of services and data. To support that model, Microsoft has made sure users can use server- or browser-based versions of the popular client applications such as Word, OneNote, PowerPoint, Excel, and Outlook Web Access.