Skip to content

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.

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

Closed
wants to merge 7 commits into from
Closed

Fix form/data mapping for typehinted properties #36492

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 Apr 19, 2020
0575980
Ignore uninitialized properties when mapping to form
ph-fritsche Apr 19, 2020
6c3aaf2
Fix form mapping tests
ph-fritsche Apr 19, 2020
39b4abe
Be specific about ignored AccessExceptions when mapping to form
ph-fritsche Apr 19, 2020
19679dc
Fix test for old phpunit
ph-fritsche Apr 24, 2020
a975d5e
Fix test for symfony/property-access 2.8
ph-fritsche Apr 24, 2020
db718c0
Catch only UninitializedPropertyException when getting a value per Pr…
ph-fritsche May 19, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Be specific about ignored AccessExceptions when mapping to form
  • Loading branch information
@ph-fritsche
ph-fritsche committed Apr 19, 2020
commit 39b4abe0d9e7248b45a75b430e174f1d1d0e26a1
7 changes: 7 additions & 0 deletions src/Symfony/Component/Form/Extension/Core/DataMapper/PropertyPathMapper.php
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -14,6 +14,7 @@
use Symfony\Component\Form\DataMapperInterface;
use Symfony\Component\Form\Exception\UnexpectedTypeException;
use Symfony\Component\PropertyAccess\Exception\AccessException;
use Symfony\Component\PropertyAccess\Exception\UninitializedPropertyException;
use Symfony\Component\PropertyAccess\PropertyAccess;
use Symfony\Component\PropertyAccess\PropertyAccessorInterface;

Expand Down Expand Up @@ -51,6 +52,12 @@ public function mapDataToForms($data, $forms)
$form->setData($this->propertyAccessor->getValue($data, $propertyPath));
} catch (AccessException $e) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we should either target 3.4 and/or catch the new UninitializedPropertyException.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I changed the target branch to 3.4.
I'm not sure if catching UninitializedPropertyException provides an advantage over the broader AccessException here. Is there a scenario in which catching the other possible AccessExceptions is harmful in the light of a flexible implementation?

Copy link
Contributor

Choose a reason for hiding this comment

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

The advantage is that the AccessException can be used internally by the PropertyAccess component for a "broader" usage, which should not be covered here.

Copy link
Contributor

Choose a reason for hiding this comment

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

And yes it could lead to bug because the form should break as misconfigured so the dev can fix it, because a property is not readable/writable as it should.
That's why I think we really should consider master instead and consider this a new feature unlocked by the new exception (that was my original intent, but I'm glad you opened that PR :)).

Copy link
Contributor

Choose a reason for hiding this comment

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

Another solution for targeting 3.4 would be to check the exception message to ensure the catch is legit.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

How do you think about this?

if (!$e instanceof UninitializedPropertyException
    // For versions without UninitializedPropertyException check the exception message
    && (\class_exists(UninitializedPropertyException::class) || false === \strpos($e->getMessage(), 'You should initialize it'))
) {
    throw $e;
}

Copy link
Contributor

Choose a reason for hiding this comment

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

We would only need to check the message in 3.4 and then when merging branches up, use the type check in master instead. No need for more complexity here in your patch.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

For 3.4 the type is never available with the current dependency constraint.
For 4.4, 5.0 and master it might be available.
I think we need to keep both checks in place until that dependency is bumped.

// Skip unitialized properties on $data
if (!$e instanceof UninitializedPropertyException
// For versions without UninitializedPropertyException check the exception message
&& (class_exists(UninitializedPropertyException::class) || false === strpos($e->getMessage(), 'You should initialize it'))
) {
throw $e;
}
}
} else {
$form->setData($config->getData());
Expand Down
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy