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

Create an interface to resolve the operations path #666

Merged
merged 1 commit into from Aug 16, 2016
Merged

Create an interface to resolve the operations path #666

merged 1 commit into from Aug 16, 2016

Conversation

GuilhemN
Copy link
Contributor

@GuilhemN GuilhemN commented Aug 3, 2016

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

This PR solves an issue of the swagger DocumentationNormalizer which doesn't include resources if they don't have at least one collection operation (that's the case when a resource has only item operations).
I finally choose a different solution than the one I proposed in #648 (comment) and created a new interface OperationPathResolverInterface. It replaces the current ResourcePathNamingStrategyInterface.

$routeCollection->get('api_dummies_get_item'),
$this->getRoute('/dummies/{id}.{_format}', 'api_platform.action.get_item', DummyEntity::class, 'get', ['GET'])
$this->getRoute('/dummies/{id}.{_format}', 'api_platform.action.get_item', DummyEntity::class, 'get', ['GET']),
$routeCollection->get('api_dummies_get_item')
Copy link
Contributor Author

@GuilhemN GuilhemN Aug 3, 2016

Choose a reason for hiding this comment

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

I did this because the expected value must be before the one tested.

@dunglas
Copy link
Member

dunglas commented Aug 6, 2016

ping @api-platform/core-team

@Simperfit
Copy link
Contributor

LGTM
ping @theofidry @teohhanhui @sroze

@dunglas
Copy link
Member

dunglas commented Aug 7, 2016

Dirty for the delay, I prefer to review it in depth or have the opinion of another member of the core team before merging it.

@GuilhemN
Copy link
Contributor Author

GuilhemN commented Aug 7, 2016

@theofidry reacted to @Simperfit comment, i guess that means he agrees ?
As long as you don't want to tag a new stable version you have the time to review this :)

@@ -35,12 +35,7 @@ public function getConfigTreeBuilder()
->scalarNode('title')->defaultValue('')->info('The title of the API.')->end()
->scalarNode('description')->defaultValue('')->info('The description of the API.')->end()
->scalarNode('version')->defaultValue('0.0.0')->info('The version of the API.')->end()
->arrayNode('naming')
Copy link
Contributor

Choose a reason for hiding this comment

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

we need to update the doc accordingly as well

@theofidry
Copy link
Contributor

👍 from me but I would be more confortable if @teohhanhui or @dunglas have time for a deeper review :)

@@ -13,7 +13,7 @@
<argument type="service" id="api_platform.metadata.property.metadata_factory" />
<argument type="service" id="api_platform.resource_class_resolver" />
<argument type="service" id="api_platform.operation_method_resolver" />
<argument type="service" id="api_platform.iri_converter" />
<argument type="service" id="api_platform.path_resolver.operation" />
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 the service be named api_platform.operation_path_resolver for consistency with other services?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes indeed, good point 👍

Copy link
Member

Choose a reason for hiding this comment

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

Can you update the PR? I'll merge it after that.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

@dunglas
Copy link
Member

dunglas commented Aug 16, 2016

I've just reviewed it in deep. Smart design!

I've just a minor comment regarding the service name. WDYT @Ener-Getick?

@GuilhemN
Copy link
Contributor Author

Thanks !

And i updated the services name :)

@dunglas
Copy link
Member

dunglas commented Aug 16, 2016

Test are broken now.

@GuilhemN
Copy link
Contributor Author

Oops i forgot to change a service name in the tests...

@dunglas dunglas merged commit 0778893 into api-platform:master Aug 16, 2016
@dunglas
Copy link
Member

dunglas commented Aug 16, 2016

Thank you @Ener-Getick!

@GuilhemN GuilhemN deleted the CACHE branch August 16, 2016 08:52
@dunglas
Copy link
Member

dunglas commented Aug 16, 2016

@Ener-Getick do you think you'll be able to also update the related docs? https://github.com/api-platform/docs/blob/master/core/path-naming-strategy.md

@GuilhemN
Copy link
Contributor Author

@dunglas yes it shouldn't be too long. I'll do that asap ;)

@dunglas
Copy link
Member

dunglas commented Aug 16, 2016

Thanks!

@teohhanhui
Copy link
Contributor

teohhanhui commented Aug 16, 2016

I don't like the name CustomOperationPathResolver. Perhaps we can change it to DelegatedOperationPathResolver (suggestions welcome)? And $deferred is a misnomer, as it should be $delegate.

@dunglas
Copy link
Member

dunglas commented Aug 16, 2016

I like DelegatedOperationPathResolver. WDYT @Ener-Getick?

@GuilhemN
Copy link
Contributor Author

The advantage of CustomOperationPathResolver is that we know it resolves the path from a custom field. It's not clear to me what DelegatedOperationPathResolver does.
I don't like this name much as well but i don't have a better idea :/

@GuilhemN
Copy link
Contributor Author

GuilhemN commented Aug 16, 2016

Maybe something relating to metadata? (Custom)MetadataOperationPathResolver
Or ExplicitOperationPathResolver?

@teohhanhui
Copy link
Contributor

teohhanhui commented Aug 16, 2016

@Ener-Getick:

The advantage of CustomOperationPathResolver is that we know it resolves the path from a custom field.

We should not care whether it's "custom" or otherwise, because such a distinction does not matter at the class level. But yes, the service name should reflect the purpose (i.e. resolving based on operations config in resource metadata).

It's not clear to me what DelegatedOperationPathResolver does.

It delegates to OperationPathResolverInterface.

@teohhanhui
Copy link
Contributor

Ok I've misunderstood...

@GuilhemN
Copy link
Contributor Author

DelegatedOperationPathResolver makes me think it is delegated.
Of course this resolver delegates to another resolver but that's not its main purpose, that's just a fallback. That's why i think its name should reflect the source it uses to resolve a path.

<argument type="service" id="api_platform.operation_path_resolver.custom" />
</service>

<service id="api_platform.operation_path_resolver.custom" class="ApiPlatform\Core\PathResolver\CustomOperationPathResolver" public="false">
Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't api_platform.operation_path_resolver.custom decorate api_platform.operation_path_resolver.default?

(Why do we need the "default" part of the name, in the first place? This was already discussed before in #547)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It would be weird to decorate a service defined by the user in case he uses its own path resolver, don't you think ?

About the default part, that's just an alias and i couldnt use .operation_path_resolver as it is already in use. Maybe a better name would be .fallback or .root?

Copy link
Contributor

Choose a reason for hiding this comment

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

We need to be clear about the decoration priority, but by not using Symfony DI's service decoration (when in fact it's exactly what you're trying to achieve), the current implementation is clearly inflexible.

It would be weird to decorate a service defined by the user in case he uses its own path resolver, don't you think ?

I'll address this separately.

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

5 participants