Getting to Know the Data Form Web Part

Getting to know the Data Form Web Part

Series Information

This four-part-series will provide an overview of the Data Form Web Part. It assumes general familiarity

with SharePoint 2007 and SharePoint Designer.

Author Information

Name: Raymond Mitchell

Email: [email protected]

Bio: Raymond Mitchell is an Information Worker Consultant at Inetium and a frequent

speaker at the Minnesota SharePoint User Group. He also blogs under the alias IWKID

on Information Worker technologies including SharePoint and Office development.

Website: http://www.iwkid.com

Blog: http://www.iwkid.com/blog

Company: Inetium

Bloomington, Minnesota

Inetium, an award-winning Gold Certified Microsoft Partner, provides consulting

services in the areas of business productivity, CRM, networking and infrastructure,

custom application development, web strategies and real estate technology solutions.

Inetium, www.inetium.com, hosts the Minnesota SharePoint User Group each month

which provides educational seminars on SharePoint; more information can be found at

www.sharepointmn.com.

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.


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.


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.


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.

Documents

Getting to Know the Data Form Web Part