neos/fusion-form
composer require neos/fusion-form
Fusion Form
v2.3.0
- Requires
- php: >7.2
- neos/flow: ^6.0 || ^7.0 || ^8.0 || ^9.0 || dev-master
- neos/fusion: ^5.0 || ^7.0 || ^8.0 || ^9.0 || dev-master
- neos/fusion-afx: ^1.2 || ^7.0 || ^8.0 || ^9.0 || dev-master
- neos/utility-arrays: *
- neos/utility-objecthandling: *
- psr/http-factory: *
- Requires (dev)
- neos/swiftmailer: *
- phpunit/phpunit: ^7.1 || ^8.0 || ^9.0
- phpstan/phpstan: ^0.12.78
- Suggest
- neos/swiftmailer: Required for the Neos.Fusion.Form.Runtime:Email action to work
Fusion Form
Pure fusion form rendering with afx support!
Documentation
Neos.Fusion.Form - Form Rendering and Data Binding
This part covers the rendering of forms that are bound to objects or data and will be submitted to a custom Controller Action.
- Fusion Form Basics
- Tutorials
- Examples
- Fusion Prototypes
- Eel Helpers
Form.Fusion.Form:Runtime - Runtime Single/Multistep Forms with Actions
This part covers the definition of forms with validation and finishing actions via Fusion. Use cases like contact forms and newsletter subscriptions should be implemented like this.
- Runtime Fusion Form Basics
- Tutorials
- Examples
- Fusion Prototypes
- Eel Helpers
- Form Actions
Development targets
- Form rendering in fusion with afx and data binding
- Clear separation of automation and magic for understandable results
- Flexibility:
- Make no assumption about the required markup like classNames
- Allow to override all automatically assigned attributes
- Enable form fragments as fusion components
- Allow to bind multiple objects to a single form
- Enable to create custom controls with
- Respect form elements that are defined as plain html when rendering __trustedProperties
- Convenience:
- Render hidden fields for validation, security and persistence magic
- Provide validation-errors and restore previously submitted values
- Prefix fieldnames with the current request namespace if needed
- Make writing of fusion backend modules easy:
- Create a backend field container with translated labels and error messages
- Adjust field markup inside the field container for the neos-backend
Important Deviations from Fluid Form ViewHelpers
The following deviations are probably the ones fluid developers will stumble over. There are many more deviations but those are breaking concept changes you should be aware of.
- Instead of binding a single
object
adata
DataStructure is bound to the form. - Form data-binding is defined via
form.data.object={object}
instead ofobjectName
andobject
. - Field data-binding is defined vis
field.name="object[title]"
with the object name and square brackets for nesting. - Data binding with
property
path syntax is not supported. - Select options and groups are defined directly as afx
content
and notoptions
.
Important deviations from the concepts of the Neos.Form package
- The definitions for form rendering and validation are separated into
content
andschema
of theprocess
. - By default the
SingleStepProcess
is used as this is the most common case. If you need multiple steps theprocess
has to be altered toMultiStepProcess
- Settings, form data and node properties can be used in a unified way via Fusion to define actions and control the process.
- Confirmations are no special feature but can be defined as "step" in a MultiStepProcess
- The concept of finishers is replaced with
actions
. - Actions cannot decide to send the user back into the form process.
The same vendor provides 94 package(s).