Problem/Motivation
UI Patterns 2
UI Patterns 2 is shipped with those context for sources:
| Context | Example | context_definitions | context_requirements |
|---|---|---|---|
| Content entity | EntityLinksSource | entity
| X |
| Field | FieldLabelSource | entity & field_name
| field_formatter
|
| Field item | FieldPropertySource | X | field_granularity:item (via deriver)
|
| View (everywhere) | ViewTitleSource | entity:view
| X |
| View (all rows) | ViewRowsSource | entity:view
| views:style
|
| View (each row) | ViewFieldSource | entity:view
| views:row |
The mix between context_definitions and context_requirements is a bit complex, and some context_requirements naming are too specific (field_formatter for example).
There are some plans to add a "Content" context (not the same as "Content entity" for sources which can be stored only in a content field (for Layout Builder overrides or Ckeditor5 for example): #3501797: Add a ContentEntity source for slots with a Content entity context
Display Builder
The module doesn't use context_definitions and has those context_requirements:
is_display_builder_views. Example: ViewExposedSourceis_display_builder_page_layout. Example: PageTitleSource
Those contexts don't tell about where we are in the Drupal API, what we have access from the source, but about the specific Display Builder sub-module using it. So, they sources will not be compatible with the UI Patterns 2 ecosystem and the future Display Builder ecosystem.
In a perfect world, Display Builder will have no Source plugins in its codebase.
Proposed resolution
Instead of is_display_builder_views, use the ones already defined and managed by UI Patterns 2.
Instead of is_display_builder_page_layout . Add a "Page" context which will be able to be proposed for UI Patterns 2 inclusion. See #3529737: Add proper page management
The future Content context from UI Patterns 2 must follow the same principles because it will also be used in Display Builder Entity View's overrides. We can implement it first in Display Builder.
If it is the opportunity to propose a backward compatible simplification to UI Patterns 2 team, let's do it.
Issue fork display_builder-3534579
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
Comment #2
pdureau commentedComment #3
pdureau commentedFollowing our discussion, can you check what can be done?
On UI Patterns 2
By maybe cleaning and tidying (removing
field_formattercontext_requirements for example) the existing.By creating a centralized, standardized, nomenclature to manage our 8 contexts:
So, all UI Patterns 2 ecosystem knows what is available.
By better documenting the attributes in https://git.drupalcode.org/project/ui_patterns/-/blob/2.0.x/src/Attribut...
On Display Builder
By replacing
is_display_builder_viewsandis_display_builder_page_layoutby the ones from the centralized, standardized, nomenclature.Comment #6
pdureau commentedComment #7
pdureau commentedFYI, in #3534215: Implement WithDisplayBuilderInterface in Views
is_display_builder_viewswill becomeviews:styleComment #8
pdureau commentedComment #9
pdureau commentedTo move to UI Patterns 2 where we only do this little tasks:
field_formattercontext_requirements for example) the existing./docs/3-devsComment #10
pdureau commentedComment #11
pdureau commentedFollow-up: #3540247: Map source contexts with enums
Comment #12
pdureau commentedComment #13
pdureau commentedFinally, still needed in Display Builder to rename
is_display_builder_page_layoutComment #14
pdureau commentedComment #15
pdureau commentedMore complicated than expected, because when the Drupal blocks are duplicated in the block library. It is because LocalActionsSource and LocalTasksSource are extending Drupal\ui_patterns\Plugin\UiPatterns\Source\BlockSource which is implemntign the SourceWithChoice interface.
Comment #16
pdureau commentedWill be done in #3529468: Remove ui_patterns_overrides because the 2 subjects are too linked.