Skip to content
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

Improve order filter generated API doc #2971

Merged

Conversation

fredericbarthelet
Copy link
Contributor

Q A
Bug fix? no
New feature? yes
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets #2891
License MIT
Doc PR -

@fredericbarthelet fredericbarthelet force-pushed the improve-filter-generated-doc branch 2 times, most recently from ec560b4 to 9caa985 Compare August 7, 2019 14:58
Copy link
Member

@alanpoulain alanpoulain left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Is it used in the UI?

@fredericbarthelet
Copy link
Contributor Author

Yep
image
image

@@ -52,6 +52,10 @@ public function getDescription(string $resourceClass): array
'property' => $propertyName,
'type' => 'string',
'required' => false,
'enum' => [
strtolower(OrderFilterInterface::DIRECTION_ASC),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually the order filter parameter could also be used without a value, e.g. GET /books?order[datePublished]

It'd use the default order configured for that property. (I don't like it, but it's something that's supported.)

See Behat test scenario here:

Scenario: Get collection ordered by default configured order on a string property and on which order filter has been enabled in whitelist mode with default descending order

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It can be documented like this but could be used without value too, doesn't it?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Enum usually means you must use one of the specified values in the list. Haha...

Copy link
Contributor

@teohhanhui teohhanhui Aug 8, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, there is allowEmptyValue in OpenAPI v3 (it's also in Swagger v2). We could probably add that for other filters too, where applicable. But perhaps in another PR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this PR could be merged as is.

Copy link
Contributor

@teohhanhui teohhanhui Aug 8, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@alanpoulain See the other review comment above.

@fredericbarthelet fredericbarthelet force-pushed the improve-filter-generated-doc branch 3 times, most recently from a140df4 to b2f3ef3 Compare August 20, 2019 13:04
@dunglas
Copy link
Member

dunglas commented Aug 20, 2019

@teohhanhui can we merge this one?

@teohhanhui
Copy link
Contributor

Test is missing for the Swagger DocumentationNormalizer.

@fredericbarthelet
Copy link
Contributor Author

@dunglas @teohhanhui test added in DocumentationNormalizerV3Test

@teohhanhui teohhanhui merged commit 1c19bf5 into api-platform:master Aug 20, 2019
@teohhanhui
Copy link
Contributor

Thanks @fredericbarthelet! 🎉

@@ -52,6 +52,13 @@ public function getDescription(string $resourceClass): array
'property' => $propertyName,
'type' => 'string',
Copy link
Member

@dunglas dunglas Aug 20, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I think that we should deprecate type and required, in favor of schema (because JSON Schema already supports type and required). Using a JSON Schema to describe the filter is smart, and we should only support that. WDYT @teohhanhui?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that'll just make a lot of code more complicated...

@@ -690,6 +690,10 @@ private function getFiltersParameters(bool $v3, string $resourceClass, string $o
$type = \in_array($data['type'], Type::$builtinTypes, true) ? $this->jsonSchemaTypeFactory->getType(new Type($data['type'], false, null, $data['is_collection'] ?? false)) : ['type' => 'string'];
$v3 ? $parameter['schema'] = $type : $parameter += $type;

if ($v3 && isset($data['schema'])) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we do this test before calling $this->jsonSchemaTypeFactory->getType, in order to not call it when it's useless (when data['schema'] exists)? Also, are the provided schema incompatible with Swagger v2?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We already do useless work like this in many other places in this class. (At least it was the case before. Not sure after your refactoring.)

I guess it's okay in this case as it keeps the code as simple as possible.

Also, are the provided schema incompatible with Swagger v2?

It has no support for schema in parameters.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We already do useless work like this in many other places in this class. (At least it was the case before. Not sure after your refactoring.)

I tried to improve it as much as possible :)

I guess it's okay in this case as it keeps the code as simple as possible.

It doesn't increase the complexity that much:

                if ($v3 && isset($data['schema'])) {
                    $parameter['schema'] = $data['schema'];
                } else {
                 $type = \in_array($data['type'], Type::$builtinTypes, true) ? $this->jsonSchemaTypeFactory->getType(new Type($data['type'], false, null, $data['is_collection'] ?? false)) : ['type' => 'string'];
                $v3 ? $parameter['schema'] = $type : $parameter += $type;
              }

(it could probably be more simplified btw)

It has no support for schema in parameters.

It is supported: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#fixed-fields-7 (If in is "body":).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And because it is supported, the code can be simplified a lot:

$type = $data['schema'] ?? \in_array($data['type'], Type::$builtinTypes, true) ? $this->jsonSchemaTypeFactory->getType(new Type($data['type'], false, null, $data['is_collection'] ?? false)) : ['type' => 'string'];
$v3 ? $parameter['schema'] = $type : $parameter += $type;

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it's not supported. That's for the request body. We're talking about filters here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants