rom the end user point of view, Web Parts provide customization tools that affect the appearance and content displayed on a workspace. Web Parts empower end users to design their own user interfaces to fit a personal way of thinking, analyzing, and of getting the job done, using drag-and-drop plug-and-play components on each individual’s SharePoint workspace. These plug-and-play components display a wide variety of information in a number of formats and views.
Web Parts can be added to Web Part Zones at design time or left empty, waiting for the user to add the specific Web Parts they want to use.
One of the key concepts behind Windows SharePoint Services and Web Parts is that non-programmers can assemble the information they need and control how they want it displayed. On a single page, someone could analyze sales information, keep an eye on a stock ticker, review a calendar, and monitor a sports news feed. Some of these functions are less vital than others, but a non-programmer now has the ability to view this sort of information if they want to.
All of the customization is done at run time while the user views a live page. Changes are made when the user specifies modifications to the current page; a list of available Web Parts is displayed, a Web Part is selected, and a simple drag and drop places it in the desired location. The Web Part displays whatever content it has been programmed to display, be it sales information and sales graphs, a customer list, a stock ticker, or fantasy football results. Users drag and drop a Web Part into a specified Web Part Zone on a specific type of Web Part Page that is designed to be receptive.
The latest SharePoint products and technologies use Microsoft ASP.NET Web Part Pages to design and display SharePoint sites. How much freedom users have to use Web Parts and Web Part Pages depends on to which security group (or groups) the user is assigned and the rights assigned to each group.
From a developer’s point of view, a Web Part is just a collection of ASP.NET server controls. The primary difference between a standard ASP.NET control and a Web Part is that standard ASP.NET controls are added to ASP.NET pages at design time by developers, and a Web Part is added to a Web Part Zone on a Web Part Page at run time by users. XML files that reference a Web Part’s namespace, class name, assembly, and additional optional property settings are called .dwp files.
One thing you might have noticed is that Web Parts don’t fit the mold of traditional programming with a definite demarcation between design time and run time. Run time demands a new role for users: real-time page design and creation. This simplifies Web design because the focus can be on page design and layout, done in Microsoft Office FrontPage 2003 or Microsoft Visual Studio.NET.
Adding a Web Part to a SharePoint Server Portal 2003 Page
In order to add and change Web Parts on a shared-view SharePoint site, you must be granted the Add and Customize Pages rights for the site. As a member of the Web Designer and Administrator site groups, you will be granted this right by default. In order to add and change Web Parts on a personal view of a SharePoint site, you must be granted the Add/Remove Private Web Parts right and the Update Personal Web Parts right. In addition to being granted to the Web Designer and Administrator site groups by default, these rights are also granted to the members of the Contributor group.
|Designing Web Parts with Visual Studio.NET
You can use Visual Studio .NET to build Web Part assemblies for use in SharePoint products and technologies. There are two options for building your Web Parts in Visual Studio: you can use the standard (provided) template for building a Web Control gallery, or you can use a special template and build a Web Part gallery. The Web Part gallery templates are not included with Visual Studio .NET, but you can download them from Microsoft at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnspts/html/sharepoint_webparttemplates.asp.
The templates are provided to help you create Web Parts and are very similar to the default server control file and project templates included with Visual Studio .NET. These templates are available for both Visual Basic .NET and C#. You choose the language you want when you run the template’s setup program (see Figure 6). Another piece of information you need to supply while installing the templates is the location of the Microsoft.SharePoint.dll file (see Figure 7). On a computer running Windows SharePoint Services, the DLL is stored in local_drive:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions60ISAPI.
Creating a project from the Web Part gallery templates offers advantages and features over using the standard Web Control gallery template, including:
You will find the process of creating a Web Part very familiar if you have ever created an ASP.NET custom control. All the techniques for building an ASP.NET custom control also apply to building a Web Part custom control. The primary difference is that with a Web Part, you inherit from the WebPart class instead of from a WebControl class. You also need to override the RenderWebPart method instead of overriding the RenderContents method.
Additional information regarding developing Web Parts for SharePoint products and technologies is available in the SharePoint Products and Technologies Software Development Kit (SDK) available from MSDN (http://msdn.microsoft.com/sharepoint), and there are additional resources listed in the Related Resources section of this article.
Developing Web Parts is definitely not your grandfather’s programming. Web Parts mean new opportunities, new horizons, and new challenges for developers providing a revolutionary capability for end users to customize their workspaces.
As always, I’m interested to hear your feedback about the material covered here.