Extending the Form Builder¶
Form Builder Bundle comes with a number of types of fields, but it is designed to be easy to extend by adding new ones.
Default field definitions are available in
Field definition structure¶
Field definitions are contained under the
fields key. Each definition has its own key, e.g.
Each definition must contain two sections:
identifier- name of the definition used on the front end
displayName- name displayed in the Page mode editor in the
The definition can also contain the following optional sections:
validators- defines validators that the field will use. This must contain the validator's identifier and the values that will be checked during validation, for example:
attributes- contains the field's attributes. You can place here custom attributes for new fields. There are also four default attributes that are used for every field:
LABEL_PLACEHOLDER_TEXT. If you wish, you can override them in your configuration.
views- provides a list of views that will be used to display the field. At least one view must be defined, with the keys
template, for example:
1 2 3 4 5
Adding a new field definition¶
This procedure assumes you are creating a separate Bundle to house your new type of form field.
1. Create a YAML file with field definition¶
Create a YAML configuration file, e.g.
Resources\config\extended_fields.yml, with the following code:
1 2 3 4 5 6 7 8 9 10 11 12 13
You can also provide additional options using the
options: key. For example, you can make sure that the data entered in a field will not to be stored in the database, like for example in the built-in Captcha field.
When creating a new template for the field definition, remember to add the mandatory
ezform-field class and
field.id as shown below:
1 2 3 4
2. Modify the
The class must implement the
prepend method in
TestExtension.php add the following lines at the end:
1 2 3 4 5 6 7 8
Creating your own validators¶
You can create your own validators by reproducing the following configuration:
A validator implements the
EzSystems\FormBuilder\SPI\ValidatorInterface.php interface and extends the abstract class
The interface requires the implementation of the following methods:
||bool||$value||Contains the logic for the validation. It returns
||string||Returns a string with the name of the validator that will be used in the editor|
||array||Returns error message(s) to appear when the
||mixed $limitation||$limitation||Allows the configuration of limitations. Its default implementation is contained in the
||string||Returns the name of the checked value type|
Currently the abstract class
Validator has three value types (defined in
1 2 3
The validator must be tagged as
form_builder.field_validator. Due to this the
Resources\config\validator_services.yml file contains two entries, one in the
and one in the
1 2 3 4
Whenever a form is submitted and stored in a database,
lib\Core\SignalSlot\Signal\FormSubmit emits a signal in a
submitForm service. You can create your own listeners, called Signal slots, to capture the FormSubmit signal.
Below you can find an example of a custom Signal slot. It saves submission to a text file.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
It has to be registered as a tagged Symfony service, like this:
1 2 3 4 5
Other Form Builder fields¶
The following Form Builder fields require additional configuration.
To make use of a datepicker in the Date field you need to add the necessary assets. The assets should be added in page head with the following code:
1 2 3 4 5 6
1 2 3 4 5 6
Adding new date format¶
If you wish to add a new date format, the
alias in the date field config must follow this pattern:
D - day of the month (1-2 digits)
DD - day of the month (2 digits)
M - month of the year (1-2 digits)
MM - month (2 digits)
YY - year (2 digits)
YYYY - year (4 digits)