Using standard field extensions when naming your fields

There are a number of reasons why using standard field extensions when naming your fields is a good idea.

Generally speaking, it will make automating your Templates and designing your Forms much easier, as you will clearly know the type of Field you are dealing with in each case.

It also allows you to re-use (to a certain extent) the prefix for the field across fields of different types. For example you may have a Yes/No Radio which asks: 'Do you want to add any further details?' called Further_Details_yn, and a multi-line textbox asking the user to 'Input further details here:' with the field name Further_Details_txtml. When creating the rule to show Further_Details_txtml when Further_Details_yn = 'true' not only will the two fields be easy to find in the Rules Editor, but if you are reviewing the rule, the field names themselves will be helping to clarify what the rule is actually doing.

The standard extensions recognised by our platform are as follows:

Textbox: Field_Name_txt 

Multi-line Textbox: Field_Name_txtml

Yes/No Radio: Field_Name_yn

Dropdown List: Field_Name_cho

Radio Group: Field_Name_rdo

Checkbox or Checkbox Group: Field_Name_chk

Number: Field_Name_num

Email: Field_Name_eml

Date: Field_Name_dt

Repeat Section: Field_Name_rpt

Section or Panel: Field_Name_sec

Script Field (often a hidden text field, where a value is calculated or assembled from other fields): Field_Name_scr

DataSource Field (a hidden text field with a key to a record which will pull in data): Field_Name_source