Where field definitions live, the properties every field shares, and when to use a group or a fieldset.
A custom field definition tells Marketpath CMS what to ask an editor for and how to store the answer. Definitions live in four places:
• A template's custom fields, filled in on every page built from that template.
• A datastore's schema, filled in on every item in that datastore.
• Custom site settings, filled in once for the whole site.
• A form, whose fields a visitor fills in.
The first three are data definitions and accept one set of Types; a form accepts a different set, and some Types serve both. Each Type page says where the Type is valid.
Every definition is an object with a Type. These properties apply to every field, whatever its Type:
• FieldID: the name a template reads the value by. Use letters, digits, hyphens, and underscores only. Every field needs one except a group. Where Custom Fields Belong covers which template should define it and where it must be unique.
• Label: the name shown to the editor.
• Subtext: help text shown with the field.
• Condition: at most one, deciding whether the editor is asked for the field at all. Field Conditions lists every condition.
• Classname: a CSS class added to the control when the field renders on a form.
Fields that store a value also accept these:
• IsRequired: the value may not be left empty. RequiredMessage replaces the default message, "Value is required".
• DefaultValue: the value a new field starts with.
• Validators: a list of rules the saved value must satisfy, on the Types that carry them. Field Validators lists every validator and the Types it applies to.
• IsReadonly and MapToAttribute: for form controls. IsReadonly shows the value without letting the visitor change it, in the browser only, and MapToAttribute copies a submitted value to a contact attribute.
Every other property belongs to particular Types, such as Options on a select or the filters on a picker. Each Type page lists the properties it accepts.
Groups and fieldsets both hold other fields, and they are easy to confuse:
• A group arranges fields for the editor and stores nothing. It needs at least one field inside it, and those fields sit directly on the object as if the group were not there. A group can be collapsible, and can start collapsed.
• A fieldset is a single field whose value is made of the fields inside it. It needs a FieldID, its child FieldIDs only need to be unique within it, and a fieldset inside another fieldset stays nested. With AllowMultiple the fieldset stores a list of rows, and a definition that leaves AllowMultiple out repeats as well; set it to false for exactly one. Noun names one row on the add button, InitCollapsed starts rows collapsed, and the minitems and maxitems validators bound how many rows an editor may add.
Reach for a group to tidy a long editing form, and for a fieldset when several values belong together or repeat. Field Values shows how a template reads each shape.