Problem/Motivation

One of the sanctioned ways to add site-specific behaviour without touching generated code — and the one meant to absorb most of it — is a structure property whose source is @service:method rather than a field. Without it, anything computed forces a subclass, and the promise that generated files never need editing does not hold.

Proposed resolution

  • Parse the @service:method syntax in a structure property and resolve it through the container at build time.
  • Call with a defined signature — the entity, the property settings, and a cacheability object the callee can add to — and validate that the service exists and the method is public at configuration save, not at request time.
  • A missing service produces a configuration validation error and, at runtime, an omitted key plus a logged warning; never a 500.
  • Restrict what may be called to services tagged for the purpose, so an arbitrary method of an arbitrary service cannot be invoked from configuration.
  • The passthrough shape that returns the service result unchanged, and kernel coverage of both the happy path and every failure mode above.

Remaining tasks

Everything. The security restriction is the part that needs the most thought: configuration that can call code is configuration that can be an attack.

Issue fork myrest-3620341

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

sergeydruua created an issue. See original summary.

  • sergeydruua committed 730905af on 1.0.x
    Issue #3620341: Support a service call as the source of a property
    
sergeydruua’s picture

Status: Active » Fixed

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

sergeydruua’s picture

Status: Fixed » Closed (fixed)