Fields are used to populate forms and gather data about the various Records the trellispark platform uses. You can create and define fields on the Data Model tab of any Concept or Portal form.
Like forms, fields share several required attributes to be displayed and have different requirements based on the field type.
Below is an example of the basic field definition page:
Every field will need to have its Tab, Grid Row, Grid Row Span, Grid Column, Grid Column Span, and Layer defined to determine where the field will be displayed in the form. How fields are laid out on a form is discussed elsewhere in this article.
The Layer field is used to layer fields in the same position. For example, in the image above that show an example of a field definition most of the fields are within a shaded area. That shaded area is actually a field that spans the area with styling applied that’s on a lower layer than the other fields so it’s rendered behind the other fields.
Each field will also need a human readable Label to be displayed above the form, which can be shown or suppressed depending on user preference.
The Field Type determines what other information is necessary to create a functioning field. Selecting a field type will make additional fields appear on the field builder, some of which may be required to create a functioning field.
IMPORTANT NOTE: Not all field types are available on each form type. For example, the Calculated field type is available on the form type Concept but not on a Wizard.
A Purpose should be set to describe what this field is recording and how it can be used. Descriptions can appear above or below the field to help the users understand what kind of information they should be entering or using within this field.
Basic field types that simply save a value will include a field for an empty message and a tool tip which would display above the field to help users fill it in.
Most field types except for child lists and read only fields will require an XML element name to identify the field within the form XML, and an indicator to show if this field will be required to fill in before the form can be saved.
Some fields types have an Auto Postback option. If enabled the page will refresh each time the field is updated. Fields that have auto postback enabled are indicated with specific styling.
As you can see there’s a subtle green outline around the field. When the field is modified the page will begin a refresh and the styling will change to a red outline. The red is to indicate the page is being refreshed and you should wait until it’s green again before making more changes.
These styles can be adjusted in the app.css file.
Learn More Tab
The learn more tab contains a Learn More field, when populated a help icon will be displayed next to the fields label and when selected will display a popup window with the content you enter inside it. This gives you a way to provide additional details on how to use a field without cluttering the user experience with long descriptions.
The styling tabs contains the following fields:
- Field Style
- Label Style
- Description Style
- Control Style
These fields allow you to enter raw CSS to apply styling to specific area of the field. Styles applied here will take priority over any theme or stylesheets being used.
Field permissions are independently set at this level but can also be controlled by the form permissions if no individual field permissions are defined. Fields can also be designated as a lookup field, which will cause this field to be added as a row in the lookup table to be searched upon. There are also fields to determine where the field should be saved, on the Record or in the session state if it will be relevant to tasks the user will be performing in future.
This tab allows you to add language translations for the field.