Skip to content

Allow to define a specific controller value resolver #48927

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.

Sign up for GitHub

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

Jump to bottom
Closed
marforon opened this issue Jan 9, 2023 · 0 comments · Fixed by #48992
Closed

Allow to define a specific controller value resolver #48927

marforon opened this issue Jan 9, 2023 · 0 comments · Fixed by #48992
Labels
Feature HttpKernel

Comments

@marforon
Copy link

marforon commented Jan 9, 2023

Description

As part of the recent bug, I would like to propose a new feature to specify a specific controller value resolver which should be forced instead of iterating the whole stack of value resolvers.

I have multiple reasons for this:

  1. bad performance architecture - each value resolver might be iterated until the first is used. I understand it's simple to use, but we don't have to break the current system, we can just add a possibility to skip the iteration
  2. we shouldn't embrace a priority system for third-party bundles - a bundle "A" might setup its value resolver to some priority, but a bundle "B" might setup the same priority, there is no way to predict all cases to not create some type of collision, each bundle should be able to define a specific value resolver and be sure it will be always used
  3. Sensio Extra Bundle had this ability to specify a converter which was always used instead of priority

Example

public function __invoke(Request $request, #[ValueResolver(EntityValueResolver::class)] Entity $entity): Response
{
...
}

or for a different resolver:

public function __invoke(Request $request, #[ValueResolver(SerializerValueResolver::class)] Entity $entity): Response
{
...
}
@xabbuh xabbuh changed the title [HttpClient] Allow to define a specific controller value resolver Allow to define a specific controller value resolver Jan 10, 2023
@MatTheCat MatTheCat mentioned this issue Jan 16, 2023
Merged
nicolas-grekas added a commit that referenced this issue Mar 6, 2023
@nicolas-grekas
feature #48992 [HttpKernel] Introduce pinnable value resolvers with `…
b6bf9de 
…#[ValueResolver]` and `#[AsPinnedValueResolver]` (MatTheCat)

This PR was merged into the 6.3 branch.

Discussion
----------

[HttpKernel] Introduce pinnable value resolvers with `#[ValueResolver]` and `#[AsPinnedValueResolver]`

| Q             | A
| ------------- | ---
| Branch?       | 6.3
| Bug fix?      | no
| New feature?  | yes
| Deprecations? | no
| Tickets       | Fix #48927
| License       | MIT
| Doc PR        | symfony/symfony-docs#17763

Introducing a new `ValueResolver` attribute, which allows to
- “pin” a value resolver to an argument, meaning only said resolver will be called
- prevent a resolver to be called for an argument

Every existing resolver-related attribute (`MapEntity`, `CurrentUser`…) now extends `ValueResolver`.

Each `controller.argument_value_resolver` tag is added a `name` attribute, which is the resolver’s FQCN. This is the first argument `ValueResolver` expects.

A new  `AsPinnedValueResolver` attribute is added for autoconfiguration, adding the `controller.pinned_value_resolver` tag. Such resolvers can only be “pinned”, meaning they won’t ever be called for an argument missing the `ValueResolver` attribute.

Commits
-------

245485c [HttpKernel] Introduce pinnable value resolvers with `#[ValueResolver]` and `#[AsPinnedValueResolver]`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Feature HttpKernel
Projects
None yet
Milestone
No milestone
4 participants
@nicolas-grekas @xabbuh @carsonbot @marforon