Contrib.social

Allow definition objects to provide options

Open on Drupal.org →
Created on 29 August 2014, over 10 years ago
Updated 19 September 2024, 3 months ago

Problem

  • When AllowedValuesInterface has been created and implemented for field types, field definition objects/classes did not exist. Meanwhile, we've started moving metadata to definition objects, but allowed values are left on field item objects what makes an inconsistent API and leads to issues like #2238085: [regression] options_allowed_values() signature doesn't allow for Views filter configuration → . Instead, options list / allowed values should be defined and retrieved via field definitions as we do with default values now.
  • For context definitions, Rules has the need to be able to fetch the options list / allowed values per context definition as well, thus we need a way to specify the options list there. Thus, we have the same requirement as for field definitions here.
  • Generally, for the Typed Data API having allowed values accessible on the data object is enough as it is used for validation only. However, as allowed values are (mostly) run-time independent metadata, this is something one would expect to be described in the data definition obejcts as well. Given that, the context definition use case and consistency allowed values should be handled by data definitions as well.
  • For field definitions, effulgentsia has summarized the problems of the current approach very well at #2305397: Field type (item) classes implementing AllowedValuesInterface::getPossible(Values|Options)() is incompatible with Views and possibly other use cases → .

Proposed resolution

Come up with a decent, easy to use API to specify and get options on definition objects and make use of it for all three definitions.

Overview:

Option providers are classes which can be set on definition objects via a setOptionsProviderDefinition() method, while getOptionsProvider() continues to return the option provider instance. Option provider classes can be easily created by extended the SimpleOptionsProviderBase, which assumes settable and possible options are the same. On top of those classes, the following options provider notations are supported:

   *  - The name of a class implementing the OptionsProviderInterface.
   *  - A callable, either as
   *    - static method via the class::method notation or as
   *    - method on a service via the service:method notation or as
   *    - function callback.

The callback notations just add the CallableOptionsProvider in automatically.

The details that have to be addressed are:

  • Options that depend on the $entity object, e.g. the settable options of a workflow state field which depend on the current issue state. The entity object has to be optional though.
  • For Rules, or context aware plugins in general, options that depend on some plugin context - e.g. the settable options of Rules' "Set a data value" value, or the selectable fields for an "Entity has field" condition depending on the configured entity type.

This details are covered via options provider context, which basically allows passing additional context to option providers based upon their implemented interfaces. (todo add more details here)

API examples

This is how you would use the API as a consumer who wants to retrieve possible options:

For a given field:

$field_definition->getOptionsProvider()->getPossibleOptions();
// or to get settable options for a certain entity
$field_definition->getOptionsProvider($entity)->getSettableOptions();
// Possible short-cut:
$field_item->getSettableOptions();

For a certain plugin context, from a plugin method:

$this->getPossibleOptions('context_name');
// What internally does:
$this->getContextDefintion('context_name')->getOptionsProvider($this->getContexts())->getPossibleOptions();

Specifying the options of a field:
$field_definition->setOptionsProvider($class);
// or
$field_definition->setOptionsProvider($callback);

For context definitions, things work very similar except that the options provider can work with any context which is defined by the plugin (internally the plugin context is set as options provider context).

Remaining tasks

Find agreement. Do it.

User interface changes

-

API changes

  • Field types would provide an options provider class instead of putting the options-list logic on the field item class. However, there is a BC-layer which automatically adds in a LegacyOptionsProvider if necessary.
📌 Task
Status

Needs review

Version

11.0 🔥

Component
Typed data  →

Last updated 16 days ago

  • Maintained by
  • 🇦🇹Austria @fago
Created by

