Sharepoint 2013 Web Part Properties and SP Designer

Mike BerrymanOften while developing custom web part for Sharepoint, developers will include some custom web part properties that would allow for users to set values for certain variables, such as list names or number of items to display.  These custom web part properties would show up in the markup for the web part in sharepoint designer, allowing developers or power users to set these properties without having to go through the browser.  In Sharepoint 2010, specifically for visual web parts, this worked great since the developer would put these custom properties in the web part’s code, and since the visual portion of the web part was seperated into its own .aspx and .aspx.cs or .aspx.vb file, any properties the visual portion of the web part (AKA the view) used would be logically seperated from the web part’s properties.

In Sharepoint 2013, visual web parts no longer seperate the view’s code from the web part’s code.  This has some interesting side-effects when your view has properties that other code uses to construct/interact with the view.  If you’ve attempted this, you’ll probably have noticed one or both of two things happening in this scenario:

1) Custom web part properties get blanked out whenever the page is opened in sharepoint designer.

2) Sharepoing designer errors/crashes when the page with the web part is opened.

Either of these 2 scenarios are caused by sharepoint designer not knowing what to do with the view’s properties.  It seems that by default, sharepoint designer wants to treat view properties as though they are web part properties and render them as an attribute in the markup.  This can either be annoying (in the case of simple data types, like strings or integers that just get blanked out) or productivity-destroying (in the case of complex data types like lists or custom classes, which SP Designer doesn’t know how to handle).

Luckily, with the addition of a few extra attributes on the view properties, we can tell sharepoint designer to ignore any property we want.

public IList Facilities
        return (List)ddlFacilityFilter.DataSource;
        ddlFacilityFilter.DataTextField = "Title";
        ddlFacilityFilter.DataValueField = "Id";
        ddlFacilityFilter.DataSource = value;
        ddlFacilityFilter.Items.Insert(0, new ListItem("All", "0"));
        ddlFacilityFilter.SelectedIndex = 0;

This property is an example of a complex list, which sharepoint designer would completely balk at handling.  By adding the Browsable(false) and DesignerSerializationVisibility(DesignerSerialitzationVisibility.Hidden) attributes, Sharepoint designer will now ignore this property.

It should also be noted that this is only necessary for properties with setters.  If it’s just a getter, Sharepoint designer already ignores it (since, why inject an attribute into the markup for something that can’t be set?).

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s