-
-
Notifications
You must be signed in to change notification settings - Fork 9.7k
Fix form/data mapping for typehinted properties #36492
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
Closed
Closed
Changes from 1 commit
Commits
Show all changes
7 commits
Select commit
Hold shift + click to select a range
252dffc
Fix form mapping to uninitialized properties
ph-fritsche 0575980
Ignore uninitialized properties when mapping to form
ph-fritsche 6c3aaf2
Fix form mapping tests
ph-fritsche 39b4abe
Be specific about ignored AccessExceptions when mapping to form
ph-fritsche 19679dc
Fix test for old phpunit
ph-fritsche a975d5e
Fix test for symfony/property-access 2.8
ph-fritsche db718c0
Catch only UninitializedPropertyException when getting a value per Pr…
ph-fritsche File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Next
Next commit
Fix form mapping to uninitialized properties
- Loading branch information
commit 252dffcf62f7fe6c4ceab907093ab453f6e7228c
There are no files selected for viewing
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
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
8 changes: 8 additions & 0 deletions
8
src/Symfony/Component/Form/Tests/Fixtures/TypehintedPropertiesCar.php
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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,8 @@ | ||
<?php | ||
namespace Symfony\Component\Form\Tests\Fixtures; | ||
|
||
class TypehintedPropertiesCar | ||
{ | ||
public ?\stdClass $engine; | ||
public ?\stdClass $color; | ||
} |
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't we apply the same logic as above to not blindly silence all exceptions that could be thrown here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think there should be any exception for failed reading of a property when trying to write it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If there cannot be any exceptions, we shouldn't add the
catch
here to not hide any bugs IMO.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem is that the implementation tries to check for the current value before calling setValue.
One should be able to map a form with
bar=123
toFoo1
, but it will fail withUninitializedPropertyException
.One should be able to map a form with
baz=123
toFoo2
, but it will fail with aNoSuchPropertyException
.It is at least confusing and IMO a bug, that setting a value fails because reading it is not possible.
I decided against catching
Throwable
here, because e.g.RuntimeException
thrown byPropertyAccessor
points to bugs in the implementation with which one can not expect the consecutivesetValue()
to work.Maybe @HeahDude can give further insight, but as I understood the current implementation the
AccessException
types point to errors in a specific read or write access, while the other exeptions point to wrong usage ofPropertyAccessor
.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not against ignoring errors caused by uninitialized properties. I just think that ignoring any other errors that might happen is not the desired solution. I suggest to update the new method like this:
We can then reuse this method in the
setData()
call above like this:There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know. I guess I would rather open an issue first and gather some feedback.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ph-fritsche Do you still like to finish the PR though?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, of course. I was just waiting for the feedback in #36754.
That would replace the old bug by a new one as it sets data that is not there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am afraid I do not understand. What exactly would be the new bug you are talking about?
As far as I can see #36754 would be a new feature affecting
master
only. So I do not really see how that would affect this PR.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Mapper should transfer data from one representation to the other.
It should fail if it either can not do its job or if it can not guarantee a certain behavior.
The previous implementation introduced restrictions that are neither documented nor are intended. (They could not be, as the pivotal problem leading to this PR came through type hinted properties that didn't exist when the implementation was written.)
Now you could argue that supporting those new concepts is by itself a new feature - then one should close this PR and constrain the dependency to
PHP<7.4
.If one supports those, one should do it right. And that means that
I committed another change that disables using
mapFormToData()
with setters when the getter is missing, as you considered this a new feature.(Funny side note:
mapDataToForm()
works, if the setter is missing.)