Generic Contact Form

Demo of features, customizations and reusable schemas (multifield, drag & drop and JSON)

Mandatory Email address field for confirmation emails
Custom content in designated slots
Field content: descriptions, hints, placeholders, etc
Injecting dymanic data into messages and emails
Configuring the browser's autocomplete helper
Input sizes for individual fields
Other useful examples

1. Mandatory Email address field for confirmation emails

A field with the name emailAddress is required if you want to send a confirmation email to the user. This field should be set as an email type and use email validations.

Add new item in Schema multifield
Set type to "Field"
Set name to "emailAddress" and label to "Email address"
Open the content drawer
Set size to "full-width" and input type to "email"
Open validations drawer
Add type "required" with a value of "true"
Add type "email" with a value of "true"
Change the error messages as needed

Drag a "Generic Contact Form - Field" component into the slot
Enter content and options in the same way that you would for a multifield schema

{
  "form": [
    {
      "type": "field",
      "name": "emailAddress",
      "label": "Email address",
      "size": "full-width",
      "inputType": "email",
      "validations": [
        {
          "type": "required",
          "value": "true"
        },
        {
          "type": "email",
          "value": "true"
        }
      ]
    }
  ]
}

2. Custom content in designated slots

Regardless of schema type, content can be added through the various components slots using the named WYSIWYGs in the component dialog.

{text} slot - can be used to add a title and description before a form that will be hidden upon submission. Use a separate content block above if that content should remain visible.
{required-fields-message} slot - can be used to override the "all fields are required unless marked optional" content that appears above inputs. If you're wondering why this content can't just be in the {text} slot, click the submit button without adding an email, to trigger the form error.
{footer} slot - great for placing disclaimer, legal or security information. Highly recommend setting the "small" text style.

This is the {text} slot.

3. Field content: descriptions, hints, placeholders, etc

A field must have a label which identifies what the field is asking for, but may also contain other pieces of information to assist a user with providing a value.

Descriptions are used to provide additional context about what information a field is asking for. Important information that is too "wordy" for the form label should be included here.

Hints provide the user with clues about how to provide the value. No important information should be included here.

Placeholders show an example value in the field only before a user starts type, but please be warned that in more cases placeholders are not accessible! If a placeholder is truly required, please consult with one of our accessibility experts.

4. Injecting dymanic data into messages and emails

If you're looking to provider feedback to the user, relying on data they submitted (e.g. greeting them by their name), you can do that with a special syntax. By using double square brackets [[]] as well as a field name (value from the name field in the dialog), this component will automagically inject the requested content.

Example confirmation message:

Your submission has been sent to [[emailAddress]]

Example:

Thank you [[firstName]] [[lastName]], we will reach out to you shortly

Example:

Thank you [[firstName]] [[lastName]], we will reach out to you shortly

Example:

Thank you [[firstName]] [[lastName]], we will reach out to you shortly

5. Configuring the browser's autocomplete helper

Most modern browsers contain a helper tool that autofills inputs for the user by using previously used or saved values. By default, the browser will attempt to determine what information a field is asking for by scanning the label and type.

In order to provide users with a more reliable experience, we can manually set the autocomplete value since browser detection isn't always accurate. An autocomplete select is available in the dialog under the content drawer to change the value. Please note that the values are pre-determined by browser makers. If none of the available values match the data needed, please set the value to "off".

A few common examples have been provided below:

Open the "Content" drawer within a field
Click on the "Autocomplete" dropdown and select a value
Test in your browser to ensure that the browser is autocompleting the correct data

Reference:

https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#attr-fe-autocomplete

Open the "Content" drawer within a field
Click on the "Autocomplete" dropdown and select a value
Test in your browser to ensure that the browser is autocompleting the correct data

Reference:

https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#attr-fe-autocomplete

Add a key "autocomplete" to a field object with a standard value (see reference)

  
    {
        "name: "firstName",
        "label: "First name",
        "autocomplete": "given-name"
    }

Reference:

https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#attr-fe-autocomplete

6. Input sizes for individual fields

There are 4 standard input sizes to choose from, with 2 special sizes reserved for field groups. These are the standard sizes.

7. Other useful examples

These examples show how to achieve various things with the Generic Contact Form component.

First and last name in a field group

Choose a field group and add two fields, choosing one of the 2 special fieldgroup sizes:

