Quantcast
Channel: Issues for Drupal core
Viewing all articles
Browse latest Browse all 296414

Define form elements from SDC

$
0
0

Problem/Motivation

In #3494634: Compatibility between SDC and the Form API, we discussed 2 incompatibilities between SDC and the form API:

  • we can put a full form into a component slot, but we can't put a form element of a form defined outside the component
  • we can't define form element, directly usable with the Form API, with SDC. So we can't easily implement some design systems components like https://getbootstrap.com/docs/5.3/forms/checks-radios/#switches

Let's deal with the second point in this dedicated ticket.

Proposed resolution

https://www.drupal.org/docs/drupal-apis/form-api/form-render-elements

Form properties to evaluate:

  • #ajax: (array) Array of elements to specify Ajax behavior. See the Javascript API and AJAX Forms guides for more information.
  • #default_value: Default value for the element. See also #value.
  • #description: (string) Help or description text for the element. In an ideal user interface, the #title should be enough to describe the element, so most elements should not have a description; if you do need one, make sure it is translated. If it is not already wrapped in a safe markup object, it will be filtered for XSS safety.
  • #description_display: (string) Where and how to display the #description.
  • #disabled: (bool) If TRUE, the element is shown but does not accept user input.
  • #prefix: (string) Prefix to display before the HTML input element. Should be translated, normally. If it is not already wrapped in a safe markup object, will be filtered for XSS safety.
  • #suffix: (string) Suffix to display after the HTML input element. Should be translated, normally. If it is not already wrapped in a safe markup object, will be filtered for XSS safety.
  • #required: (bool) Whether or not input is required on the element.
  • #required_error: (string) Override default error message "@field_title is required" will be used if this is undefined.
  • #title: (string) Title of the form element. Should be translated.
  • #title_display: (string) Where and how to display the #title.
  • #value: Used to set values that cannot be edited by the user

The other ones are internal, or not self-contained, or needs PHP. That means form elements created from SDC doesn't have:

  • #after_build: (array) Array of callables or function names, which are called after the element is built. Arguments: $element, $form_state.
  • #element_validate: (array) Array of callables or function names, which are called to validate the input. Arguments: $element, $form_state, $form.
  • #process: (array) Array of callables or function names, which are called during form building. Arguments: $element, $form_state, $form.
  • #value_callback: (callable) Callable or function name, which is called to transform the raw user input to the element's value. Arguments: $element, $input, $form_state.
  • ...

This will not be a missing feature, but a welcomed feature, however:

  • If really needed by the front developer, to implement UI logic, we can imagine so declarative ways:
    • inline twig transformation for #process
    • json schema for #element_validate
    • ...
  • If a back developer want to add some callbacks, it will be a applicative/business need. The form elements that will be created will be alterable like any other form elements.

So, it will be the opportunity to split UI logic from business logic, which is not currently the case in the Form API.

How do we create form elements (which are plugins too) from those SDC plugins? Plugin derivatives?

Remaining tasks

Let's start by trying to re-implement a few Core form element with SDC, some simple, some complex:

  • Textfield
  • Checkboxes
  • Checkbox
  • Actions
  • Submit button
  • ...

Out of scope

The scope of this ticket is not to override or replace existing form element but to create new form elements, aside the existing ones, from SDC. We hope one day all Core form elements will be defined as SDC components, but it will be other issues.

Also, we don't address the need of derivative configurable plugins like Field Widgets or WebformElement. It may be the purpose of some contrib modules.


Viewing all articles
Browse latest Browse all 296414

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>