Working with the SharePoint DataFormWebPart in Custom Application Pages: Part I

I just recently got through 2 phases of a major SharePoint 2010 project where we made extensive use of the build int DataFormWebPart on a series of custom application pages. We were basically building a web based wizard to walk end users through a process. Each instance of the process had it’s own sharepoint list item, and we used customized DataFormWebParts to layout all the fields of the list item onto a bunch of different screens.

What I found in doing this though, is that there isn’t alot of documentation about how to use the DataFormWebPart in a custom page with lots of codebehind. This is especially frustrating, since the webpart has lots of interesting little quirks and limitations that I had to find out about the hard way. In the next two blog posts I’m going to talk through some of those, as well as providing the code for a enhanced DataFormWebPart that gets around some of them.

What is the DataFormWebPart

If you haven’t worked with the DataFormWebPart before, it’s basically the webpart that SharePoint uses to create list item forms. All the default create, update, and view forms for list items are powered by a DataFormWebPart. Essentially, the dataform webpart is one of many XsltViewerWebParts, which allow developers and site admins to provide their own XSL markup to control how SharePoint data is rendered.

This makes it a very powerful tool for custom application pages. By dropping a DataFormWebPart on your page, you don’ t have to worry about building out any CRUD plumbing. Just choose which fields you want to show up, tweak and style your html, and you’ve got a basic form up and running. At least, that’s how it should work in theory…..

Getting Started

In actual implementation, nothing with the DataFormWebPart is quite so simple. The first challenge is even managing to get something that loads onto your page. The DFW comes with a bevy of parameters and properties, most of which have unclear names, and require specific, often undocumented values. Unless you enjoy seeing lots of big yellow and red error screens, you’re better off letting SharePoint Designer generate your initial markup, and iterating off that. To do so, boot up designer in the site where your list is, and create a Webpart Page. Once inside your new page, select the “SharePoint” menu from the ribbon, and choose the option “Custom ListForm.” This will open up a little wizard where you can choose the list and content type.

When you’re done, Designer will spit all the markup out onto your page. Copy and paste the webpart markup into your Visual Studio. Don’t forget to add

<%@ Register Tagprefix=”WebPartPages” Namespace=”Microsoft.SharePoint.WebPartPages” Assembly=”Microsoft.SharePoint, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c” %>”

at the top of your custom application page, so that you’ve got the right namespace loading for the DFW. You’re also going to want to delete the autogenerated .designer.cs page that sharepoitn creates for you. If you don’t, all the xsl based ID’s will prevent you from building, since they have invalid characters for code behind. This means you may also want to set the pages “AutoEventWireUp” property to false.

This should at least get your page to load. Now you can go in and start editing the xsl. By default you’ll probably have all your fields on the form, so you can remove them by deleting the FormField control who’s FieldName property matches the field you don’t want. You can add as much extra html or javascript as you like, to really make the form stand out. The main things to watch out for here, is be very careful to ensure you don’t have an duplicate ID’s for your controls. The DFW is likely to throw a very cryptic error if that happens.

Once you’re done styling the form, you’ll also need to put some thought into how people access it. The DFW relies on two QueryString variables to figure out what list and list item to grab the data from. You’ll see these two variables, , ListItemId and ListID, called out in the “ParameterBindings” section of the DFW markup. You can see that they get pulled from two QueryString values, ID and ListID. You’ll need to make sure that you set those query string values when you build the urls that users use to access your forms.

Lastly, you’ll also want to look at the “PageType” property of the DFW and the ControlMode property of each of the form fields. These control whether you can read or edit the form fields, and whether or not a save will create a new item, or update an existing one. For page type, the valid values are “PAGE_DISPLAYFORM”, “PAGE_EDITFORM”, and “PAGE_NEWFORM.” For ControlMode the values are “Edit”, “New”, and “Display”

Otherwise though this is the easy part. We’ll get to the fun stuff next post.


One thought on “Working with the SharePoint DataFormWebPart in Custom Application Pages: Part I

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