SharePoint 2010 Visual Web Parts

Ever since the sneak peak developer videos were released months ago I’ve been wondering about the implementation of SharePoint 2010’s visual web parts. If your not sure what I mean, with SP 2010 and Visual Studio 2010 you can now create a web part with a design time experience, so you can drag and drop controls etc:

Now that the beta is upon us I can finally take a look under the covers at a visual web part, the default project structure looks like:

The project contains a number of new items: Features and Package both relate to the deployment features of Visual Studio 2010 in that you can create SharePoint solutions (aka the Package) and features which can be activated, visual studio will automatically deploy and activate your web parts using this solution and features.

Next we move on to the VisualWebPart1.cs file which contains the secret sauce:

    public class VisualWebPart1 : WebPart
   {
      

       // Visual Studio might automatically update this path when you change the Visual Web Part project item.
       private const string _ascxPath = @"~/_CONTROLTEMPLATES/TestVisualWebPart/VisualWebPart1/VisualWebPart1UserControl.ascx";

       public VisualWebPart1()
       {
       }

       protected override void CreateChildControls()
       {
           Control control = this.Page.LoadControl(_ascxPath);
           Controls.Add(control);
           base.CreateChildControls();
       }

       protected override void RenderContents(HtmlTextWriter writer)
       {
           base.RenderContents(writer);
       }

As you can see, the web part still derives from WebPart, no special VisualWebPart base class, nothing special going on here.

In fact we are using the same techniques and approach that would have worked in Visual Studio 2008, the only difference now is that Visual Studio 2010 has better tooling support for SharePoint 2010 and will deploy the ascx file automatically for us to the _CONTROLTEMPLATES directory as part of the solution.

There are still a few things a web part developer should know, lets look at the case where we want to expose some custom properties on a web part that we want a user to configure via the web interface:

      [System.Web.UI.WebControls.WebParts.WebBrowsable(true),
      System.Web.UI.WebControls.WebParts.WebDisplayName("Custom Prop"),
      System.Web.UI.WebControls.WebParts.WebDescription(""),
      System.Web.UI.WebControls.WebParts.Personalizable(
      System.Web.UI.WebControls.WebParts.PersonalizationScope.Shared),
      System.ComponentModel.Category("Settings"),
      System.ComponentModel.DefaultValue("")
      ]       
       public string CustomProp
       {
           get { return customProp; }
           set { customProp = value; }
       }

Now if we put this property and attributes on the VisualWebPart1UserControl (in VisualWebPart1UserControl.ascx.cs) we will find that the custom property builder won’t appear (the web interface that lets us set a value to this property).

We have to add the custom property on the VisualWebPart1 class (in VisualWebPart1.cs) :

    public class VisualWebPart1 : WebPart
   {     

       // Visual Studio might automatically update this path when you change the Visual Web Part project item.
       private const string _ascxPath = @"~/_CONTROLTEMPLATES/TestVisualWebPart/VisualWebPart1/VisualWebPart1UserControl.ascx";

       protected override void CreateChildControls()
       {
           Control control = this.Page.LoadControl(_ascxPath);
           Controls.Add(control);
           base.CreateChildControls();
       }

       protected override void RenderContents(HtmlTextWriter writer)
       {
           base.RenderContents(writer);
       }

       [System.Web.UI.WebControls.WebParts.WebBrowsable(true),
      System.Web.UI.WebControls.WebParts.WebDisplayName("Custom Prop"),
      System.Web.UI.WebControls.WebParts.WebDescription(""),
      System.Web.UI.WebControls.WebParts.Personalizable(
      System.Web.UI.WebControls.WebParts.PersonalizationScope.Shared),
      System.ComponentModel.Category("Settings"),
      System.ComponentModel.DefaultValue("")
      ]
       public string CustomProp
       {
           get { return customProp; }
           set { customProp = value; }
       }
   }

Now we get our custom property builder:

Lets assume that we want to pass the user entered value to the Visual component (the usercontrol) we now need to change the visual studio generated code to cast the user control to our visual user control class, rather than the more generic base Control:

       protected override void CreateChildControls()
       {
           //user control is of type VisualWebPart1UserControl and defined with private scope
           userControl = (VisualWebPart1UserControl)this.Page.LoadControl(_ascxPath);
           Controls.Add(control);
           base.CreateChildControls();
       }

From here we can set properties on the userControl variable as normal.

The same principles apply to web part connections, so the connection points need to be defined on the web part class (not the usercontrol). Visual Studio will take care of deploying the ascx file which is still a big win.

I doubt an experienced web part developer would have any issues, but I wonder how many new web part developers will not know that they can make there web parts configurable and connectable given that they will likely only use the Visual Studio lie presented to them?