Export (0) Print
Expand All
Expand Minimize
20 out of 26 rated this helpful - Rate this topic

Checklist for Creating SharePoint Web Parts

Windows SharePoint Services 3

Summary: Use this checklist to assist with the deployment and maintenance of Microsoft SharePoint Products and Technologies Web Parts. (12 printed pages)

Dallas Tester, Microsoft Corporation

Lana Fly, Microsoft Corporation

Susan Harney, Microsoft Corporation

January 2008

Applies to: Windows SharePoint Services 3.0, Microsoft Office SharePoint Server 2007

Contents

Overview

If you install and maintain the Web Parts for your Microsoft Office SharePoint Server 2007 Web site or Windows SharePoint Services team site, you should help ensure that the Web Parts are secure, coded well, and can integrate appropriately with other components on the Web Part page.

By understanding the tasks we describe in this article, you can determine whether a Web Part meets these requirements, and help enhance the success of your Web Part deployment and maintenance.

Note   For more information about authoring Web Parts, see Working with ASP.NET 2.0 Web Parts and Windows SharePoint Services 3.0

Task Checklist for Testing Web Parts

The following checklist contains a series of tasks designed to help you determine the quality of Web Parts you are asked to deploy or maintain.

For details about how to perform these verifications, click each link in the checklist.

Task Checklist

Verifying Web Part Rendering

Use the following procedures as guidelines to verify that your Web Parts render correctly in various views.

Verify that Web Part Renders Appropriately Based On User Permissions

Because a Web Part is managed by the user at run time, the Web Part should render with a user interface (UI) that is appropriate for each user's permissions.

To test

  1. Test with different user accounts that have only Reader or Contributor rights.

  2. Make sure that the UI is suppressed if the end user does not have permissions to perform a certain action. (For example, if a Web Part displays a Save button, it should be disabled or hidden if the user does not have permissions to perform that action.)

  3. Turn on anonymous access for the site and browse a Web Part page that has your Web Part, but make sure the sign-in button is still visible on the page. (When the sign-in button is displayed on the page, the user has not yet been authenticated.)

Verify that Static Web Part Renders Appropriately and Does Not Cause Web Part Page to Fail

Web Parts that are placed outside of a Web Part zone, which are called static Web Parts, are contained in .aspx pages but not in a Web Part zone. Because the static Web Part is a Web form control, ASP.NET renders the Web Part. You cannot save changes to static Web Parts in either shared or personal view.

To test

  1. Open SharePoint Designer 2007.

  2. Open a SharePoint site.

  3. On the File menu, select New, select Page, and choose ASPX in the General category.

  4. In Design view, on the Insert menu, point to SharePoint Controls, and then click Web Part.

  5. From the Web Parts toolbox, drag a Web Part onto the page.

  6. Save the page.

  7. View the page in the browser.

    Bb985502.note(en-us,office.12).gifNote:

    Make sure that your Web Part is within the <form runat="server"> tags.

  8. Verify that the part renders correctly (for example, you should not be able to save changes in a static Web Part).

Verify that Web Part Appears Appropriately in Search Results

Because Web Parts galleries can contain numerous custom Web Parts, the search capability helps users quickly find the Web Parts they want.

The Web Part infrastructure uses the Title and Description properties of the Web Part to build the search result set, so when you add comprehensive information in these fields your Web Parts will be easily searchable.

To test

  1. Add the Web part to the Site Web Part Gallery by navigating to Site Settings, click Web Parts under the Galleries heading, and then click New on the toolbar.

  2. Choose the Web Part that you are testing, and then click Populate Gallery.

  3. Browse to the Web Part page and choose Edit Page from the Site Actions menu.

  4. Click Add a Web Part in a Web Part zone.

  5. In the dialog, choose Advanced Web Part gallery and options.

  6. In the Add a Web Part pane, choose Search in the Web Part chrome drop-down menu.

  7. Enter the appropriate search text and click Go. The Web Part should appear as one of the top choices.

Verify that Web Part Previews Properly

It is important to create previews for Web Parts so that administrators are able to review the parts included in the Web Part gallery.

