A colleague of mine recently asked me if the WebPart he was writing should inherit from the ASP.Net WebPart class or the SharePoint WebPart class. He was a bit confused because he had seen a few articles online that talked about the benefits of inheriting from one class or the other.
Some articles recommend using ASP.Net WebPart class for general ASP.Net interoperability while other articles recommend using the SharePoint WebPart class to gain access to its additional features. This MSDN article enumerates the list of features provided exclusively by the Windows SharePoint Services WebPart class:
-
Cross page connections
-
Connections between Web Parts that are outside of a Web Part zone
-
Client-side connections (Web Part Page Services Component)
-
A data caching infrastructure that allows caching to the content database
My colleague was confused. He wanted the ASP.Net interoperability but he wasn’t sure if he would regret not having access to the additional SharePoint WebPart class’ feature.
To my mind, the decision is very simple for most SharePoint developers: use the the SharePoint WebPart class. While the idea of general ASP.Net interoperability is nice, it is not likely to pan out. The reason: if you are writing a web part for SharePoint, you will likely want access to the SharePoint object model to work with list and document data, get SharePoint context, etc…. As soon as you add a reference to the Microsoft.SharePoint.dll assembly to your project and use any of its types, your assembly has already been strongly tied to SharePoint and will not work on a plain ASP.Net web site. If your assembly is already tied to SharePoint, then you may as well get the added functionality of the SharePoint WebPart by inheriting from it.
Hi,
I might somewhat agree, but there are advantages of using the ASP.net webpart. One thing I prefer is that the ASP.net 2.0 webpart uses the EditorPart instead of the ToolParts.
Cheers
/WW
Hi, I usually recommend to use the ASP.NET Web Part base class. Just like the article you mentioned seems to do:
"When to Derive from the Windows SharePoint Services WebPart Class
In a very few cases, you may have to create Web Parts that support Windows SharePoint Services features that are not available in the ASP.NET Web Part infrastructure. In these cases, you can create a class that inherits from the Windows SharePoint Services WebPart base class."
I understood that only in those case you explicitly need to have e.g. Cross Page Connections, you use the SharePoint base class.
Jan
Wictor, the SharePoint Toolpart class ultimately inherits from the ASP.Net EditorPart class, so you can use regular EditorParts to edit SharePoint WebPart objects by overriding the CreateEditorParts method just as you would in an ASP.Net WebPart.
Jan, it has been my experience that once you start thinking about deploying a web part into SharePoint, you will want to take advantage of some of the SharePoint infrastructure or access SharePoint data. Once you do that, your web part will be tied to SharePoint. At that point there is no benefit not to use the SharePoint WebPart class.
Eugene,
you're right, never reflected on that. But the toolparts will still be in the bottom of toolpane compared to editorparts that is at the top.
/WW
Wictor, you can actually control the order in which your ToolParts are rendered by controlling the order in which you populate the TooPart array in the GetToolParts method override. The code below will render a custom ToolPart on top, then the CustomPropertyToolPart, then the default ToolParts:
public override ToolPart[] GetToolParts()
{
List<ToolPart> toolParts = new List<ToolPart>();
toolParts.Add(new BlackBlade.MyCustomToolPart());
toolParts.Add(new CustomPropertyToolPart());
toolParts.AddRange(base.GetToolParts());
return toolParts.ToArray();
}
Thanks,
I've not used SP webparts since SP2003. Gotta give em a try next time.
/WW