Professional Documents
Culture Documents
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: Email: Bio: Raymond Mitchell kid@iwkid.com 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. http://www.iwkid.com http://www.iwkid.com/blog 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.
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 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. 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
Parameters XSL
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:
To insert a Data Form Web Part, first select a Web Part Zone and choose Insert Data View from the Data View menu:
A Data Source Library Task Pane will appear displaying the available data sources for the current site:
In this example well select an existing SharePoint List called Stuff and choose the Show Data option:
The Data Source Details will appear in the Task Pane displaying the fields from our 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:
Next you will want to save your page. When you save, you will receive a prompt:
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:
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:
In the Web Part Task Pane you will see two properties you can edit:
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:
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 Ive 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.
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:
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, lets 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:
In this example well add a Color parameter that reads from the Query String:
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:
Now well configure our DFWP to filter using our new parameter:
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:
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:
Now if we view our page in the browser and pass in a parameter we can see that our filter has been applied:
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.
You should then see the Conditional Formatting task pane and usually one existing condition:
Note that the create button is disabled because we have not selected an HTML element to apply any conditional formatting to. Lets create a new Conditional Formatting rule that will change a table rows background color based on the color selected in the list. First, we need to select a row (which isnt 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:
Once you have selected a row you should also see a selected <tr> in 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...
Next we need to define when the formatting will occur by defining the condition. In this case well apply formatting when the Color field is set to Red:
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, well just set the background color to red:
Once we press OK, our conditional formatting is revealed using SharePoint Designers live preview:
Behind the scenes So what is really going on here? It isnt Magic - it is XSL. Select your row again (if it isnt 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:
For those of you that dont 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 whats going on, lets change the XSL to make it a little more useful. We have several colors defined in our list so we probably dont want to define a separate condition for each color. Another option is to use the XSL "choose" tag:
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:
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, thats 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.
Next, select the data source youd like to use and choose Show Data from the context menu:
Select the fields you want to use for your Data Form and select Multiple Item Form from the Insert Selected Fields as dropdown:
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:
On the Editing tab, select the options to support editing and inserting of items:
Now when you browse to the page you will have the ability to edit items inline:
You also have the ability to add new items without leaving the current Web Part page:
You also have the ability to build a page that allows editing multiple items at once. Before we get to that, lets review how to add a new Web Part page to our site using SharePoint Designer.
Select OK to attach the sites default Master Page to the new page:
Now we can open the "branded" page and modify the PlaceHolderMain region to allow us to insert a Web Part Zone:
Now choose to insert a Web Part Zone into the PlaceHolderMain content region:
With our new Web Part Zone inserted were now ready to create add a Data Form Web Part.
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:
In this example well select Multiple Item Form. Now we have a custom edit form for our list:
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:
These kinds of formatting options, along with the greater control over the forms 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.
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 well 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 well 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 weve given that some thought, lets 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 well 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 wouldnt want to hard-code the email address field since we have a perfectly good value saved in the XML file. Back in SharePoint Designer lets update our Data View to allow us to pass the current records email value into our workflow. To do this, well need to change the format-as option of the email field by clicking the fields 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, lets 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 Ive 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, lets make sure we can see who were 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
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 items 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 well 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 were 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.