To test

  1. Go to Site Settings, click Web Parts under the Galleries heading, and click the Web Part in the list.

  2. Verify that there are no script errors.

  3. Verify that the preview appears correctly.

Verifying Web Part Functionality

Use the following procedures to verify that your Web Part functions properly in typical situations.

Verify that Web Part Can Be Added to Web Part Zone

Adding a Web Part to a Web Part zone is the most common user task. Therefore, it is essential that the Web Part works correctly to create a good user experience.

To test

  1. Create a new Web Part page.

  2. Click Site Actions, click Edit Page.

  3. In the zone where you want the Web Part to appear, click Add a Web Part.

  4. In the dialog, choose Advanced Web Part gallery and options.

  5. In the Add a Web Part pane, choose Import in the Web Part chrome drop-down menu.

  6. Import the .dwp file for your Web Part.

  7. Add the Web Part to a Web Part zone.

Verify that Web Part Works Correctly Regardless of Web Part Page Location

You can add Web Parts to Web Part pages that are contained in a document library as well as Web Part pages that are contained in the top-level Web site. They should work correctly in either location.

To test

  1. Create a Web Part page in a document library.

  2. Browse to the portal site.

  3. On the Site Actions menu, click Create.

  4. On the Create page, click Web Part Page.

  5. In the New Web Part Page creation form, Save Location lists the document libraries in which the Web Part can be saved. Select a document library, type a Name for the page, and then click Create.

  6. Import your Web Part from the gallery.

  7. Next, create a Web Part page in the top-level Web site.

  8. Open a SharePoint site in SharePoint Designer 2007.

  9. On the File menu, select New, select Page, and choose ASPX in the General category.

  10. In Design view, on the Insert menu, point to SharePoint Controls, and click Web Part.

  11. From the Web Parts toolbox, drag a Web Part onto the page.

  12. Save the ASPX file in the top-level Web site, for example, at the same location where the default.aspx is located.

Verify that Web Part Caching Works Correctly

For any operation that works with a large amount of data, use a Web Part cache to store property values and to expedite data retrieval.

Web Part authors can choose to cache data in several ways, but ultimately the farm administrator decides the type of caching that a Web Part uses.

Following are three available cache settings:

  • CacheObject — uses the ASP.NET Cache object (the default).

  • Database — uses the content database (and requires all objects to be serialized).

  • None — disables caching.

To test your Web Part caching, set the type of cache using the value of the WebPartCache element in the web.config file.

To test

  1. In the web.config file, change the <WebPartCache Storage="CacheObject"> statement to <WebPartCache Storage="Database"> and make sure that the Web Part still works correctly.

  2. Next, change the same statement to <WebPartCache Storage="None"> and then make sure that the Web Part still works correctly.

    Bb985502.note(en-us,office.12).gifNote:

    By default, exceptions related to caching are not displayed by the Web Part infrastructure. For debugging purposes only, you can make the following changes (steps 3 and 4 below) to your web.config file.

  3. In the <system.web> tag, locate the <customErrors mode="On"> tag and change it to <customErrors mode="Off"> to see the ASP.NET exception when an error occurs instead of being redirected to the error page.

  4. In the <SharePoint> tag, locate the <SafeMode MaxControls="50" CallStack="false"/> tag and change it to <SafeMode MaxControls="50" CallStack="true"/>. This causes ASP.NET error messages to display with stack trace information.

Verify that Changes Made in Personal View Are Not Reflected in Shared View

Changes that are made in shared view are seen by all users. Changes that are made in personal view should be seen only by the person who made them.

To test

  1. Add the Web Part in shared view.

  2. Edit the properties in shared view.

  3. Change to personal view.

  4. Edit the property in personal view.

  5. Change back to shared view, and then make sure that the Web Part does not display any of the values that were changed in personal view.

Verify that Web Part Can Handle Asynchronous Calls to Other HTTP Sites and Web Services

For performance reasons, you should use asynchronous threads for any operation that works with a large amount of data.

To test

  1. Confirm that any calls to Web services or other HTTP sites are asynchronous.

  2. Test your Web Part on the page to be sure that it handles asynchronous calls as you expect.

