Getting to know the Data Form Web Part
Series Information
Getting to know the Data Form Web Part (1 of 4)
What is the Data Form Web Part?
This article is the first in a four part series on the Data Form Web Part. First things first - what is the
Data Form Web Part (DFWP)? The easiest place to start is that the DFWP is a Web Part that can be
added to any SharePoint site. Unlike most Web Parts, however, the DFWP cannot be (easily) added
through the web browser - it must be created using SharePoint Designer.
Components of a Data Form Web Part
Before we jump into creating a DFWP, it is helpful to understand the components that make up a DFWP.
There are three main components of any Data Form Web Part:
Data Source The DFWP supports many different data sources including:
• SharePoint Lists and Libraries
• An XML File
• ODBC/SQL Database
• Web Service
Or a combination of sources using a Linked Source
Parameters Parameters can be used to make your DFWP more dynamic. The DFWP can read
parameters from several sources including the Query String, Form fields, and cookies.
XSL Simply put, this is what defines how your DFWP displays. The DFWP uses an XSLT
stylesheet to transform data into HTML (for more information on XSL see the XSL page
at the W3C: http://www.w3.org/Style/XSL/)
Table 1 - Components of a Data Form Web Part
Creating a Data Form Web Part
To create a Data Form Web Part, you will need to open a page on a SharePoint site using SharePoint
Designer:
Figure 1 - An .aspx page in SharePoint Designer
To insert a Data Form Web Part, first select a Web Part Zone and choose Insert Data View from the Data
View menu:
Figure 2 – Data View Menu
A Data Source Library Task Pane will appear displaying the available data sources for the current site:
Figure 3 - Data Source Library
In this example we’ll select an existing SharePoint List called “Stuff” and choose the Show Data option:
Figure 4 - Previewing the data in a Data Source
The Data Source Details will appear in the Task Pane displaying the fields from our list:
Figure 5 - Data Source Details for a SharePoint List
We can now select the fields we would like to display in our Data Form Web Part. By clicking on fields
while holding Control, we can select multiple fields and then choose to insert those fields as a multiple
item view:
Figure 6 - Inserting fields into a Data Form Web Part
We now have a Data Form Web Part:
Figure 7 - Data Form Web Part in SharePoint Designer
Next you will want to save your page. When you save, you will receive a prompt:
Figure 8 - Site Definition Page Warning
This prompt does not indicate an error; it simply warns you that saving will customize the page. If you
are not familiar with customizing pages (formerly referred to as “unghosting”) in SharePoint I highly
recommend clicking the “About SharePoint site definitions” link.
Once saved, your Data Form Web Part will look very similar to an out of the box List View Web Part:
Figure 9 - Data Form Web part in Internet Explorer
Behind the scenes
If we modify our new Data Form Web Part in Internet Explorer, we can see some of what is happening
behind the scenes. Click on the Web Part Menu and select Modify Shared Web Part:
Figure 10 - Modifying our DFWP in Internet Explorer
In the Web Part Task Pane you will see two properties you can edit:
Figure 11 - DFWP properties
These two properties (XSL Editor and Parameters Editor) map to the components we discussed earlier in
Table 1. Note that you cannot change the Data Source outside of SharePoint Designer. If you click on
the XSL Editor, you will see the XSL that was generated for you by SharePoint Designer:
Figure 12 - Viewing the XSL of a DFWP in Internet Explorer
While the XML can be pretty tough to look at, the good news is that even if you are not an expert at XSL,
if you have some HTML background you will be somewhat familiar with what you are seeing. For
example, in the section I’ve captured in figure 13 you can see that we have a few table cells. Inside of
those cells we are using some XSL markup to output the Title and Color fields. For the Quantity field, we
are first running a format-number function, and then displaying the output.
Figure 13 - XSL from a Data Form Web Part
While it is possible to make changes to the DFWP from Internet Explorer, in practice you will make most
of your changes in SharePoint Designer.
Configuring the Data Form Web Part
If we want to configure our Data Form Web Part in SharePoint Designer, the easiest way is to open the
Common Data View Tasks menu by clicking on the chevron in the top-right corner of our DFWP:
Figure 14 - Common Data View Tasks
From the Common Data View Tasks menu we can add, remove, or reorder columns in our DFWP. We
can also apply filters and add sorting along with many other options. For now, let’s explore how you
could use Parameters in a Data Form Web Part. If you click on the Parameters… link, you will open the
Data View Parameters dialog:
Figure 15 – Data View Parameters dialog
In this example we’ll add a Color parameter that reads from the Query String:
Figure 16 - New Color Parameter
Now that we have created the parameter, we can now configure a filter for our DFWP. Back on the
Common Data View Tasks menu; select Filter to open the Filter Criteria dialog:
Figure 17 - Filter Criteria dialog
Now we’ll configure our DFWP to filter using our new parameter:
Figure 18 - Filter by color
Once our filter is applied SharePoint designer applies the filter to our live preview. Because we did not
set a default value for our Color parameter, we are presented with the “No Matching Items” template:
Figure 19 - DFWP “No Matching Items” template
To allow you to once again view what your DFWP would look like, select the “Show with sample data”
option in the Common Data View Tasks Menu:
Figure 20 - DFWP option: Show with sample data
Now if we view our page in the browser and pass in a parameter we can see that our filter has been
applied:
Figure 21 - DFWP with filter applied in the browser
Conclusion
As you can see, the Data Form Web Part is a highly configurable Web Part that allows you to quickly
create highly customized views of your data. In my next article we will explore some of the more
advanced views you can create using the Data Form Web Part.
Getting to know the Data Form Web Part (2 of 4)
Advanced Data Form Web Parts
In the first article of this series we introduced the components of a Data Form Web Part. One of the
core components of a Data Form Web Part is the XSL which defines how the DFWP will render. You can
customize the XSL to change how the DFWP is displayed but before we jump into customizing the XSL
code let’s take a look at what SharePoint Designer can do for us.
Conditional Formatting
Data Form Web Parts support conditional formatting which allows you to apply formatting and visibility
rules to html elements. To work with conditional formatting you’ll need to open the Conditional
Formatting task pane on a page with a Data Form Web Part. To open the task pane, open the Common
Data View Tasks menu by clicking on the chevron in the top-right corner of our DFWP and then select
Conditional Formatting:
Figure 1 – Opening the Conditional Formatting task pane
You should then see the Conditional Formatting task pane and usually one existing condition:
Figure 2 – The Conditional Formatting task pane
Note that the create button is disabled because we have not selected an HTML element to apply any
conditional formatting to. Let’s create a new Conditional Formatting rule that will change a table row’s
background color based on the color selected in the list. First, we need to select a row (which isn’t
always as easy as it sounds). If you are lucky, you can position the mouse just right to give you the
option to select a row. I find it is easier to simply select a cell and then choose select row from the
menu:
Figure 3 – Selecting a Table Row
Once you have selected a row you should also see a selected <tr> in the Quick Tag Selector:
Figure 4 – The Quick Tag Selector
At this point you are ready to add a conditional formatting rule. Choose create from the Conditional
Formatting task pane and choose Apply formatting...
Figure 5 – Opening the Conditional Formatting task pane
Next we need to define when the formatting will occur by defining the condition. In this case we’ll apply
formatting when the Color field is set to Red:
Figure 6 – Adding Condition Criteria
Now we are presented with the Modify Style dialog. From here we can define what to do when our
condition is met. In this case, we’ll just set the background color to red:
Figure 7 – Applying a style to your Conditional Formatting
Once we press OK, our conditional formatting is revealed using SharePoint Designer’s live preview:
Figure 8 – Live preview of Conditional Formatting in action
Behind the scenes
So what is really going on here? It isn’t Magic - it is XSL. Select your row again (if it isn’t already
selected) and switch to the code view. The corresponding html for the row you selected should be
selected in the code view as well:
Figure 9 – XSL <tr> definition
The part we’re really interested in is highlighted below:
Figure 10 – Conditional Formatting applying style to a <tr>
For those of you that don’t read XSL, the attribute tag is used to add an attribute to the parent tag. In
this case it is adding a style attribute to our TR tag. The value of the style attribute is determined by the
XSL "if" statement which determines if the @Color element is equal to the text value Red.
Digging into XSL
Now that we can see what’s going on, let’s change the XSL to make it a little more useful. We have
several colors defined in our list so we probably don’t want to define a separate condition for each
color. Another option is to use the XSL "choose" tag:
Figure 11 – Updating the XSL by hand
The XSL "choose" tag allows us to configure multiple conditions and results. The downside is that we
lose the ability to see direct XSL customizations reflected in the Conditional Formatting task pane. It
does, however, allow much more complex rendering:
Figure 12 – Conditional Formatting in action
Not just pretty tables, my friend
A lot of people that are new to the Data Form Web Part use conditional formatting and custom XSL to
create dashboards with highlighted lines (etc), however, that’s not all the Data Form Web Part is good
for. Some other examples I have seen include:
• Generating customized Mobile views of SharePoint lists
• Displaying Flash (.swf) files stored in a document library
• Generating JavaScript that interacts with page objects such as Google/Live Maps, Windows
Media Player, etc
Conclusion
The ability to customize the XSL of a Data Form Web Part is what makes it such a powerful tool for
displaying data in SharePoint. In my next article we will focus on the FORM in Data Form Web Part as
we look at how to edit and save data using the Data Form Web Part.
Getting to know the Data Form Web Part (3 of 4)
Editing and Saving Data using the Data Form Web Part
In the previous article of this series we looked at how we can change the way a Data Form Web Part
displays using Conditional Formatting. One thing we haven’t looked at yet is the reason we call it the
Data Form Web Part - its ability to edit and save data.
Editing List Data
First we’ll look at adding the editing abilities to a Data Form Web Part. We’ll start by opening a Web
Part page SharePoint Designer. With the Web Part Page open, select “Manage Data Sources” from the
Data View menu:
Figure 1 – Manage Data Sources
Next, select the data source you’d like to use and choose “Show Data” from the context menu:
Figure 2 – Show Data
Select the fields you want to use for your Data Form and select “Multiple Item Form” from the “Insert
Selected Fields as” dropdown:
Figure 3 – Insert Multiple Item View
Now that we have a read-only view, click the chevron on the Data Form Web Part and select “Data View
Properties” from the Common Data View Tasks menu:
Figure 4 – Common Data View Tasks
On the Editing tab, select the options to support editing and inserting of items:
Figure 5 – Data View Properties Editing Tab
Now when you browse to the page you will have the ability to edit items inline:
Figure 6 – Using a Data Form Web Part
You also have the ability to add new items without leaving the current Web Part page:
Figure 7 – Inserting from a Data Form Web Part
You also have the ability to build a page that allows editing multiple items at once. Before we get to
that, let’s review how to add a new Web Part page to our site using SharePoint Designer.
Adding Web Part Pages to your Site
To add a new page we’ll start by right-clicking the root of our site in the Folder List and selecting New,
and then ASPX to create a new .aspx page:
Figure 8 – New ASPX Page
Next we’ll attach a master page to our new ASPX page:
Figure 9 – Attach a Master Page
Select OK to attach the site’s default Master Page to the new page:
Figure 10 – Select a Master Page
Now we can open the "branded" page and modify the PlaceHolderMain region to allow us to insert a
Web Part Zone:
Figure 11 – Override PlaceHolderMain
Now choose to insert a Web Part Zone into the PlaceHolderMain content region:
Figure 12 – Insert Web Part Zone
With our new Web Part Zone inserted we’re now ready to create add a Data Form Web Part.
Building a Custom Data Form
To add a Data Form Web Part, select Manage Data Sources from the Data View menu and bring up the
Data Source Library Task Pane:
Figure 13 – Manage Data Sources
Next we’ll select a list and select Show Data:
Figure 14 – Data Source Library Task Pane
Now we can select the fields we would like to have on our form (using control/shift to select multiple
fields). Once we have our fields selected, hit the Insert Selected Fields as dropdown:
Figure 15 – Insert DFWP
In this example we’ll select Multiple Item Form. Now we have a custom edit form for our list:
Figure 16 – Data Form Web Part
One of the powerful features of the Data Form Web Part is the control you have over how the fields
render. By selecting a DateTime field and selecting the chevron, for instance, you can modify the
DateTime formatting options to control how the date is formatted:
Figure 17 – DateTime Formatting Options
These kinds of formatting options, along with the greater control over the form’s layout make the Data
Form Web Part an extremely powerful tool.
Conclusion
As you can see, the Data Form Web Part is much more powerful than its predecessor, the Data View
Web Part. Using SharePoint Designer and the Data Form Web Part you can quickly build no-code
applications that read and write data from multiple data sources. In my next article we will take a look
at how you can trigger workflows from a Data Form Web Part.
Getting to know the Data Form Web Part (4 of 4)
Data Form Web Parts and Form Actions
In this series we’ve looked at how to create powerful displays using the Data Form Web Part and how to
interact with that data. For this article we’ll explore how to take that interaction to the next level by
triggering Workflows from a Data Form Web Part.
Introducing Form Action controls
For a quick demo of Form Action controls I’ve created a Data Form Web Part from a simple XML file:
Figure 1
This list is nice but it would be even better if we could somehow trigger a workflow to send an email to
people on the list to say “Happy Birthday.” To get started we’ll open the page in SharePoint Designer
and edit our Data View. The first change we want to make is to add a new column to our Data View:
Figure 2
Next we want to add our Form Action control. Choose “SharePoint Controls” from the Insert menu and
then select “More SharePoint Controls.”
Figure 3
This should open the Toolbox task pane and display the various SharePoint Controls that are available.
The control we are interested at the moment is the Form Action Button (although later make sure you
try out the Form Action Hyperlink):
Figure 4
Select the Form Action Button and drag it into the new column we have created. Once the control has
been added to the page a Form Actions dialog will open:
Figure 5
From this dialog you can add a number of actions. For this example we’ll skip to the most powerful
option. Select [Custom action] and choose Add. Next, click settings and a familiar dialog will launch:
Figure 6
If you have worked with SharePoint Designer workflows before you will be very familiar with this screen.
The interesting thing to note here is that we have just created a SharePoint Designer workflow that is
NOT associated to a SharePoint list or library.
Now that we’ve given that some thought, let’s get back to the task at hand and actually make our
workflow do something! From the actions dropdown select “Send an email.” Next click “this message”
to configure your email:
Figure 7
For now we’ll hard-code the form fields and press OK to save the changes. Next click Finish to save your
workflow changes and OK to save your Form Action changes. Now preview the changes in the browser
and test your form by clicking on the Form Action button:
Figure 8
If you do not receive the email and believe your workflow was configured properly you may want to
check the workflow history list for any errors. The workflow history list is a hidden list by default so you
have to manually type in the path: http://site/web/Lists/Workflow%20History
In my case, outgoing e-mail settings for the server have not been configured so I receive an error
message in the workflow history list which is pretty helpful:
Figure 9
Well, even if email was configured properly we wouldn’t want to hard-code the email address field since
we have a perfectly good value saved in the XML file. Back in SharePoint Designer let’s update our Data
View to allow us to pass the current record’s email value into our workflow. To do this, we’ll need to
change the format-as option of the email field by clicking the field’s chevron:
Figure 10
Switching the field to display as a Label turns what was rendered as just text into an ASP.NET Label
control. Now that our Data View has an ASP.NET form control available, let’s edit our Workflow. There
are two ways to update our Workflow:
1) Right-click on the Form Action button and select Form Actions to re-open the Form Actions dialog:
Figure 11
2) Expand the Workflows folder and open the .xoml file of the matching Workflow (Custom Form Action
1, in this case):
Figure 12
When you are working with form fields I’ve found that it is usually best to use method #1 mentioned
above. Once you are back in the Workflow Designer, click on your email action to configure your
settings. Clear out the To: field and click on the address book icon to launch the Select Users dialog.
From the Select Users Dialog, choose Workflow lookup:
Figure 13
From the Define Workflow Lookup dialog, select Form Fields as your source and you should see a form
field that matches our email column:
Figure 14
Save your changes and return to the Workflow Designer screen. Before we leave here, let’s make sure
we can see who we’re sending our message to by adding an additional action to log the same field to
the history list:
Figure 15
Save your changes and test out your form again. If you go out to your Workflow History list you should
see an entry that logs the email address your message would have been sent to as well as any errors
that may have occurred:
Figure 16
Working with List Items in Form Action Workflows
Our first example showed how easy it is to create workflows that aren’t associated with any SharePoint
lists. That is a pretty powerful option but really since we’re in SharePoint it would be nice to know how
to do something similar with list data. For our last example we’ll look at how to add a form action
button that marks an item in a task as complete AND puts its % complete field at 100%.
For this example I’ve created a simple tasks list and a Data View showing my tasks:
Figure 17
Our first step is to make sure we can uniquely identify our task in a workflow. Ideally we would key off
of the list item’s ID but unfortunately that is more difficult than it should be in the current version of
SharePoint Designer. In this scenario we can assume that our Title fields are unique so we will start by
converting that field into an ASP.NET Label:
Figure 18
Next we’ll create a new column and add a Form Action Hyperlink control to the column. By default the
form action has a “Navigate to page” action defined. First modify that action and configure the target
page to be the current form page:
Figure 19
We do this to get around a little timing issue that happens when we update items using Form Action
Workflows. Speaking of updates, next add a [Custom action] and move it to the top of the Current
Actions list. Then click Settings to configure the Workflow. From the Actions dropdown, select Update
List Item and click on the action to configure it. On the Update List Item screen configure the list we
want to configure and add the fields and the values we want to set. Finally, configure the “Find the List
Item” section to match the Title field to the title control on the corresponding row we clicked on.
Figure 20
When you choose OK you will be warned that the criteria we set to find the appropriate list item to
update may not be unique. Again, for this scenario we’re assuming titles will be unique so we can select
Yes. Save and preview your changes and you should see your Form Action Hyperlink:
Figure 21
After clicking on the Form Action Hyperlink for Article 4 you can see that my % Complete is updated as
well as my status:
Figure 22
Next you could certainly update the Data View so it conditionally displays the Form Action Hyperlink
only on rows where the tasks are not marked complete. You could also extend the Form Action
Workflow so an email notification is sent with a customized message to both the creator of the task and
the “Assigned To” user.
Conclusion
Form Actions and Form Action Workflows are powerful extensions of the Data Form Web Part. Using
the lessons learned in this series you can now create powerful displays of data, work with external data
sources, and create dynamic workflows.
