Developing a Custom Web Part, Part 1
Paul Schaeflein
10/10/2005
Printer Friendly Version
This series of articles has focused on making end-users and administrators more effective in updating a WSS/SPS site. For the next few articles, I'm going to be more technical and discuss Web Part development. This is certainly not the first online article on Web Part development. For beginners, I can recommend two articles from JupiterWeb's DevX network that explain how to get started and create simple web parts:
Although Microsoft provides many examples in the software developer's kit, most developers who are starting to work with Web Parts still have questions. When I am starting with a new technology, I search for many examples. By comparing the examples, I believe that I get a better understanding of the technology and how it can be used to solve my problem.
My goal in this part of the series is to provide another example to developing Web
Parts. Together, we will walk through the process and I will explain why I wrote the code in a particular manner. Keep in mind that there may be different ways to do the same thing, and that my solution may not be the best for your situation.
Web Part Development Process
When developing a Web Part, I follow these steps:
- Define requirements
- Create an HTML mockup of the output
- Identify sources of data
- Create form(s) for user input (if necessary)
- Create data access code (if necessary)
- Create output code
I admit this is a very simplistic list, but it keeps me focused on providing exactly what the end-user is looking for. Let's discuss these steps at a high-level.
Define Requirements
I find it very helpful to simply re-state the requirements. This will quickly highlight any miscommunication. Then, I recommend that the requirements become more technical, using SharePoint terms and features as appropriate. This step of the process will align the expectations of the developer and the end-user. In some cases, you may find an out-of-the-box solution.
HTML Mockup
Yes, this is an obvious step. It eliminates confusion between the parties involved in the development project. But having a mockup in HTML has another advantage — I already know the exact format of the Web Part's output. In some cases, this can be copied and pasted right into the Web Part.
Identify Sources of Data
In the vast majority of cases, the Web Part will render itself dynamically based on some data. (For cases where the output is constant, I would use the Content Editor Web Part. The Content Editor Web Part has been used a few times already in this series.) Identifying and verifying this data will make sure that the actual output is correct. This data source may be a SharePoint list or document library (as in the Document Library Quick Launch) or an external database (as in the Phone Directory).
Create Form(s) for User Input (If Necessary)
In addition to the data source, user input of some type is generally required. This input could be a filter to apply to the data or descriptive text. Within the Web Part framework, there are some built-in methods for capturing user input: the Form Web Part and the Web Part Tool Part. There should be a clear requirement or benefit to creating a custom form instead of leveraging these built-in tools.
Create Data Access Code (If Necessary)
The Web Part must actually retrieve the data from the data source. There are some advanced features in the Web Part framework that improve performance of this code: caching and asynchronous threads. One of the most common questions asked when writing data access code is code-access security. Code-access security is a very advanced topic, so I will touch on it only as necessary.
Create Output Code
The outputting of HTML from a Web Part is called rendering. There are several techniques that can be used to render a Web Part. Each technique has advantages and disadvantages — understanding them is necessary to create a quality Web Part.
With an understanding of my Web Part Development process, we can now proceed to implement it in the development of a Web Part for project managers.
Milestone Countdown Web Part
The Web Part that I am developing in this article is the Milestone Countdown Web Part. Since SharePoint is often used for project management, it is helpful to remind the project team of upcoming milestones and the time remaining until that date. I have to admit, however, that I initially wrote the countdown code so that I would know the time remaining until my latest vacation.
Define Requirements
Following our development process, let's state the requirements of the Web Part.
Create a Web Part to use on a project home page that will display a countdown timer to a user-specified date and time. In addition to the timer, the part will display user-specified text and optionally a user-specified image. This Web Part will be offered as a replacement for the Site Image Web Part at the top-right corner of the WSS Team site template.
Based on my knowledge of SharePoint pages, I recognize the default Site Image Web Part. I know that it is displayed without a frame and title. The Site Image Web Part has a tool part that prompts for the address to an image as well as some additional display properties. The width of the Web Part zone is only a few hundred pixels.
I am going to add a few requirements for the new Web Part:
- The default frame style for the part will be "None."
- Since the frame and title will not display, the part requires a custom property for the text.
- Custom properties are required for the image. Specifically: image URL, alternate text and height and width. The height and width are specified to allow the end-user to shrink the image if desired.
- Since the image is optional, provide a separate input form for the image properties.
- Different project managers will have different preferences for the countdown timer. Some will want to display only the days remaining, while others may want to see more hours and minutes. Provide for the end-user to choose the timer precision. Include a choice of Auto, which will display a more precise timer as the event approaches. For example, the display starts are days only. When the event is less than one day away, the display becomes hours and minutes. When the event is less than one hour away, the display becomes minutes and seconds.
HTML Mockup
The HTML for this Web Part is rather simple. The image, text, and timer are displayed in that order, and are centered inside the Web Part. I will likely want to add some CSS class names to the HTML, the basic structure should not change.
<html>
<head>
<title>Milestone Countdown</title>
</head>
<body>
<P align="center">
<img alt="New building" src="/images/building.jpg">
</P>
<H3 align="center">Move to new building<br>16 Days</H3>
</body>
</html>
|
Identify Sources of Data
For the Milestone Countdown Web Part, the only source of input is from the end-user. The input is required only once for the Web Part, and is the same for all site visitors. The Web Part framework provides for properties to store information related to a Web Part. There properties can be stored for each user, or shared among all users. We will use the shared storage for our properties.
| Property |
Data Type |
Description |
| Text |
String |
The name of the milestone. This is displayed above the countodwn timer. |
| Milestone Date |
Date/Time |
The date and time of the milestone. The countdown timer will reach zero at this time. |
| Timer display precision |
Custom list of choices |
Controls the display of the timer. Refer to requirements. |
| Image URL |
String |
Used for the <IMG> tag. |
| Image Alternate Text |
String |
The alternate text that describes the image. Used for the <IMG> tag. |
| Image Width |
Integer |
The width (in pixels) to use for the image display. |
| Image Height |
Integer |
The height (in pixels) to use for the image display. |
Summary
At this point, we have a solid definition of what the custom part should do. Next time, we will continue the development process, starting with the development of the input forms. In the interim, I encourage you to download the software development kit from Microsoft and start learning more.
About this series
This series of articles on SharePoint is intended to help you understand the capabilities of the product, as well as provide tips and tricks, development ideas, information from Microsoft, information from the community, and perhaps some samples. Like many other series on IntranetJournal.com, I plan to include how-to articles that can help you with your deployments — ways to customize a page; deployment scenarios; content management; etc. With such a diverse product, there is no lack of topics for this series of articles. What would you like to read?
About the author
Paul Schaeflein is a developer with more than 20 years experience. Paul has been developing dynamic and interactive Web sites since 1996. Paul has worked on all of the versions of SharePoint and has worked with the .NET framework since its debut. You can reach Paul through his blog at http://www.schaeflein.net/blog/.
Read Part 2 of Developing a Customer Web Part at: http://www.intranetjournal.com/articles/200511/ij_11_04_05a.html.
Printer Friendly Version