16.01.2013 Views

Microsoft Sharepoint Products and Technologies Resource Kit eBook

Microsoft Sharepoint Products and Technologies Resource Kit eBook

Microsoft Sharepoint Products and Technologies Resource Kit eBook

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

1122 Part XI: Upgrading <strong>and</strong> Migrating to SharePoint <strong>Products</strong> <strong>and</strong> <strong>Technologies</strong><br />

Custom Web Parts must derive from the <strong>Microsoft</strong>.SharePoint.WebPartPages.WebPart<br />

base class. For more information about how to create a Web Part, see Part 10,<br />

“<strong>Microsoft</strong> Office 2003 Integration with SharePoint <strong>Products</strong> <strong>and</strong> <strong>Technologies</strong>” <strong>and</strong><br />

the SharePoint <strong>Products</strong> <strong>and</strong> <strong>Technologies</strong> SDK. You can write custom Web Parts for<br />

any of the following purposes:<br />

■ Creating custom properties <strong>and</strong> using the Web Part infrastructure to display<br />

them in the tool pane.<br />

■ Creating custom Tool Parts in the tool pane.<br />

■ Creating a base class for other Web Parts to extend. For example, to create a<br />

collection of Web Parts with similar features <strong>and</strong> functionality, create a custom<br />

base class from which multiple Web Parts can inherit. This reduces the overall<br />

cost of developing <strong>and</strong> testing subsequent Web Parts.<br />

■ Improving performance <strong>and</strong> scalability. A compiled custom Web Part runs<br />

faster than a script.<br />

■ Securing <strong>and</strong> controlling access to content within the Web Part. The built-in<br />

Web Parts allow any users with appropriate permissions to change content <strong>and</strong><br />

alter Web Part functionality. With a custom Web Part, you can determine the<br />

content or properties to display to users, regardless of their permissions.<br />

■ Making your Web Part connectable by implementing one or more of the<br />

defined Web Part Connection interfaces. This allows the custom Web Part to<br />

provide or access data from other connectable Web Parts.<br />

■ Interacting with the object models that are exposed in SharePoint <strong>Products</strong> <strong>and</strong><br />

<strong>Technologies</strong>. For example, you can create a custom Web Part to save documents<br />

to a Windows SharePoint Services document library.<br />

■ Controlling the cache for the Web Part by using built-in cache tools. For example,<br />

you can use these tools to specify when to read, write, or invalidate the<br />

Web Part cache.<br />

■ Benefiting from a rich development environment with debugging features that<br />

are provided by tools such as Visual Studio .NET.<br />

■ Implementing proprietary code without disclosing the source code.<br />

■ Controlling the implementation of the Web Part. For example, you can write a<br />

custom server-side Web Part that connects to a back-end database, or you can<br />

create a Web Part that is compatible with a broader range of Web browsers.<br />

To successfully convert your dashboard Web Parts to the Web Part infrastructure,<br />

you must underst<strong>and</strong> the changes to properties, namespace, resource h<strong>and</strong>ling,<br />

tokens, DDSC, <strong>and</strong> .dwp files that are described in the white paper “Converting<br />

Dashboard Web Parts to the Web Part Infrastructure for <strong>Microsoft</strong> SharePoint <strong>Products</strong><br />

<strong>and</strong> <strong>Technologies</strong>,” mentioned earlier in this chapter, <strong>and</strong> the SDKs.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!