"Auto" for evenly sized columns (3 items would be 33.3333%, 4 would be 25%)
"Pairs" for groups of two (50% width regardless of # of items)

Full name (first, middle & last) in a fieldset

Choose a fieldset and add two or more fields, choosing one of the 2 special fieldgroup/fieldset sizes:

"Auto" for evenly sized columns (3 items would be 33.3333%, 4 would be 25%)
"Pairs" for groups of two (50% width regardless of # of items)

If auto is paired with one of the 4 basic sizes, then the input will take up the remaining space. In the exampke below, middle initial uses the short size, while the 2 auto inputs take up the remaining space (divided evenly between them).

Custom CTA content and config

You can change the button style and label in the design options tab

Number fields and min/max validation

Example number range (0-100) using a number input

Options

Set input type to number
Set a "Min" value
Set a "Max" value

Validations

Use minValue to set the floor for valid numbers (should match the "Min" value from options)
Use maxValue to set the ceiling for valid numbers (should match the "Max" value from options)

Affixed formatted number fields

These inputs are built on top of the number type and provide special formatting, along with an affix (prefix or suffix symbol). Please use the same options and validations that are used by number inputs, as these are really just "special number inputs" under the hood.

Masked input types

These inputs provide special placeholder and lock in user input to a specific format. It is recommended that you use the default size for these fields. Validation is not required, other then setting "required".

Phone number with extension

This example uses a field group with a phone number input (size=auto) and a text input for the extension (size=short)

Textarea (multi-line text input)

These are very useful for longform user content and may be validated only by content length. You may want to consider setting autocomplete to "off"

Datepicker field

This input type is composed of three inputs (month, day and year) that can be rearranged.

The input-format option can be used to change the order of of the monday, day and year fields

Select and options

A dropdown-like input with options for the user to select from. Options must be set in the schema

Provinces fields

A select with Canadian provinces and territories option for the user to select from.

By default, only provinces are listed as options. A checkbox is available in the dialog to include territories.

If you need pre-formatted values, there is an option called "format" with 4 options to choose from:

None (default) - internal value used by developers (eg. "on" for Ontario)
Full name - name of the province as it appears in the option's label (eg. "Ontario" for Ontario)
Alphacode - the internationally approved alpha code from Canada Post (eg. "ON" for Ontario)
Abbreviation - the standard abbreviations (eg. "Ont." for Ontario)

More information about the standard formats

Checkbox groups

A group of options where multiple options can be selected

Each option requires a name (id) and a label

Please note that checkbox groups come with a built-in fieldset

Radio groups

A group of options where only one option can be selected

Each option requires a name (id) and a label

Please note that radio groups come with a built-in fieldset

Conditionally displayed fields

For when you need to dynamically hide or show a field based on the value of another field

All conditions have three parts:

field - the exact name of another field which should be watched
operator - the type of matching pattern that should be watched for (more details below)
value - the value of the field being watched

There are 3 types of operators to should from, depending on your use case

EQUALS - checks if the value is an exact match
NOTEQUALS - checks if the value is anything other than an exact match
INCLUDES - checks if the value is included within a list or long label

For example, if you have a select named "reason-for-contact" with an "other field", you would need to create a separate textarea field with the following condition

field = "reason-for-contact"
operator = "EQUALS"
value = "other"

JSON schemas

Due to an unfortunate limitation with AEM, overly complex forms may require use of the "JSON Schema" field, as MultiFields have a limit on how much data can exist. While there are no differences with the rendered component, the schema will have to be authored manually using the following syntax:

The Form

First up, we must declare an object which hosts the entire form.


{
  "form": [

  ]
}

Fields

Each field must be a new object, with type=field declared, followed the normal keys


{
  "form": [
    { "type": "field", "name": "firstName", "label": "label" }
  ]
}

Fieldgroups

Each fieldgroup must be a new object, with the primary key "fieldgroup" being an array of field objects


{
  "form": [
    {
      "fieldgroup": [
        {
          "name": "firstName",
          "inputType": "text",
          "label": "First name"
        },
        {
          "name": "lastName",
          "inputType": "text",
          "label": "Last name"
        }
      ]
    }
  ]
}

Fieldsets

Each fieldset must be a new object, with fieldset being an array objects. The first contains the legend. The second is empty. The third contains an array of fields. The fourth allows for adding html attributes.


{
  "form": [
    {
      "fieldset": [
        {
          "legend": "This is a legend in a fieldset"
        },
        {},
        {
          "fieldgroup": [
            {
              "label": "Address",
              "name": "address",
              "inputType": "text"
            },
            {
              "label": "City",
              "name": "city",
              "inputType": "text"
            }
          ]
        },
        {
          "htmlAttributes": []
        }
      ]
    }
  ]
}

A note about styling and layout

The Generic Contact Form component does not have any built in spacing, background options, container sizing, etc.

It is an intentional decision that layout and structure should be handled by a parent component that wraps this component. It is recommended that Container Block be used as a wrapper for most use cases. Columns and Postcard may also be suitable.

This example uses a container block.

Another layout example

This time, the form is within a columns component, which is within a postcard component.

Componentception!

QA test forms

The forms below can be used to send test emails to the FET QA team.

The email address you enter will be used for confirmation emails
Submission emails will always be sent to the FET QA team

Common fields

Specialty fields

Fields with options

Email Service Endpoint URL

Add new item in Schema multifield
Set type to "Field"
Set name to "emailAddress" and label to "Email address"
Under the Email Tab, add the values for "Email Service Endpoint URL" and "Email recipient"

Use Native Post

Under Developer tab, check the "Use Native Post" to use HTML native form posting instead of the JavaScript default.

Table of contents

1. Mandatory Email address field for confirmation emails

2. Custom content in designated slots

3. Field content: descriptions, hints, placeholders, etc

4. Injecting dymanic data into messages and emails

Example confirmation message:

Example:

Example:

Example:

5. Configuring the browser's autocomplete helper

6. Input sizes for individual fields

7. Other useful examples

First and last name in a field group

Full name (first, middle & last) in a fieldset

Custom CTA content and config

Number fields and min/max validation

Options

Validations

Affixed formatted number fields

Masked input types

Phone number with extension

Textarea (multi-line text input)

Datepicker field

Select and options

Provinces fields

Checkbox groups

Radio groups

JSON schemas

The Form

Fields

Fieldgroups

Fieldsets

A note about styling and layout

Another layout example

QA test forms

Email Service Endpoint URL

Use Native Post