Forms

HTTP Forms are a very old and important concept of the Web Platform. Neos offers you different ways to create, render and store them.

#Defining forms

Neos offers you multiple ways to create forms:

 

#Which Form package to choose?

In case you are unsure, use the Neos.Fusion.Form package, which is natively integrated into Fusion and AFX.

The older Neos.Form ecosystem is not suggested for new projects. There, we pioneered many of the concepts which are now simplified and supported by the newer Neos.Fusion.Form package.

#Neos.Fusion.Form (since 2021)

Neos.Fusion.Form is the newer and recommended way to build Forms in Neos. It currently supports the following features:

  • 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
    • 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 field names 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

The following feature is currently not implemented (compared to the legacy Neos.Form ecosystem):

  • Node Types for building a form through the Neos UI

#Neos.Form Ecosystem (since 2012)

supported

We have no plans to deprecate the older Neos.Form ecosystem - just expect development to be slower.

For legacy reasons, by default the form rendering of Neos.Form is based on the Fluid renderer and Fluid templates for all the form elements.

That approach is flexible and probably the easiest for developers that are used to working with Fluid. When a lot of custom rendering is required, though, it can lead to a duplication and accidental complexity.
For these cases the Neos.Form.FusionRenderer package offers an alternative to build forms in Fusion.

It defines a new form preset that replaces the default form renderer with a Fusion implementation. The default prototypes render elements just like the "default" preset would. But now the complete output is adjustable with a bit of Fusion code.

The following example will remove the labels of all elements and render their content as placeholders instead: 

fusion
prototype(Neos.Form.FusionRenderer:FormElement) {
    label >
    fieldContainer.field.attributes.placeholder = ${element.label}
}

Make sure to have a look at the Fusion prototypes to see how they work together and how they can be manipulated to your needs.

#Core Packages

#More Form Packages

#Further reading

Localization
SEO