🇦🇹Austria fago Vienna

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

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment almost 2 years ago →
    needs-review-queue-bot

    The Needs Review Queue Bot → tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

    Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

    Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

  • Comment almost 2 years ago →
    🇮🇳India Akhil Yadav

    Added patch against #83 in 10.1 version

  • Status changed to Needs review almost 2 years ago
  • Comment almost 2 years ago →
    🇮🇳India bhanu951

    Setting as need review for tests to run.

  • Comment almost 2 years ago →
    🇮🇳India bhanu951

    core/lib/Drupal/Core/Field/TypedData/FieldDefinitionOptionsProviderTrait.php
    core/lib/Drupal/Core/Field/TypedData/FieldStorageDefinitionAwareOptionsProviderInterface.php
    core/lib/Drupal/Core/Field/TypedData/FieldStorageDefinitionAwareOptionsProviderTrait.php
    core/lib/Drupal/Core/Field/TypedData/LegacyOptionsProvider.php
    core/lib/Drupal/Core/Plugin/Context/ContextAwareOptionsProviderInterface.php
    core/lib/Drupal/Core/TypedData/Options/CallableOptionsProvider.php
    core/lib/Drupal/Core/TypedData/Options/DefinitionAwareOptionsProviderInterface.php
    core/lib/Drupal/Core/TypedData/Options/DefinitionAwareOptionsProviderTrait.php
    core/lib/Drupal/Core/TypedData/Options/DependentOptionsProviderInterface.php
    core/lib/Drupal/Core/TypedData/Options/OptionsProviderResolver.php
    core/lib/Drupal/Core/TypedData/Options/SimpleOptionsProviderBase.php
    core/modules/system/src/Tests/TypedData/OptionsProviderTest.php

    Above files missing in patch #87 which were present in #83.

    Hiding patch #87.

  • Comment almost 2 years ago →
    🇬🇧United Kingdom catch
  • Comment almost 2 years ago →
    🇫🇷France andypost

    Some clean-up after re-roll from #83

  • Merge request !3419Issue #2329937: Allow definition objects to provide options → (Open) created by bhanu951
  • Comment almost 2 years ago →
    🇮🇳India bhanu951

    Removed Deprecated Utility.

  • Status changed to Needs work almost 2 years ago
  • Comment almost 2 years ago →
    needs-review-queue-bot

    The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

    Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

    Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

  • Comment over 1 year ago →
    🇪🇬Egypt Mohamed Nabawy

    this is an enhanced version of 2329937-91.patch to support ListDataDefinition with empty property name like in rules condition (User Has Role)

  • Comment 12 months ago →
    🇺🇦Ukraine i-trokhanenko Lutsk 🇺🇦

    Rerolled the 2329937-91.patch to Drupal 10.2.x

  • Comment 12 months ago →
    🇺🇦Ukraine i-trokhanenko Lutsk 🇺🇦

    Ignore patch #97. Here is the correct one

  • Comment 6 months ago →
    🇺🇸United States gcalex5

    Re-roll #98 for 10.3.x

  • Pipeline finished with Canceled
    6 months ago
    Total: 38s
    #219760
  • Pipeline finished with Canceled
    6 months ago
    Total: 132s
    #219761
  • Pipeline finished with Failed
    6 months ago
    Total: 373s
    #219763
  • Comment 6 months ago →
    🇮🇳India bhanu951
  • Pipeline finished with Failed
    6 months ago
    Total: 184s
    #219796
  • Comment 4 months ago →
    🇺🇸United States veronicaSeveryn

    I have rerolled the patch for Drupal 11.x branch (it is at the tag of 11.0.2 now).
    I had to combine patches from #91 + #95, because otherwise was having all kinds of issues mainly related to List type fields (couldn't create these fields on nodes, any entity containing this field type was throwing an error, etc.).

  • Comment 4 months ago →
    🇫🇷France andypost

    Please create MR from patch to run tests

  • First commit to issue fork.
  • Pipeline finished with Failed
    3 months ago
    #286864
  • Pipeline finished with Failed
    3 months ago
    Total: 159s
    #286870
  • Pipeline finished with Failed
    3 months ago
    Total: 135s
    #286875
  • Pipeline finished with Failed
    3 months ago
    Total: 127s
    #286905
  • Status changed to Needs review 3 months ago
  • Comment 3 months ago →
    🇮🇳India mrinalini9 New Delhi

    Hi,

    I have created MR from the patch #101 to run tests, please review it.

    Thanks!

  • Pipeline finished with Failed
    3 months ago
    Total: 488s
    #288017
  • Pipeline finished with Failed
    3 months ago
    Total: 264s
    #288160
  • Comment 2 months ago →
    needs-review-queue-bot

    The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

    This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

    Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024