Forms¶
Ibexa DXP offers a unified way of handling all one-page forms.
One-page forms have several common criteria:
- They are displayed on a single page.
- After submitting some processes are executed in the backend.
- After server response the user sees a confirmation page with a success or error message.
Ibexa DXP uses Symfony forms as part of the solution.
You can pre-fill the form with default values when it is loaded for the first time. The process that pre-fills the form is called a pre-data processor.
You can define actions that are executed after the form is submitted.
These actions are services that are called in a sequence and are able to exchange the data.
These actions are called dataProcessors.
If process execution is not successful, the process can store an error message and display it on the confirmation page.
You can decide what happens after the form is submitted - on server response. You can differ between valid and invalid responses and change the behavior according to your needs.
Usually a confirmation page is displayed, but you can choose one of the following behaviors:
- confirmation page
- redirect to another page:
- another route from the shop
- external URL
Creating a form¶
To create a form you must define and implement the form component parts (form entity, form type, template)
and its services (preDataProcessor and dataProcessors) and point to them in configuration.
FormTypeResolver¶
formTypeResolver identifies the form in the URL.
FormsController::formsAction handles the form and formTypeResolver is the parameter that tells it
which forms configuration should be used.
1 2 3 | |
When you call the URL /service/registration_private the FormsController::formsAction method
uses the forms configuration.
Define another URL for the form¶
If you want to change the URL for the form, define a new route for FormsController::formsAction.
The parameter formTypeResolver must still be part of the URL.
1 2 3 | |
Then, when you call /shop_functions/registration_private, the FormsController::formsAction is used.
Configuration¶
The configuration parameter must follow this syntax:
1 | |
formTypeResolver identifies the form and has a special function.
You can define the whole form behavior using configuration.
In the following example, formTypeResolver value is registration_private.
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 | |
| Configuration key | Description |
|---|---|
modelClass |
Required. A fully-qualified class path to the form entity. This class must extend Silversolutions\Bundle\EshopBundle\Entities\Forms\AbstractFormEntity |
typeClass |
Required if typeService is not defined. A fully-qualified class path to the form type. Using typeService gives more flexibility. |
typeService |
Required if typeClass is not defined. ID of the form type service. |
template |
Required. Template that renders the form. |
validMessage |
General success message displayed on the confirmation page if form submission is successful. |
invalidMessage |
General error message displayed on the confirmation page if form submission failed. |
preDataProcessor |
ID of the service that pre-fills the form. |
dataProcessors |
List of service IDs that are executed in sequence after the form is submitted. |
response |
Behavior definition on the server response. If not defined, the confirmation page (template) is displayed. |
policy |
Required user Policy. If the user doesn't have the Policy, they cannot see the form. The Policy must be defined as module/function |