(REF) Extract compiler passes from CRM_Api4_Services #24283
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Overview
CRM_Api4_Services
has interesting behavior that (sort of) applies to all container-based services -- it detects services with the tagsevent_subscriber
andspec_provider
, and it registers them with the necessary provider (ie the event-dispatcher or the spec-gatherer).This patch preserves support for these tags, but it moves the code to a more conventional spot, fixes a bug, and adds explanatory docblocks.
Before
It scans for tagged services (
findTaggedServiceIds()
) during the definition phase. This is too early. The tags will work for some services -- but they'll be quietly ignored on other services.For example, if you define a tagged-service in
Civi\Core\Container::createContainer()
, then it will be recongized. But if you define the same tagged-service inhook_civicrm_container
, then it won't be recognized.After
It scans for tagged services (
findTaggedServiceIds()
) during the compilation process. This is slightly later -- after all service definitions have been defined.Consequently, the tags will work the same way (regardless of who defines the service).
Technical Details
The key thing is to distinguish these use-cases:
$container->setDefinition()
(et al).$container->addCompilerPass()
The prior code conflates these two things. The PR splits them apart (running as separate phases - in keeping with the general design of Symfony's
ContainerBuilder
).Comments
The specific folders / interfaces / tags for
CRM_Api4_Services
may seem a bit alien. I submit that doesn't matter -- because there's a bunch of test-coverage that relies onCRM_Api4_Services
(if it breaks, you'll see a lot of failures) and because it's a step toward #24276, which will allow a more consistent model.