Chapter 7: Advanced Web Part Development

Although basic web parts are useful for customizing the display of information and some light system integration, they have some limitations. I noted, for example, that properties were limited to simple values of types like String , Integer , and enumerations. Also, the web parts you created in Chapters 5 and 6 were isolated from one another and could not take advantage of web part connections. Additionally, all of my examples only operated as server-side code. In this chapter, you'll examine advanced web part concepts that allow you to overcome the limitations found in the basic web part.

Client-Side Web Parts

When I began our discussion of web parts, I made it clear that they were essentially ASP.NET controls running in a special infrastructure. This definition is significant because all of the web parts you have written so far have been designed to operate on the server. They have relied upon post-back processing to access data and integrate other systems. This fundamental processing model is unchangeable in SharePoint Services; however, you can utilize some new techniques to introduce client-side processing to your web parts.

Using ActiveX Controls

The most-likely reason to use client-side processing is to incorporate an ActiveX control into your web part. In some cases, by using an ActiveX control, you can provide functionality that is not easily created through server-side processing. A good example of such functionality is found in the Office Web Components (OWC).

OWC is a set of ActiveX controls that implement spreadsheet and charting functionality that is compatible with Office products like Excel. The controls have a rich interface that allows end users to interact with data sources, pivot spreadsheets, and change chart characteristics. This functionality is not present in ASP.NET and would be difficult to implement through server-side processing.

You can include ActiveX controls in a web part by writing an appropriate <OBJECT> tag in the RenderWebPart method. As far as the web part is concerned , <OBJECT> tags are no different than any other HTML element. When the web part appears to the client, however, the referenced ActiveX control will load into the portal. The following code shows an example of creating an <OBJECT> tag in a web part.

 output.Write ("<OBJECT id=""myobj""" & _ " style=""VISIBILITY: hidden; WIDTH: 0px; HEIGHT: 0px""" & _ " classid=""clsid:238F6F83-B8B4-11CF-8771-00A024541EE3""" & _ " VIEWASTEXT>" + vbCrLf) output.Write("</OBJECT>" + vbCrLf) 

The most challenging part of incorporating an ActiveX control is correctly constructing the <OBJECT> tag. Fortunately, you can easily lift the required HTML from Microsoft FrontPage. Whenever you add an ActiveX control to a page, FrontPage generates the appropriate code. Simply use this code as a template for your RenderWebPart method.

Although the <OBJECT> tag is sufficient for incorporating the ActiveX control into the user interface, most ActiveX controls rely on a client-side script to make them fully functional. This means that you may have to generate client-side script routines in the RenderWebPart method. This can be a bit tricky, especially when the client-side script uses a large number of quotation marks. Listing 7-1 shows an example of creating a JavaScript block using VB.NET in the RenderWebPart method.

Listing 7-1: Creating a Client-Side Script

 With output     .Write("<script language=""javascript"" type=""text/javascript"">")     .Write("<!")     .Write("function windowLoad()")     .Write("{")     .Write("//Code goes here")     .Write("}")     .Write(">")     .Write("</script>") End With 

 

Using Script Files

In Listing 7-1, I showed you how to generate your own script code directly in the RenderWebPart method. However, you can also create separate script files that can be accessed at runtime by your web parts. There are two techniques for accessing such scripts: linking and embedding.

Linking a script file allows you to create your script in a separate file and put it on the web server. When a web part references the script, it is loaded into the browser cache. All future references to the script then utilize the cached code. Linking a script requires you to first create the script in a separate text file. Once this file is created, it is placed under a special folder and referenced in your web part.

To make a script available to web parts for linking, follow these steps:

1. Open the Windows Explorer and navigate to \Program Files\Common Files\Microsoft Shared\Web Server Extensions\wpresources .

2. In this folder, create a new folder with the name of the web part assembly (e.g., SPSPageView ).

3. Under the new folder, create another folder consisting of the Assembly , Version , Culture , and PublicKeyToken (e.g., 1.0.0.0_en-us_eb3e58846fb2ac2b ).

   Note

   Although the correct format for the new folder is version_culture_token , you may leave out the culture information when the culture is neutral.

4. Create a script file in a text editor.

5. Save this file under the folder you just created.

Once the file is saved in the appropriate location, you may use the RegisterClientScriptBlock method of the Page object to load the script at runtime. This method takes as arguments a unique identifying name and a String for the script. Because you are linking the script, you only need to reference the location of the script file. The following code shows how to link a script file.

 String scriptKey = "MyKey"; String scriptFile = this.ClassResourcePath + "\myscript.js"; String scriptBlock = "<script language='javascript' src='" + scriptFile + "'></script>"; Page.RegisterClientScriptBlock(scriptKey,scriptBlock); 

Embedding a script differs from linking it in that the script is not stored in a separate file. In this case, the script is simply created in code and then loaded using the RegisterScriptBlock method. Regardless of which method you choose, however, you should always check to see if the script has been loaded previously before you attempt to load it. You can do this using the script key and the IsClientScriptBlockRegistered method of the Page object. Although no error will occur if you attempt to reload a script, doing so will reduce the efficiency of your overall loading process.