Dataform Field Naming Standards
General guidelines
Care should be taken when first creating a dataform, as the underlying database table is generated from the name at the time of creation. For example, if a dataform is added with the name Certs, a database table gen_Certs is generated, where gen_CertificateOfInsurance would have been preferable.
So, when adding a dataform, think about what you would want the database table to be named, then, after it is created, the form name can be changed to something more human readable or industry jargonized, without having an effect on the underlying database table.
Field names are in Pascal Case
Pascal Case is a field naming convention whereby field names are created by concatenating capitalized words. Extraneous spaces are also removed. For example: FirstName., which means that field names are created by concatenating capitalized words. For example:
-
FirstName
-
GrossPayroll
-
MinAdminPerAccount
Prefixes are all lowercase. For example:
-
luState
-
fsOrganizationInformation
When using the ID suffix, both letters should be uppercase. For example:
-
fkEmployeeID
-
fkUserID
Note:
-
Always examine the automatically generated field name after typing in the label to make sure they are Pascal Case and have the appropriate prefix and suffix. DO NOT leave a field with an excessively long name because it was auto-generated. For example, a field with the label “Are union workers or employees under collective bargaining agreements employed?” should not be left as the automatically generated name. In this case, it can be appropriately shortened to luEECoveredUnderCBAEmployed.
-
When editing field names, we do not recommend removing any auto-generated prefixes or suffixes as these reflect the selected datatype.
-
You can edit any field name up to the point of saving the dataform field record. Once saved, Field Name becomes dimmed and inaccessible.
Datatype guidelines
When you add a dataform field, the field label is stripped of its spaces and special characters and used as the Field Name. The appropriate prefixes and suffixes are automatically added based on the selected datatype.
Prefix fk and suffix ID
Any fields that store an ID to another entity should have the prefix fk and the suffix of "ID" in all capital letters.
Example: fkEmployeeID
A few examples of foreign key datatypes:
| • | Any of the Organization or Contact datatypes |
| • | Any of the User datatypes |
| • | Parent Form |
| • | Comp Code Suggest |
| • | Employee Type Ahead |
| • | Project Type Selector |
| • | Role Selectors |
| • | Workspace Selectors |
Prefix lu
Lookup (core) fields have the lu prefix.
Example: luStatus
Prefix mlu
Lookup – Multiple (core) fields have the mlu prefix.
Example:
| • | mluCommissionMethod |
| • | mluCertifications |
Prefix chk
Checkboxes store a Boolean value (True/False, Yes/No) and start with a chk prefix.
Example:
| • | chkBrokerSubmitted |
| • | chkCustomPayroll |
| • | chkCreateWorkspace |
Note: Prior to ClientSpace Release R153, we recommended that you manually add an Is, Has, or Can prefix to checkbox fields, depending on what sounded more correct. Now, that chk auto-populates as the prefix, this step is no longer necessary.
Prefix Date
Date fields begin with the word Date.
Example: DateReported
Prefix fs
Field Sets have the prefix fs.
Example: fsContactInformation
Prefix sf
Secure attachments have the prefix sf.
Example: sfLossHistory
Other datatypes
All other datatypes stick to the Pascal Case convention but will not have a prefix or suffix.
Examples:
|
(Decimal) | |||
|
(Integer) | |||
|
(TextArea or Log) | |||
|
(Text) | |||
|
(Email) |