Verify that Web Part Works Correctly With Different Combinations of Zone Settings

Web Part zones have properties that control whether a user can save changes. If a user attempts to save changes to a Web Part without the correct permissions, a broken page can result.

The following Web Part zone properties affect Web Parts in the zone:

  • AllowCustomization—If false, and a user is viewing the page in shared view, the Web Part cannot save any changes to the database.

  • AllowPersonalization—If false, and a user is viewing the page in personal view, the Web Part cannot persist any changes to the database.

  • LockLayout—If true, changes to the AllowRemove, AllowZoneChange, Height, IsIncluded, IsVisible, PartOrder, Width, and ZoneID properties are not persisted to the database regardless of view.

To test

  1. Create a page in the browser, and then add your Web Part into several zones, both in shared and personal views.

  2. Open SharePoint Designer 2007.

  3. Open a Web Part page on a SharePoint site and, in Design view, double-click a Web Part zone (or right-click over a Web Part zone, and then, on the shortcut menu, click Web Part Zone Properties), and then change the zone properties. Alternatively, you can switch to Code view and type in the attributes for the Web Part zone control.

  4. View the page in the browser.

  5. Verify that the part does not break the page and that the Web part functions correctly.

  6. Verify that any UI displayed in the Web Part indicates to the user that changes cannot be persisted or that that the UI is disabled as appropriate for the zone settings.

Verify that Web Part Can Access Resources in Different Setup Configurations

Web Part resources cannot be part of the DLL because they must be URL-accessible. Examples of these resources are images, .js files, or .aspx pages.

Bb985502.note(en-us,office.12).gifNote:

Because a Web Part assembly can be installed in either the bin directory (%SystemDrive%\Inetpub\wwwroot\wss\VirtualDirectories\%port%\bin), or the global assembly cache, you must go through each of these steps with the Web Part installed in the bin and again with the Web Part installed in the global assembly cache.

Add the Web Part to your page in all the following scenarios and make sure that it can correctly access its resources.

To test

  1. Add the Web Part to the top-level Web site.

  2. Add the Web Part to a subsite with unique permissions, in which only a user has rights in the subsite.

  3. Add the Web Part to a Web Part page inside a folder in a document library.

  4. Add a Web Part to a site with Self-Service Site Creation enabled on the Web application.

  5. Add a Web Part to a site with Host Header mode enabled.

  6. Add the Web Part to a site where the top-level Web site is not a SharePoint site, for example, http://servername/customURL.

  7. Add to the Web Part to Web Part pages that are in different subsite languages.

Verify that Web Part Can Be Imported and Exported Correctly

By default, whenever you export a Web Part, each Web Part property is included in the .dwp file. However, because properties can contain sensitive information, for example, a date of birth, you can identify a property as controlled, allowing you or the user to exclude the value if the Web Part is exported. But you can only exercise control of properties that are exported when the user is in personal view; in shared view, all property values are exported.

To test

  1. Add a Web Part from the gallery into a Web Part page and set the properties of the Web Part.

  2. On the Web Part chrome drop-down menu, click Export to export the Web Part. Save the .dwp file that is generated onto your local computer.

  3. Re-import the Web Part by choosing Edit Page from the Site Actions drop-down menu, and then click Add a Web Part.

  4. Choose Advanced Web Part gallery and options, and then select Import in the Web Part chrome drop-down menu.

  5. Browse to the .dwp file, click Upload, and then click Import.

  6. Make sure that the properties that were exported have been correctly imported.

  7. Verify that any property that would not make sense to export (for example, a Social Security number) has the ExportControlledProperties attribute set correctly. (The Allow Export Sensitive Properties check box in the tool pane should be cleared.)

Verifying Web Part Properties

Use the following procedures to verify that your Web Part properties function properly.

Verify that Web Part Property Attributes Are Correctly Defined

You can specify Web Part properties in two ways: as an XML BLOB contained within the Web Part or as an attribute within the Web Part.

Because of the way that the Web Part infrastructure handles property values, we recommend that you define properties as simple types rather than as complex types so that they work properly if they are specified as attributes of the Web Part.

