How the ListFormWebPart Works
The way that the ListFormWebPart works is fairly simple. It draws its header based on the properties of the list, it draws each user field, it draws the attachments, and it draws the footer. The process is very simple but also extremely powerful. The basic structure of the Web part is repeated for each of three modes in which the Web part can be drawn: display, edit, and add.
Because I'm only interested in creating new items and editing, I can leave the existing ListFormWebPart in place for displaying a list item. That will allow me to focus my efforts on the add and edit functionality. With a few thousand lines of code it is possible to replicate the add and edit functionality of the ListFormWebPart, as you'll see in the rest of this article. Once you have replicated the basic functionality of the Web part it's easy to add additional functionality like the ability to fetch from an external data source.
Creating the ListFormWebPart replacement
There are a few fundamental pieces of information that you need to make your replacement ListFormWebPart work. They are:
- What List is being worked on?Obviously you need to know what list to display fields for.
- What list item is being worked on?This not only tells you which item to display when editing but its absence tells you that you're adding a new record.
First, the list being worked on can be extracted from the URL that the control is being called on if in a list, or it can be stored in a property of the Web part. Because you can drop the Web part on any page, the latter method is a great tool for testing. It also provides flexibility in how you construct your sites.
The list item comes from the query string. SharePoint provides the ID number of the list item in the query string.
The example code shows you a working prototype that supports the basic structure for a few of the fields. There are a few basic pieces: enhancedlistformwp.cs, form.cs, field.cs.
The EnhancedListFormWP code is the Web part code. It has the public properties, defines which list the Web part is supposed to be working on, and uses CreateChildControls to add the form to the output of the control. (See my earlier article, "Wrapping Web Controls in a SharePoint Web Part").
Form.cs draws the header and sets up the output so that each field can be drawn one-by-one. The HTML emitted from form.cs is designed to match the output of the ListFormWebPart. From the styles to the tables the output is nearly identical. This helps minimize the possibility that the user will notice the difference between your control and the built-in control.
The Form sets up the Web part so that it will post back via a FrontPage RPC (Save). This means that you don't have to bother with the processing code to write the item back to a list. You can, however, change the code so that the post is returned to the Web part and the Web part processes the update to the list.
The workhorse of the sample is the Fields.cs, which does the work to draw each field. Fields represents a container for a collection of static methods that draw fields. The core is a dispatcher, ControlForField, which determines which type each field is and hands off the work of getting the right control to the individual field-focused functions. For instance, SingleLineField handles single-line text fields.
Adding it to the page
Once you have workable code (or have compiled the included sample application) and have installed it, you can add it to either the new or edit pages (newitem.aspx or edititem.aspx respectively.) To do this, add the ToolPaneView=2 on the query string on the page, browse to your Web part, and drag it on the page. Take the original Web part and close it. (Do not delete it since SharePoint wants to see that it still exists on the page.) Figure 2 shows what the page looks like when you're done closing the ListFormWebPart and have added the enhanced list form Web part.
Figure 2. Modified Form: Your modified editform.aspx page including the EnhancedListForm Web part.
Figure 3. Back to Original: The modified and enhanced page looks like the original page.
You now have added the Web part to the appropriate page in the list. Now when you go to add or edit an item your Web part will be displayed rather than the SharePoint list form Web part. Figure 3
shows the resulting pageit should look identical to the way the edit page looked before we started.
Enhancing the Edit Experience
Now that you have your own code for editing SharePoint lists it becomes a trivial task to support new fields or options. Here are a few ideas for how to support new features with your new enhanced editing form:
- Get a drop-down from a databaseBy using the description field for a SharePoint field you can store away the configuration necessary to connect to a database, retrieve values, and display them in a drop-down box.
- Call a Web serviceUsing the same principles of stuffing configuration into the description box you can setup a Web service that returns the data that you need.
- ValidationAnother approach is to have your Web part read its operation from the web.config file and potentially even dynamically load DLLs to do multi-field validation. All you need to do is define an interface that turns over all of the fields to a type that implements an interface (say IFormValidate) and then use reflections to dynamically load and execute the specific code for the form.