SharePoint: Extended DVWP-Part 2: using more form fields in a Workflow

Document directory

• Get control

This article is part of the extended DVWP series. We have discussed how to create a workflow triggered by a form operation. In the previous article, we found that more information except form fields can be passed to the workflow, other workflow variables can be passed, and these variables can be used in the workflow.

Although the form fields are automatically displayed in the workflow, you may have noticed that sometimes not all fields appear.

Why?

Get control

In fact, the question should be expressed as follows: what essentially causes this phenomenon? The reason is that only a specific control is regarded as a form field and passed to the workflow:

1. SharePoint: FieldControl

2. ASP: Label

3. ASP: TextBox

4. ASP: CheckBox

5. ASP: RadioButton

A field that cannot be edited is not displayed as a control in DVWP by default.

For example, a notification list contains some uneditable fields. When we include it in DVWP and create an edit template, these fields are displayed in the form of the xsl: value-of Tag:

1. In the design view, click the angle brackets icon on the right (displayed when you move the cursor over this field ). Change "format as" to "label ".

2. The following changes occur in the Code view:

From:

<td class="ms-vb">        <xsl:value-of select="@ContentType" /></td>

To:

<Td class = "ms-vb"> <asp: Label runat = "server" id = "ff2 {$ Pos}" text = "{@ ContentType}" _ designer: bind = "{... code ...} "/> </td>

Now, let's take a look at the form field in the workflow. The content type (@ ContentType) already appears in it:

Next time: Want to access more data: Do you want to get the data modified by the user before saving it? In the following extended DVWP series, we will add more form fields to this page.

 

References

SharePoint: Extending the DVWP-Part 11: Getting More Form Fields to the Workflow