Repeating sections in Nintex Forms are really powerful. To ensure that you’re getting the most out of them and to make your form development easier, here are some best practices to ensure that your work with repeating sections in Nintex Forms is great.
Name Your Controls Well
When a control is added to Nintex Forms, regardless if it's in a repeating table or not, by default it does not have a name. No matter if it's bound to a field, you have all these controls sans name. Be sure to spend some time to give your controls meaningful names because names are easier to work with instead of GUIDs. This will save you some headache if you have workflow integration and/or nested panels.
Nested Panels and Repeating Sections
Remember how I said to name your controls well? You better be sure that you name your panels and repeating sections well too.
The Hardest Button to Button (is an HTML Button)
If you're looking to use a button control in a repeating section, you’ll quickly find that you can’t. A workaround is to add a label control to the repeating section, create the button using HTML, edit the HTML source for the label control, and you got yourself a button.
Are you using a workflow with your form? If yes, then keep on reading this section. If no, then that concludes this blog post for you.
Log to history list: That last paragraph was such a conditional statement in a workflow
Dump that XML
You'll find out hard and fast that you cannot connect controls nested in a repeating section to fields in your list. A Repeating section can only be connected to a multiple lines of text field. All of the repeating elements in the form are dumped to this single field. If you have nested panels or repeating sections within your parent repeating section, they'll be dumped to the single field too. This means your workflow needs to do some XML parsing.
Parse that XML
The assumption I'm making in this section is that you're looping through the rows in your repeating section. If I've assumed correctly, keep reading. If I've assumed incorrectly, well you know how the saying goes.
- Query the list and get the XML Dump field and store it in a multiple line of text variable MLOT_XMLDump.
- Use a Query XML action to retrieve the Item node from the XML dump and store it in a collection variable named Collection_Item.
- Add a For each action that'll loop through Collection_Item and stores the result in a multiple line of text variable named MLOT_Item.
- In the loop, add a Query XML action. Have the variable MLOT_Item set up as the XML source. Add as many outputs as you need. Here is where the named fields come full circle. If you didn't have named fields, you'd be dealing with some nasty GUIDs. Instead of pulling your hair out, you can keep your hair because you, dutiful blog reader, named your fields nicely.
In the screen below, you can see that the controls Notes, Quantity, and others are easily retrieved. All I need to do is set the Xpath to be /Item/ControlName. If you have a repeating section within your repeating section, store the result in a multiple line of text variable.
- From here, you can do as you please with the data.
Parse that XML
No this section's title isn't a typo. If you have a repeating section within your repeating section, you'll need to parse that XML on its own. In the last section, I told you that when parsing the XML dump, you'll need to store any nested repeating sections in a multiple lines of text variable.
To make that repeating section consumable and not be raw XML, use a Set Variable action after the XML action in the previous section. Set the multiple line of text variable to equal fn-XmlDecode(your MLOT variable).
After the variable has been XML decoded, add a Query XML and repeat step 4 in the previous section.
If you're repeating section's repeating sections have repeating sections, first of all woah. Secondly, you'd need to repeat this for each nested repeating sections.