LegacySpecScanner
in package
implements
AutoServiceInterface
This provides transitional support for extensions that implemented 'SpecProviderInterface'.
Compare these contracts:
- For v5.19-v5.53, an extension could create a class in '$EXT/Civi/Api4/Service/Spec/Provider' which implements 'SpecProviderInterface'. This would be auto-registered as a Symfony service and tagged with 'spec_provider'.
- For v5.54+, an extension can enable
scan-classes@1. Any classes in$EXT/Civior$EXT/CRMwill be scanned and registered, provided that they implement AutoServiceInterface and enablescan-classes@1.
The 5.54+ scanner supports more interfaces and more options. However, it won't necessarily detect
spec-providers from 5.19-5.53 (because they don't have scan-classes@1 and they don't
implement AutoServiceInterface).
Table of Contents
Interfaces
- AutoServiceInterface
- The CiviCRM container will automatically load classes that implement AutoServiceInterface.
Methods
- buildContainer() : void
- Register any services with the container.
- findClasses() : array<string|int, mixed>
- Scan all enabled extensions for files in a certain namespace.
Methods
buildContainer()
Register any services with the container.
public
static buildContainer(ContainerBuilder $container) : void
Parameters
- $container : ContainerBuilder
findClasses()
Scan all enabled extensions for files in a certain namespace.
protected
static findClasses(string $namespace, ContainerBuilder $container) : array<string|int, mixed>
Q: this seems to be adding resources to the container as it goes, rather than just finding them as per function name? Otherwise could share an implementation with LegacyEntityScanner
Note: respects dispatch policy for hook_civicrm_scanClasses, for consistency
Parameters
- $namespace : string
- $container : ContainerBuilder