Allow Form Decorators

Created on 17 February 2024, about 1 year ago

Problem/Motivation

Drupal provides several methods for altering forms, with the hook_form_alter being one of the most widely used. This approach allows for the modification of the form array and the addition of static callbacks for validation and submission processes.

Despite its flexibility and ease of use, this method falls short of integrating with the concept of altering the implementing class for a specific feature, as is possible with services.

Proposed resolution

Allow form decorators β†’ .

On https://www.drupal.org/project/form_decorator β†’ there is a Proof of Concept how one could offer an easy way to decorate forms.

Key benefits might be:

  1. Dependency Injection in your form logic
  2. Easily reuse methods of the original class
  3. No need for custom callbacks - one can add logic to submit/validation handlers
  4. Having the form logic in one separate file instead of .module
✨ Feature request
Status

Active

Version

11.0 πŸ”₯

Component
FormΒ  β†’

Last updated about 2 hours ago

Created by

πŸ‡©πŸ‡ͺGermany Harlor Berlin

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @Harlor
  • πŸ‡©πŸ‡ͺGermany Harlor Berlin
  • πŸ‡©πŸ‡ͺGermany tstoeckler Essen, Germany

    Discussed this with @harlor at DrupalDevDays, just noting some thoughts.

    Since we already use the class resolver to instantiate the form class, it should work fine to use service IDs instead of the actual class names (or otherwise just have the class name be the service ID) and the decorate the respective services. So by simply making forms services and referencing them by their ID we could already reap the benefits of being able to decorate them.

    On the other hand, years ago there were discussions already about converting forms to plugins in the context of Config Translation. Config Translation basically needs to now a title and a path for a form and currently dynamically collects that information during route building, but it would be nicer (and less brittle) to have that information statically. That would then also allow altering forms very easily.

    Either way, really like the idea πŸ‘οΈ

Production build 0.71.5 2024