feat(symfony): Add an option to #[ApiResource] to keep the class as service
#7403
Conversation
| * | ||
| * @var bool|null | ||
| */ | ||
| public bool $registerAsController = false, |
There was a problem hiding this comment.
I'm not sure for the name. Any better idea?
There was a problem hiding this comment.
Since it could work with any service and not only controller, maybe registerAsService or exposeAsService (?)
Or the inverted excludeFromContainer.
but the issue is that such name is really related to the symfony configuration, and it might be weird on laravel side to have a useless option.
What's the benefit of $definition->setAbstract(true)->addTag('container.excluded', ['source' => 'by #[ApiResource] attribute']); for dto ?
Also, couldn't it be automatically detected/added only if the class is not already registered/autowired (as a service/controller) (?)
But given the "wrong" use I did with ApiResource to document some controller route, I wonder if the right solution wouldn't to expose another dedicated attribute for my usage (which could be used on Controller class or directly on a route) like #[ApiRoute] (?)
There was a problem hiding this comment.
But given the "wrong" use I did with ApiResource to document some controller route, I wonder if the right solution wouldn't to expose another dedicated attribute for my usage (which could be used on Controller class or directly on a route) like
#[ApiRoute](?)
This feature might already exists
#7402 (comment)
| ->addTag('container.excluded', ['source' => 'by #[ApiResource] attribute']); | ||
| $container->registerAttributeForAutoconfiguration(ApiResource::class, static function (ChildDefinition $definition, ApiResource $attribute): void { | ||
| $definition->addTag('api_platform.resource'); | ||
| if ($attribute->registerAsController) { |
There was a problem hiding this comment.
Given the name did you want to do the opposite ?
if (!$attribute->registerAsController) {
| * | ||
| * @var bool|null | ||
| */ | ||
| public bool $registerAsController = false, |
There was a problem hiding this comment.
Since it could work with any service and not only controller, maybe registerAsService or exposeAsService (?)
Or the inverted excludeFromContainer.
but the issue is that such name is really related to the symfony configuration, and it might be weird on laravel side to have a useless option.
What's the benefit of $definition->setAbstract(true)->addTag('container.excluded', ['source' => 'by #[ApiResource] attribute']); for dto ?
Also, couldn't it be automatically detected/added only if the class is not already registered/autowired (as a service/controller) (?)
But given the "wrong" use I did with ApiResource to document some controller route, I wonder if the right solution wouldn't to expose another dedicated attribute for my usage (which could be used on Controller class or directly on a route) like #[ApiRoute] (?)
|
Would marking the services private by default result in having the services available at the moment the controller is wired to the API Platform? Maybe the issue isn't that the service should be kept available, but maybe the issue is that Symfony's compiler pass that removes unused services ran too early? A simple fix could then be to increase the priority of APIP's logic that wires the services, in order to prevent the exception from occurring. |
|
Closing as @VincentLanglet found the right path: #7402 (comment) |
3 participants
Since #6943, classes with
#[ApiResource]attribute are excluded from the Symfony DIC. But that was without considering that a resource class could be a controller service and not a DTO. With this new option on the attribute, you can enable or restore the old behavior for a class.