Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[WIP] Refactored argument resolving out of the ControllerResolver#11457

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Closed

Conversation

@wouterj
Copy link
Member

QA
Bug fix?no
New feature?yes
BC breaks?yes
Deprecations?yes
Tests pass?yes
Fixed tickets#1547,#10710
LicenseMIT
Doc PRtbd

Todo

  • Write docs
  • Make BC
  • Add priority
  • Review

BC

I've done my best to make this BC. It is now fully BC except from one case: If the logic inControllerResolver#getArguments() is no longer used. If one would have used that method for custom argument resolving logic, it is no ignored. There should be a way that we can support both methods at the same time (in other words, create an argument resolver which uses the controller resolver).

Thanks

A huge thanks to@iltar for giving me the idea and helping me setting up this PR.

@wouterjwouterj changed the titlekernel-argument-resolvingRefactored argument resolving out of the ControllerResolverJul 23, 2014
@wouterjwouterj changed the titleRefactored argument resolving out of the ControllerResolver[WIP] Refactored argument resolving out of the ControllerResolverJul 23, 2014
@dawehner
Copy link
Contributor

This would work together with#10529 which does the same for the other part of it: the class/method resolving.

Copy link
Contributor

Choose a reason for hiding this comment

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

Usually methods like this namedsupports in the Symfony codebase.

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

SensioFrameworkExtraBundle, which did have this feature previously, usedsupports. We tried to stick as much as possible to the SensioFrameworkExtraBundle API, so the migration will be easy.

Copy link
Member

Choose a reason for hiding this comment

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

this should use$request->attributes->get() too

Copy link
Contributor

Choose a reason for hiding this comment

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

If i remember correct, normally methods like this are calledadd since they would logically only containArgumentResolverInterface instances.

@wouterjwouterjforce-pushed thekernel-argument-resolving branch from7a8cfae tob352992CompareFebruary 19, 2015 18:57
@wouterj
Copy link
MemberAuthor

I just revisited this PR for 3.0, as it was impossible to make a BC pull request. I've fixed the comments.

This could be made so generic that it will work for any callable (not just controllers). This would cover#10710

@wouterj
Copy link
MemberAuthor

What do core devs think about this PR?

  1. Continue and make it decoupled from controllers
  2. Continue the current direction, just as a replacement of SensioFrameworkExtraBundle's feature
  3. Stop worrying about this PR

@fabpot
Copy link
Member

@wouterj I would say 2

@wouterjwouterjforce-pushed thekernel-argument-resolving branch fromd30c01f to966ffe6CompareApril 6, 2015 15:17
@wouterjwouterjforce-pushed thekernel-argument-resolving branch from8e8c34c to416a33eCompareApril 9, 2015 11:54
@wouterj
Copy link
MemberAuthor

Why can't HHVM find the compiler pass class?

Copy link
Member

Choose a reason for hiding this comment

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

should be private

@stof
Copy link
Member

@wouterj I just thought about a BC way introduce the ArgumentResolver concept in Symfony: inject the ArgumentResolverManager inside the ControllerResolver for now (with a default value matching the current behavior) to be used in its existinggetArguments method.

This would allow to start using this extension point already.

Building an ArgumentResolver which would call the ControllerResolver old API would not allow to preserve BC, because you would not have BC forparent::getArguments()

@wouterj
Copy link
MemberAuthor

@stof this isn't FC for standalone usage, is it? As you have to pass the argument resolver manager with custom resolvers to ControllerResolver in 2.8 and to AppKernel in 3.0.

@wouterj
Copy link
MemberAuthor

Hmm, we can of course still pass the argument resolver manager to AppKernel and introduce a setArgumentResolverManager method in the ControllerResolver (which is called in AppKernel). This would fix that.

@wouterj
Copy link
MemberAuthor

Closing in favor of#14971

@wouterjwouterj deleted the kernel-argument-resolving branchJune 13, 2015 15:26
fabpot added a commit that referenced this pull requestApr 3, 2016
…iltar, HeahDude)This PR was merged into the 3.1-dev branch.Discussion----------Added an ArgumentResolver with clean extension point| Q             | A| ------------- | ---| Branch?       | master| Bug fix?      | no| New feature?  | yes| BC breaks?    | no| Deprecations? | yes| Tests pass?   | yes| Fixed tickets |#17933 (pre-work),#1547,#10710| License       | MIT| Doc PR        |symfony/symfony-docs#6422**This PR is a follow up for and blocked by:#18187**, relates to#11457 by@wouterj. When reviewing, please take the last commit: [Added an ArgumentResolver with clean extension point](4c092b3)This PR provides:- The ability to tag your own `ArgumentValueResolverInterface`. This means that you can effectively expand on the argument resolving in the `HttpKernel` without having to implement your own `ArgumentResolver`.- The possibility to cache away argument metadata via a new `ArgumentMetadataFactory` which simply fetches the data from the cache, effectively omitting 1 reflection call per request. *Not implemented in this PR, but possible once this is merged.*- The possibility to add a PSR-7 adapter to resolve the correct request, avoids the paramconverters- The possibility to add a value resolver to fetch stuff from $request->query- Drupal could simplify [their argument resolving](https://github.com/drupal/drupal/blob/8.1.x/core/lib/Drupal/Core/Controller/ControllerResolver.php) by a lot- etc.The aim for this PR is to provide a 100% BC variant to add argument resolving in a clean way, this is shown by the 2 tests: `LegacyArgumentResolverTest` and `ArgumentResolverTest`./cc@dawehner@larowlan if you have time, can you check the impact for Drupal? I think this should be a very simple change which should make it more maintainable.Commits-------1bf80c9 Improved DX for the ArgumentResolverf29bf4c Refactor ArgumentResolverTestcee5106 cs fixescfcf764 Added an ArgumentResolver with clean extension point360fc5f Extracting arg resolving from ControllerResolver
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

6 participants

@wouterj@dawehner@fabpot@stof@henrikbjorn@Koc

[8]ページ先頭

©2009-2025 Movatter.jp