Validate the extended type for lazy-loaded type extensions #15743
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| @@ -9,6 +9,7 @@ CHANGELOG | |||
| * deprecated the "cascade_validation" option in favor of setting "constraints" | |||
| with the Valid constraint | |||
| * moved data trimming logic of TrimListener into StringUtil | |||
| * [BC BREAK] When registering a type extension through the DI extension, the tag alias has to match the actual extended type. | |||
There was a problem hiding this comment.
tag alias or the service id (if we don't intend to fallback to the service id, it should be deprecated)
There was a problem hiding this comment.
the service id makes no sense as there could only be one extension for a type (as the service ids need to be unique). So IMO this fallback really needs to be deprecated, making the "alias" required in the future.
There was a problem hiding this comment.
yeah, this really does not make sense for extensions
|
@symfony/deciders anything else needed here ? |
169e965 to
8db6880
Compare
|
I fixed the component tests by adding the necessary dev dependency to be able to test the DI extension. |
|
👍 |
| // validate result of getExtendedType() to ensure it is consistent with the service definition | ||
| if ($extension->getExtendedType() !== $name) { | ||
| throw new InvalidArgumentException( | ||
| sprintf('The extended type specified for the service "%s" does not match the actual extended type. Expected "%s", given "%s"', |
There was a problem hiding this comment.
Missing dot at the end of the sentence.
|
👍 |
8db6880 to
8826d39
Compare
|
Thank you @stof. |
fabpot
added a commit
that referenced
this pull request
Sep 15, 2015
…ions (stof) This PR was merged into the 2.8 branch. Discussion ---------- Validate the extended type for lazy-loaded type extensions | Q | A | ------------- | --- | Bug fix? | no | New feature? | not really | BC breaks? | yes, but only for broken setups | Deprecations? | no | Tests pass? | yes | Fixed tickets | n/a | License | MIT | Doc PR | n/a Symfony 2.1 introduced such validation for form types because a mismatch would actually break the logic (the name is accessed again later). This was not added for type extensions because in such case, ``getExtendedType`` would actually never be used for extensions loaded by the DI extension (this method is only used inside extensions, and the DI extension relies on the service configuration instead). However, having mismatching values there would make debugging much harder, and can hide mistakes (see #15740 for such a mistake being fixed in the core). It also means that it might be hard to fix usage of deprecated APIs as the code might not contain the same extended type than the one used in the fullstack usage. Commits ------- 8826d39 Validate the extended type for lazy-loaded type extensions
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Symfony 2.1 introduced such validation for form types because a mismatch would actually break the logic (the name is accessed again later).
This was not added for type extensions because in such case,
getExtendedTypewould actually never be used for extensions loaded by the DI extension (this method is only used inside extensions, and the DI extension relies on the service configuration instead). However, having mismatching values there would make debugging much harder, and can hide mistakes (see #15740 for such a mistake being fixed in the core). It also means that it might be hard to fix usage of deprecated APIs as the code might not contain the same extended type than the one used in the fullstack usage.