To test

  1. Crate a static Web Part in SharePoint Designer 2007 and, in Design view, right-click the Web Part, select Web Part Properties, and try setting every property the Web Part has as an attribute.

  2. Browse to the page and see if the page fails or if the property setting was ignored.

Verify that Web Part Properties Displayed in Tool Pane Are User-Friendly

Because the tool pane is where users modify Web Part properties, it is important that users can work with Web Part properties easily in the tool pane.

To test

  1. Add the Web Part to a Web Part page. Click the Edit drop-down menu on your Web Part and then click Modify Shared Web Part. The tool pane should appear and display the Web Part properties.

  2. Verify that the Friendly Name is easy to understand, for example, a property named MyText should be My Text (notice the space between the two words).

  3. Make sure the Description (the ToolTip that appears) helps the user understand how and why to set the property.

  4. Verify that the Category name makes sense. (Miscellaneous is used when no category is specified for the property, but it is not especially helpful to the user.)

  5. Verify that the order of the properties is logical.

  6. If appropriate, check that these properties are localized using the following method:

    1. After installing the SharePoint language packs, create a new subsite and select a different language.

    2. Add the Web Part to a Web Part page in the new subsite and verify that Friendly Name, Description, and Category are localized in the tool pane.

Verify that Web Part Properties Are Not Dependent On Each Other

Because you cannot guarantee the order that properties are set in the tool pane, you should avoid writing Web Part properties that are dependent on each other and that both appear in the tool pane.

To test

  1. Test different values for properties in the tool pane, such as switching a value between true and false.

    Bb985502.note(en-us,office.12).gifNote:

    If a property is not visible in the UI, or is disabled, you can open the Web Part page in SharePoint Designer 2007, switch to Code view, and then set the properties by editing the XML. Export the Web Part, save the .dwp file, and then modify the .dwp file.

  2. Import the .dwp file back into the Web Page and check the property values.

Verifying Web Part Error Handling

Use the following procedures to verify that your Web Parts handle errors and incorrect user input.

Verify that Every Public Property Can Handle Incorrect User Input

As for any ASP.NET control or application, you should validate all user input before performing operations with it. This validation can help to protect against not only accidental misuse, but also deliberate attacks such as SQL injection, cross-site scripting, buffer overflow, and so on.

To test

  1. Verify that the Web Part can detect invalid input for properties and that it informs the end user when incorrect data is entered.

  2. Verify that the property is not used outside of its intended purpose. For example, if a Web Part is intended to allow users to link URLs, limit the protocol usage to HTTP instead of allowing any protocol to be saved (for example: ftp://).

  3. Verify that the Web Part HTML encodes the property value when rendering user input to the client.

  4. Check all the ways in which property values can be changed, including:

    • Modifying the .dwp file in a text editor.

    • Modifying properties in a tool pane.

    • Modifying properties in Code view in SharePoint Designer 2007.

    • Using the Web Part Page Services Component (WPSC), which is a client-side object model that provides a way to set properties and save them in the client browser.

Verify that Adding Several Instances of the Same Web Part to a Web Part Page (or to the Same Web Part Zone) Works Correctly

When you want multiple Web Parts to share client-side script, you should place the script in an external file and register the script for the page, to improve Web Part page performance and to simplify maintenance.

To test

  1. Add several instances of the Web Part to the same Web Part page. Be sure to execute any client-side script that is specific to the Web Part.

  2. Add several instances of the Web Part to the same Web Part zone. Be sure to execute any client-side script that is specific to the Web Part.

Verify that Web Part Handles All of its Exceptions

A Web Part should handle all exceptions rather than risk the possibility of causing the Web Part page to stop responding.

To test

  1. Enter error and boundary cases for Web Part properties.

  2. Verify that the Web Part handles all of its exceptions and does not break the page.

Conclusion

Web Parts are key elements of Microsoft SharePoint Products and Technologies. By using the guidelines described in this article, you can help ensure that the Web Parts you are responsible for are secure, well-coded, and integrate well with other components on the page.

Additional Resources

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft. All rights reserved.