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 |