-
-
Notifications
You must be signed in to change notification settings - Fork 838
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow custom processors
through tagged services
#2149
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you.
I like it. It works. But what if we want to add a processor in the middle of the list?
Could we register Generator
as a service and use constructor injection to add that service to ApiDocGenerator
? If so, we would be able to re-use Generator::addProcessor($$processor, ?string $before = null)
.
Thank you for your feedback! The 6.3.* test keep failing on me, but I think that's a general issue at the moment. I think as of now we have a generally working solution for custom processors in One thing I noticed though, is that a lot of what the API Docs Bundle does is abstracted away from the processors, particularly anything relating the That means, that while this is a nice addition for the Bundle in general, it would not solve #1721 for example, because you need access to the '@model' and refs to do that. I'm currently thinking about if we could find a way to pipe the ModelRegistry into a processor if needed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is awesome.
I think this is great. Thank you for working on this.
I think it should be in the scope of this PR to extend the Does that make sense? |
To answer my own question: Nope! I got it without touching the ModelRegister. The secret sauce is to use So this would be an example of the const X_QUERY_AGS_REF = 'query-args-explode';
public function __invoke(Analysis $analysis)
{
$this->analysis = $analysis;
/** @var OA\Parameter[] $schemas */
$parameters = $analysis->getAnnotationsOfType(OA\Parameter::class);
foreach ($parameters as $parameter) {
if ($parameter->x !== GENERATOR::UNDEFINED && array_key_exists(self::X_QUERY_AGS_REF, $parameter->x)) {
// Generate the name from the parameter schema.
$name = str_replace(OA\Components::SCHEMA_REF, '', $parameter->schema->ref);
$schema = Util::getSchema($this->analysis->openapi, $name);
}
}
} This would result into It was registered like this in a controller: #[OA\Parameter(
in: 'query',
name: 'query',
explode: true,
style: 'form',
schema: new OA\Schema(
type: 'object',
ref: new Model(
type: TeamFilter::class,
groups: ['read']
)
),
x: [
'query-args-explode' => true
]
)] So to reiterate: If you want to access
|
ApiDocGenerator.php
Outdated
/** | ||
* @param DescriberInterface[]|iterable $describers | ||
* @param ModelDescriberInterface[]|iterable $modelDescribers | ||
*/ | ||
public function __construct($describers, $modelDescribers, CacheItemPoolInterface $cacheItemPool = null, string $cacheItemId = null) | ||
public function __construct($describers, $modelDescribers, Generator $generator, CacheItemPoolInterface $cacheItemPool = null, string $cacheItemId = null) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the Generator parameter should be optional here aswell right? It would prevent making a potential breaking change.
public function __construct($describers, $modelDescribers, Generator $generator, CacheItemPoolInterface $cacheItemPool = null, string $cacheItemId = null) | |
public function __construct($describers, $modelDescribers, CacheItemPoolInterface $cacheItemPool = null, string $cacheItemId = null, Generator $generator = new Generator()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then we have to update the container registration as well. Just changing this line leads to an error.
I'm not quite sure how one would do that. Would it just be:
->setArguments([
new TaggedIteratorArgument(sprintf('nelmio_api_doc.describer.%s', $area)),
new TaggedIteratorArgument('nelmio_api_doc.model_describer'),
null,
null,
new Reference('nelmio_api_doc.open_api.generator'),
]);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ye that seems fine.
Co-authored-by: Djordy Koert <[email protected]>
I've tested this in a SF 6 application. It works as expected. Thank you! |
Thank you @Luehrsen 😄 |
This pull request aims to provide a solution to register custom processors for
swagger-php
through services with the tagswagger.processor
.fixes #2146