WebControls Versus WebParts in SharePoint
In the example, you used a SharePoint aspx "Basic Page", because it is easy to manipulate without risk to the system. The downside of this approach is that you need to modify each newly created page to add the WebControl; to avoid this problem, create a template with the WebControl already in place. Applying the same principle, it's possible to use a SharePoint "Web Part Page" that contains more (sub) templates that are easier to modify than the "Basic Page".
One or more of the default aspx SharePoint pages may also be used. They reside in the "12 hive" of the file system in the server ("C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS"); they can be edited with any ASCII text editor (Notepad or Visual Studio). This brings the WebControl directly into the SharePoint structure; Microsoft does not recommend this approach because future Service Packs can override the modified ASPX pages without warning.
Modifications in the parameters of existing and placed WebControls in default aspx pages are also possible, with the same warning as before: A future Service Pack can roll back the modifications. Normally, the default WebControls in SharePoint does not use all the programmed parameters or they use it in a "default" way. If you need to edit parameters, open the ASPX page and modify it. An example of this approach is the modification of the "MyProfile" in "My Site" in MOSS: The control "ProfilePropertyLoader" in the "editprofile.aspx" page takes care of the data presentation in the window; this control contains many parameters not used in the default page presentation, but you can exploit them to modify the layout and, for example, render the information in sections as appears in the Profile DataBase screen in Central Administration.
Default SharePoint WebControls can be reused. If you need to add or delete functionality in default WebControls, it is—in general—possible to subclass them in Visual Studio through inheritance. The only condition is that the original WebControl has not been marked as "sealed". Again, if a Service Pack modifies the control interface and the subclass uses the original, the new control will not function. Another disappointment is the lack of information available from Microsoft: The SharePoint SDK gives only summary information about the implemented WebControls, thus developers are on their own to discover the correct configuration parameters.
Finally, because WebParts inherit from WebControls, they can be "appropriated" to function as WebControls: Install the WebPart in the conventional way in SharePoint; and, in the target ASPX page, register the WebPart in the same way as a WebControl:
<%@ Register Tagprefix="[TagName]" Namespace="[NameSpace WebPart]" Assembly="[Name assembly WebPart], Version=[Version WebPart], Culture=neutral, PublicKeyToken=[KeyToken WebPart]" %>
And in the location where it will be used, add the WebPart as a WebControl:
<[TagName]:[ClassName] id="MyWebPartId" runat="server"> <WebPart xmlns="http://schemas.microsoft.com/WebPart/v2" > <Title>Title-WebPart</Title> <FrameType>None</FrameType> </WebPart> </[TagName]:[ClassName]>
For the properties of the WebPart within the registration ("Title" and "FrameType" in the example), use the same value as for the registration of the WebPart (file ".webpart" for SharePoint 2007 of ".dwp" for 2003). The configuration panel of the WebPart, obviously, cannot be used, but this is a nice way to reuse functionality in an easy way.
In the preceding pages, developers have been offered a versatile tool to automate tasks under SharePoint. WebControls go into motion when activity is occurring in the Portal and do mechanized tasks in the Interface. In the SharePoint infrastructure, WebControls are equivalents to WebParts; moreover, as shall become evident, WebControls have unique benefits for developers and designers. However, as with all systems, there are downsides that must be examined as well.
WebControls are the basis for WebParts and are able to maneuver in places WebParts cannot reach, namely, outside the Web Zones. For ECM systems, they also guarantee assignments are done without human intervention; thus ensuring enterprise rules are strictly enforced. WebControls create reusable components that can be applied across the Portal and shared among different pages; additionally they can inherit from another control and extend that functionality.
Download the Code
You can download the code that accompanies this article here.
About the Author
Gustavo Velez is a MCSD Senior Application Developer for Winvision (http://www.winvision.nl), a Microsoft Gold Partner in the Netherlands. He has many years of experience developing Windows and Office applications, and more than five years of daily programming experience with SharePoint. The author's articles can be found in many of the leading trade magazines in English, Dutch, and Spanish. He is also pleased to be Webmaster of http://www.gavd.net/servers, the only Spanish-language site dedicated to SharePoint. Spanish-language readers may want to consult Velez's new book, Programación con SharePoint 2007 (http://www.dotnetmania.com/CTdnm/index.html).
Page 3 of 3