SharePoint 2010 WebPart Enhancements

It’s been too long since my last post. I struggle as a blogger because I feel my time is better spent reading bloggers like Andrew Connell, Waldek Mastykarz, Eric Shupps, and so on, rather than writing my own content. I never imagined this long of a gap between my last posts, but the recent SharePoint conference has re-inspired me to begin writing again.

I was one of the lucky few who was registered and set to hit Vegas for the 2009 SharePoint conference. However, as luck would have it, the H1N1 virus had other plans for me, and I was forced to stay at home and watch all of the conference online. Although I missed out on a lot of the fun, I was able to soak in a lot of the information, and so I want to summarize some of the new features for anyone who wasn’t able to attend, or didn’t get to all of the sessions they had hoped to watch.

Most of the content in this post came from a great session on Advanced WebPart development, which was done by Maurice Prather, from ShareSquared. Here are the main points I’d like to highlight:

Versioning

Anyone who has had an author put a lot of content into a Content Editor WebPart, and ask the question “Why is my content not changing when I restore a version?” is going to be happy about this addition. WebParts are now versioned with pages, so you no longer are only left with the option of putting your content into the publishing content fields. There are a lot of strong opinions out there saying the content editor WebPart shouldn’t even be used, but if you’re in an organization who has decided to continue using it, being able to version that data will be a big help. It will also be nice for keeping configuration setups for other WebParts such as the content query WebPart, where you’ve gone through revisions and want to roll back to earlier settings.

Visual WebParts

This is really not something new to SharePoint 2010. What’s new is Visual Studio’s excellent automation of a system many have been using for a long time. ASP.Net developers are often more comfortable when working within a designer GUI where controls can be dragged and dropped. While using CreateChildControls is perfectly valid, and still a good way to go, creating an experience where less code is written often leads to more productivity. The trick has always been the following:

1. Create a User Control within Visual Studio
2. Push the User Control into the ControlTemplates directory inside the 12 Hive (located at: 12 Hive/Templates/ControlTemplates)
3. Create a WebPart class and use Page.LoadControl inside CreateChildControls to load in your User Control

This same concept is exactly what Visual Studio is now doing for you, but its taking out many of the steps you would perform manually, and making it a much more complete experience.
(Note: Visual WebParts will not work when part of a Sandboxed Solution, something I plan to recap in another post)

Cross-Site Scripting Safeguards (XSS)

This affects old and new WebParts, and it’s important to understand how your current solutions could be affected, even if they will still otherwise work in SharePoint 2010. Simple properties on a WebPart class are normally displayed in the Editor Toolbar (in the default Miscellaneous category if not specified). Many times a developer might take the value of a property entered in the editor, and directly output it to the screen (i.e. new LiteralControl(QuoteOfTheDay) ). The issue with this is that if any html, script, etc… were injected into this property, by outputting it to the screen, malicious code could be run that affects all users to the site. Properties now have a new RequiresDesignerPermission attribute to determine if a property needs designer permissions in order to display on the editor toolbar, and SafeControl entries now have a new SafeAgainstScript attribute to control whether a control is protected. The default behavior without specifying either is that only designers can edit the properties. When SafeAgainstScript is set to true, and RequiresDesignerPermission attribute is set to false, then and only then, can Contributors gain access to edit the property. Going forward this should help to ensure developers are properly encoding values, etc…, before they mark a control as SafeAgainstScript and set RequiresDesignerPermission to false, if they are going to be outputting properties onto the screen.

(Note: personalized properties will not be affected by this new addition, since they would only display for an individual user, and would not be a risk to other viewers)

Miscellaneous

Here are a few things to look forward that don’t necessarily warrant their own section, but are nonetheless interesting:

• The ASP.Net WebPart class is still the preferred class to inherit over the SharePoint WebPart class
• More functionality is being added to the ASP.Net WebPart class
• Developers are encouraged to deploy WebParts as features, and not directly through the solution manifest file or other means
• Thew new enhanced WIKI allows WebParts to be dropped into anywhere inside the main content area, without having to put it into a WebPartZone (This is all happening behind-the-scenes through a dynamic zone that pushes WebParts into placeholders)

Summary

I hope this has been informative to some of you as to what we have to look forward to in WebParts inside SharePoint 2010. I am sure as Beta is released in November, and the product gets to release, there will be even more gems to discover inside this new and very promising effort from Microsoft.

Cheers,
Matt