Pure fusion form rendering with afx support!

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
  • Implementing custom input elements
  • Fusion rendering for backend modules
  • Custom field container
• Examples
  • FrontendForm
• Fusion Prototypes
• Eel Helpers

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
  • Custom form action
• Examples
  • SingleStepForm
  • MultiStepForm
• Fusion Prototypes
• Eel Helpers
• Form Actions

• 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

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 a data DataStructure is bound to the form.
• Form data-binding is defined via form.data.object={object} instead of objectName and object.
• 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 not options.

• The definitions for form rendering and validation are separated into content and schema of the process.
• By default the SingleStepProcess is used as this is the most common case. If you need multiple steps the process has to be altered to MultiStepProcess
• 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.