Form behaviour in various form states is the mechanism by which form inputs are hidden after a successful form submission and for building multi-step forms.
Most Form Reform blocks have a Behaviour tab in the block edit dialogue with sections for Form State and Visibility Rules.
Form State provides a list of the states a form can be in and what the block does in those states. The actual list is derived from the alert classes available for messages and a numeric list of steps from 1..5 (the number of states is configurable). See Form State.
Visibility Rules (this page) are applied in browser as form values change and are for use on a much smaller scale. A form control can be toggled between shown+enabled and hidden+disabled according to these rules. For example, show this form control when another control has a value of "Yes".
This page is about Visibility Rules. For most form control block types, Visibility Rules can be found in the Behaviour tab of the block edit dialogue, scroll down from the Form State checkboxes.
Before adding visibility rules to a form block:
Rules will usually refer to another form input A, and compare that to value B. For example, to show a form control when a checkbox named more_info_provided is checked, and has the value more_info.
You can refer to other form controls using the {{form:key}} format used in the form handler pipeline, but take care, only a very limited subset of {{data_values}} are supported. The available {{category:key}} are tagged [JS] in the documentation.
Example - check and uncheck this checkbox
For the above example, a simple visibility rule is configured in the Behaviour tab of the Text Area input block, so that it shows when the checkbox provided by a Checkbox input block is ticked.
For more advanced selection of other form controls, you can also wrap a jQuery selector within $(...). This will be evaluated to identify an input to retrieve the value for.
Where a {{form:key}} or jQuery selector $(...) identifies more than one input, the values are returned concatenated with commas. Such a list of values may be difficult to work with exact comparisons, so consider using 'contains' or 'not contains' comparison rules. This is a convenient trick to work with checkbox lists.
For convenience when used within a repeatable group, the {{form:key}} will automatically adjust to the current group repetition.
By default, the element shown/hidden is just the form input. However, if it is wrapped in a block design or other wrapping element(s), the scope can be grown to the containing element by selecting Apply to containing element.
Normally the form control is shown When condition is met and hidden when it is not met. We can also invert the entire condition, to hide the form control when the condition is met and show it When condition is not met.
As well as hiding the form control, the actual html inputs within the form control are disabled. When the form is submitted, these disabled inputs are not sent to the server. With that in mind, you should think twice before setting 'require' for an input that could be hidden and disabled. Such a form input may not pass validation!
For any form control block, the usual way of applying Visibility Rules is to configure the rules in the Behaviour tab of the form control's block edit dialogue.
If you need to simply show or hide some content according to Visibility Rules, the Boilerplate Content block can be used for simple content show/hide behaviour.
If you need to apply Visibility Rules to other items on the page, for example, to show other blocks or groups of blocks according to values entered in a form, we have the Visibility Rules Engine block. This block has no actual visual presence of its own on the page. It provides a way of configuring a set of Visibility Rules and attaching them to a CSS or jQuery selector. The selected element(s) are then shown or hidden according to the evaluated Visibility Rules.
When a form field is hidden by a visibility rule, that field is disabled and hence excluded from a submitted form.
This can complicate validation of such form fields, in some cases resulting in unwanted validation failure.
To support an easy solution, the Validate Input Fields handler provides an option to Skip validation of inputs which are not required and are missing from the submitted form data. When checked, any form input which is not required and not actually present in the submitted data, such as for hidden and disabled by a visibility rule, will not be validated.
A similar checkbox Skip validation of inputs which are not required and are empty in the submitted form data allows inputs that are not required to be submitted but empty.
Where a repeatable group contains required fields, but those fields could be hidden/disabled, the validation can be relaxed within a group - see the Validation tab of the Repeatable Group block edit dialogue. You may then need to add handlers to the pipeline ensure the genuinely required fields are present.
The Submit form block implements an extended option in the visibility rules. Rather than just showing or hiding the form control, it can also be configured to automatically submit the form when a condition is met.
When a form is automatically submitted, take care the condition is not perpetuated to result in an infinite loop. For example, the submitted form could disable one of the controls used by the condition or redirect to another page to avoid such a loop from manifesting.
If you need a specialized template or a custom input element, you can design new templates or new block types for form elements as you would any block type.
Blocks are easy for third party addition or extension. Block templates and are the first thing any Concrete CMS developer learns to code. They are one of the easiest things to code. The underlying mechanisms are well established and reliable.
Form handlers are built about the same extensible plugin system as many of my other addons (Universal Content Puller, Omni Gallery, Extreme Clean ...).
The whole system is aimed at easy extension within Form Reform, by third party addons, by agencies and by site building developers.
Handlers can be easily added to do whatever you want with the form data.
Saving form data with Form Reform is simply a handler in the processing pipeline. You can save to multiple locations or just one location.
If you need to save data elsewhere, such as to a dedicated table, a table provided through another addon, to another database, send it to an API, forward it to another server, or anywhere you can imagine, you can adapt or develop a form handler to do so.
The complexity of the code depends on where you are saving or sending the data, but wrapping that into a form handler plugin for Form Reform is straight forward.
The Form Reform handler plugin system is designed for easy extension.
Express is the built in object data system built in to Concrete CMS. Form Reform is way more powerful for forms. Express supports basic object relationships, but is not robust.
Reform the way forms are built. Build a form out of blocks. Take control of how form submissions are processed and how the submitted data is stored. Easy to extend. Easy to reconfigure. Tangible data. Easy to add your own integrations.
Provides blocks and dashboard utilities to List, display, summarize, generate reports and analyze form submissions from Form Reform. Additionally supports integration with Universal Content Puller.
Not just Form Reform and not just UTM! Capture and hold incoming UTM (or other) tags and make the tag values available to Form Reform and/or Conditional Redirect as {{place_holders}}. You don't need Form Reform to use this.
Form handlers for querying Microsoft Dynamics, forwarding and updating form data to Microsoft Dynamics.
A suite of advanced image capture and upload tools. Enhanced drag and drop file uploading. Make screengrabs from within Concrete CMS. Capture images directly from device webcams. Edit images before uploading.
Save submitted forms to Express objects and user attributes. Add and remove users from groups.
Form Reform Image Picker provides an image picking input block for Form Reform. The Image Picker Input is preconfigured to connect to most Omni Gallery gallery and slider display widgets, the core gallery block, and thumbnail showing templates for the core page list block. Advanced settings allow the Image Picker Input to be configured to pick images from other galleries and sliders.
Form Reform Data Picker provides data picking input blocks for Form Reform. Create pickers and selectors from tables or JSON data sources including HTML tables, Calendars, Page Lists, Universal Content Puller and previously submitted form results.
Extends Form Reform with form handler macros. Provides a new dashboard page at System & Settings > Form Reform > Form Reform Macros to manage macros, and form handlers to run macros.
A growing suite of resources to assist those developing blocks, handlers and more complex forms for Form Reform.
While you may have plans to implement some much more complex forms using Form Reform, we strongly recommend you start with a simple form such as our contact form example in order to review the basic principles of using Form Reform before you move onto anything bigger.