Recently I ‘inherited’ an InfoPath form to clean up and expand the capabilities of. The project is fun and interesting, so I thought it would be a quick and easy exercise. Unfortunately, when I opened the form, to my horror, none of the fields were named or organized in any way. This isn’t a big deal on a form with a dozen fields or less, but this bad boy had 236 fields, named field1, field2, field3 … all the way to field 236. Worst still, the fields weren’t in any order in the fields window; checkboxes at the start of the form were at the bottom, and text boxes at the bottom were somewhere in the middle. It was literally impossible to tell what field was what.
This happens easily and regularly, because when you pop a field into InfoPath, it’s automatically assigned a name of ‘field#” (where # is the number of that field). When you’re quickly throwing together a form, it’s easy after a few dozen clicks to have an unmanageable, unorganized number of fields.
Referring to these fields in InfoPath by ‘field#’ is not best practice, and frankly it makes your fellow InfoPath developers weep before bed every night – oh, and wastes tons of time trying to figure out what field is what. For example, good luck building rule sets with conditions like:
field23 is equal to field94 AND field 12 is not empty AND field104 is greater than field 197.
This. Makes. No. Sense.
There is a better way: The 6 rules below will get you well on your way to organizing and bringing sanity to an insane InfoPath world.
How To Organize InfoPath Fields
1. Order
Keep your sections and fields in the order they’re displayed on the form. Moving fields around can be a pain, but it makes the field list more logical and easy to navigate. Tip: It’s a lot easier to move fields around when they’re inside of logical sections (see ‘Use Sections’ below).
2. CamelCase
Use CamelCase to name sections and fields to make the names more legible. Since InfoPath does not allow spaces in field and section names, using CamelCase can make it much easier to distinguish distinct words for field names. For example: producttype becomes ProductType.
3. Use Sections
Sections aren’t just for conditional displays. You can create them in the Fields window to separate logical groups of controls, or even blocks of text. If your form has logical sections or separation of content, use groups to define those sections in the field list.
4. Descriptive Names
In programming, Hungarian Notation is a naming convention used to describe variables and functions. I use a similar system in InfoPath to help describe the type of field I’m using, so I can quickly know what kind of control it is, and by extension the type of information being captured. For example, if I’m using a text box, I prefix the name with ‘txt’. So FirstName becomes txtFirstName.
Field Name Prefixes
| Field Type | Prefix | Example |
|---|---|---|
| Text Box | txt | txtFirstName |
| Rich Text | rtxt | rtxtComments |
| Drop Down List | dd | ddPantSize |
| Combo Box | cb | cbShirtSize |
| Check Box | chk | chkNeedsBelt |
| Option Button | rdo | rdoShoeType |
| Date Picker | dte | dteBirthday |
| Date and Time Picker | dtet | dtetPickup |
| Multiple Selections | ms | msPatternType |
| List Box | lb | lbShoes |
| Bulletted List | bl | blBelts |
| Numbered List | nl | blChoices |
| Plain List | pl | plOtherSelection |
| Person/ Group Picker | ppl | pplSalesAgent |
| External Item Picker | exl | exlProduct |
Object Name Prefixes
| Object Type | Prefix | Example |
|---|---|---|
| Button | btn | btnSubmit |
| Picture Button | pbtn | pbtnHouse |
| Calculated Value | n/a | n/a |
| File Attachment | att | attDocument |
| Picture | pic | picFields |
| Hyperlink | www | wwwGoogle |
Section Names
I tend not to append the section type with a prefix, because it’s more important to give it a descriptive name, and then name any fields inside with a prefixed, descriptive name. After all a section is a group of data, not the data itself.
5. Give Rules Action Names
I know, Rules are technically not InfoPath fields, but all the same you should always give them a good, descriptive name. Much like fields, by default InfoPath gives the rule a name like ‘Rule#’. I use a descriptive name that includes a verb, which describes the action the rule is actually doing.
A common rule is to make a section hidden if another field does not equal a particular value, in this example, I name that rule ‘MakeHidden’. Similarly, if a field has a rule that makes that field required based on another field’s value, I’ll name that rule ‘MakeRequired’.
6. Consistency
Rules are only as good as how consistently they’re applied. I know it’s more work to name, order, and section everything properly, but trust me, it will save you (and others) time and effort in the future. Apply the above rules across an entire form every time you create a form – and when you can glean what the form is and what it does in 5 seconds flat, pat yourself on the back.
Closing
InfoPath makes it so easy to bang out a form in just a few clicks, but the cost of this is lack of enforcing any kind of structure or rules to that will help you and others in the future to remember how the form is structured and what it’s actually doing.
Ordering your fields, using CamelCase, Sections, Descriptive Names, Rule Names, and Consistency are 6 quick and easy ways to bring some sanity back to your forms, and save you and your coworkers a significant amount of blood, sweat, and tears.
