Skip to content

Field storage

Wim Leers requested to merge field_storage into 0.x

(Legend: ❌ = TODO, ✅ = working)

Goals

  • Being able to create, store, edit and view component trees.
    • Note: viewing component trees must support component prop values of sourceType == static:… ("fixed values") and sourceType == dynamic ("dynamic values": fetched from the host entity using a StructuredDataPropExpressionInterface)
    • WITH test coverage
  • Editing individual sourceType == static:field_item:<field type> prop values using field widgets in modal dialogs.
    • WITHOUT test coverage: viability alone is sufficient

Non-goals

  • Good UX
  • Any UI to change the expression used for a sourceType == dynamic prop value
  • Nested components
  • Translations
  • "default" component trees aka bundle-defined defaults (in the Capabilities Doc: "content type templates"), which this field ought to store the additions/overrides for; it should no repeat the defaults.
  • API representation (JSON:API) or otherwise

MR contents

  • New field type based on @effulgentsia's proposal at https://www.drupal.org/project/drupal/issues/3440578, with 3 properties:
    1. ✅ tree to store the component tree
      • Here just restricted to a component list, not doing nesting yet. That should happen in !2.
    2. ✅ props to store the props values assigned to the components in the tree
    3. ✅ 932ce4b9: hydrated to compute the combination of both — and available as both a JSON blob with cacheability metadata and as a Drupal render array.
      • ❌ … based on configuration, we can achieve symmetric translation or asymmetric translation.
  • With validation:
    • ✅ the component instance UUIDs in tree and props must match
    • ✅ 0c4ffd00: each component's assigned prop values must not trigger an InvalidComponentException
    • ❌ … much more!
  • With the most minimal UI possible:
    • ✅ widget: two <textarea>s — validation: see above

      • ✅ : !15 (d964218b) Edit individual sourcetype: static:field_item:<field type> prop values using their corresponding widgets using modal dialogs — this would increase confidence that we'll be able to pull this off via the React UI eventually:

        field-widget-for-static-sdc-prop-value.gif

      • ❌ The above MUST run explicit validation against the SDC props, because e.g. the link field type accepts relative URLs, fragment URLs, etc, whereas the SDC prop does not.

      • ❌ Edit individual sourcetype: dynamic expressions using a <select> → !20 (merged)

    • ✅ formatter: reuse the same rendering that was in hook_entity_view_build_alter() and uses _eb_resolve_sdc_prop_value() — refactored to value object in 04ce0599 (belongs elsewhere but trying to avoid conflict with @f.mazeikis' work on adapters — @f.mazeikis indicated this was no problem)
      • Out-of-scope here: taking over the entire rendered entity: for the purpose of this MR being able to render the component tree inside a field is sufficient.
  • Moved to !17 (merged) Drop Drupal 10.2 support~~; require Drupal 10.3, due to plugin annotations being deprecated since 10.3: ~~~~https://www.drupal.org/node/3229001~~
  • Tests (minimal)
    • ❌ Unit
    • ❌ Kernel
Edited by Wim Leers

Merge request reports