Problem/Motivation

UI pattern sources like component or blocks, rely on child plugins.
should have :
- an interface (and factorized implementation like a trait?) to allow to fetch the list of child plugins from outside the source.
- improved source label when child plugin is selected
- settings presets/skeletons for a source when a child plugin is known.

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

just_like_good_vibes created an issue. See original summary.

just_like_good_vibes’s picture

Title: [2.0.3] Source usability : better interfaces for sources relying/referencing on child plugins » [2.0.3] Source usability : better interfaces for sources relying on child plugins

pdureau’s picture

I am not sure about the naming...

Proposal inspired from [ObjectWithPluginCollectionInterface](https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Plugin%21...) but not identical because we have a single collection and not many collections:

  • getChildPluginDefinitions >> getCollection
  • getSettingsSourceWithChildPlugin >> getMinimalConfiguration
  • getChildPluginId >>getSelectedItem
interface SourceWithCollectionInterface {

  /**
   * Get collection of items.
   *
   * @return array
   *   Array of items definitions.
   */
  public function getCollection(): array;

  /**
   * Get the minimal configuration for an item.
   *
   * @param string $item_id
   *   An item ID.
   *
   * @return array
   *   A source configuration.
   */
  public function getMinimalConfiguration(string $item_id): array;

  /**
   * Get the currently select item from the collection.
   *
   * @return string|null
   *   The item ID.
   */
  public function getSelectedItem(): ?string;

Do we also need a getItemLabel(string $item_id): string ?

Also, it may be good to move ::getMinimalConfiguration() to SourceInterface and to implemtn it in SourcePluginBase as a proxy to PluginSettingsInterface::defaultSettings(). What do you think?

just_like_good_vibes’s picture

getMinimalConfiguration does not need any parameter, unless it is static, which could be a nice idea after all.

i don’t like collection, because it reminds of the plugin collections in drupal which are managed differently…

just_like_good_vibes’s picture

also, the term configuration for the source refers to the global configuration, whereas we wanted the settings, i would keep settings to avoid confusion

pdureau’s picture

getMinimalConfiguration does not need any parameter, unless it is static, which could be a nice idea after all.

You have the same parameter in the MR: getSettingsSourceWithChildPlugin(string $plugin_id): array;

i don’t like collection, because it reminds of the plugin collections in drupal which are managed differently…

Let's find a synonym

also, the term configuration for the source refers to the global configuration, whereas we wanted the settings, i would keep settings to avoid confusion

OK

pdureau’s picture

  • getChildPluginDefinitions >> getItems
  • getSettingsSourceWithChildPlugin >> getMinimalSetting
  • getChildPluginId >>getSelectedItem
interface SourceWithItemsInterface {

  /**
   * Get items.
   *
   * @return array
   *   Associative array of items definitions with ID as the key.
   */
  public function getItems(): array;

  /**
   * Get the minimal settings for an item.
   *
   * @param string $item_id
   *   An item ID.
   *
   * @return array
   *   A source setting.
   */
  public function getMinimalSetting(string $item_id): array;

  /**
   * Get the currently select item.
   *
   * @return string|null
   *   The item ID.
   */
  public function getSelectedItem(): ?string;

Is it better?

Also:

  • Do we also need a getItemLabel(string $item_id): string ?
  • it may be good to move ::getMinimalSetting() to SourceInterface and to implemtn it in SourcePluginBase as a proxy to PluginSettingsInterface::defaultSettings(). What do you think?
just_like_good_vibes’s picture

i am not so fan of items neither :)

pdureau’s picture

Title: [2.0.3] Source usability : better interfaces for sources relying on child plugins » [2.0.4] Source usability : better interfaces for sources relying on child plugins
pdureau’s picture

Title: [2.0.4] Source usability : better interfaces for sources relying on child plugins » [2.0.5] Source usability : better interfaces for sources relying on child plugins

Too late for 2.0.X

pdureau’s picture

Title: [2.0.5] Source usability : better interfaces for sources relying on child plugins » [2.0.6] Source usability : better interfaces for sources relying on child plugins
pdureau’s picture

Title: [2.0.6] Source usability : better interfaces for sources relying on child plugins » [2.0.7] Source usability : better interfaces for sources relying on child plugins

pdureau’s picture

UI Patterns 2 sources where we want to extract multiple item.

Reminder: Only for slots source.

Nice to have

ComponentSource with bootstrap:card:

source_id: component
source:
  component: 
    component_id: bootstrap:card

BlockSource with system_menu_block:admin:

source_id: block
source:
  plugin_id: system_menu_block:admin

Expected in the scope of this issue

Entity Field with field:node:article:title:

  source_id: entity_field
  source:
    derivable_context: 'field:node:article:title'
    'field:node:article:title':
      value: {}

Entity Reference with entity_reference:node:article:uid:user:user:

  source_id: entity_reference
  source:
    derivable_context: 'entity_reference:node:article:uid:user:user'
    'entity_reference:node:article:uid:user:user':
      value: {}

Out of scope

Because single item:

  • WysiwygWidget
  • TokenSource
  • ViewRowsSource

Multiple items context never reached from the top of a component data tree:

  • ViewFieldSource
  • FieldFormatterSourceDeriver
pdureau’s picture

Status: Active » Needs work

Thanks for your ongoing work.

It would be nice to also implement this interface on ComponentSource so it will be possible to get the same simplification in display_builder's ComponentLibraryPanel.

Also, we may need to add some properties in ::getChoices() along side label and provider: like the original plugin ID and the group/category.

It would be even better to return an object implementing standard interfaces instead of a loose array:

  • PluginDefinitionInterface::getClass
  • PluginDefinitionInterface::getProvider
  • PluginDefinitionInterface::id
  • PluginDefinitionInterface::setClass
  • Unfortunately, I have found nothing for label and group/category

Can you also add this to EntityReferencedSource or DerivableContextSourceBase ?

+  /**
+   * {@inheritdoc}
+   */
+  public function settingsSummary(): array {
+    $derivable_context = explode(':', $this->getSetting("derivable_context") ?? '');
+    return [
+      $derivable_context[array_key_last($derivable_context)],
+    ];
+  }

just_like_good_vibes changed the visibility of the branch 3513568-2.0.3-source-usability to hidden.

just_like_good_vibes’s picture

Assigned: just_like_good_vibes » pdureau
Status: Needs work » Needs review

here we are, ready for review :

- we have a new interface for those sources with a choice. It allows them to expose those choices to the outside world.
- we have improved the returned label of sources, in those particular cases of sources with choice.

pdureau’s picture

Assigned: pdureau » just_like_good_vibes
Status: Needs review » Reviewed & tested by the community

pdureau’s picture

Assigned: just_like_good_vibes » Unassigned
Status: Reviewed & tested by the community » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.