Skip to content

[Form] TransformationFailedException: Support specifying message to display #20978

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

Merged
merged 1 commit into from
Mar 27, 2019
Merged

[Form] TransformationFailedException: Support specifying message to display #20978

merged 1 commit into from
Mar 27, 2019

Conversation

ogizanagi
Copy link
Contributor

@ogizanagi ogizanagi commented Dec 18, 2016

Q A
Branch? master
Bug fix? no
New feature? yes
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets #22501
License MIT
Doc PR N/A

Currently, a failed transformation can't display a very accurate message, as it only uses the value of the invalid_message option. I suggest to add more flexibility, somehow the same way we did for CustomUserMessageAuthenticationException.

A test case in FormTypeTest shows a use-case based on @webmozart's blog post about value/immutable objects in Symfony forms.

I named the exception properties and methods the same way as for CustomUserMessageAuthenticationException, but do you think the followings would be better:

  • setSafeMessagesetInvalidMessage
  • getMessageKeygetInvalidMessageKey
  • getMessageDatagetInvalidMessageParameters

in order to echoes invalid_message and invalid_message_parameters options?

=> Replaced to use invalidMessage & invalidMessageParameters

@nicolas-grekas nicolas-grekas added this to the 3.x milestone Dec 26, 2016
@ogizanagi
Copy link
Contributor Author

@HeahDude : Is it worth working again on this PR or should I wait your propositions about #20978 (comment) ?

@HeahDude
Copy link
Contributor

HeahDude commented Jul 6, 2017

Yes, I suggest to wait :).

@nicolas-grekas
Copy link
Member

Moving to 4.1. Rebase on master needed, where PHP 7.1 features can be used btw.

@nicolas-grekas nicolas-grekas modified the milestones: 3.4, 4.1 Oct 8, 2017
@fabpot
Copy link
Member

fabpot commented Mar 31, 2018

@HeahDude Any ways we can unblock this PR?

@nicolas-grekas nicolas-grekas modified the milestones: 4.1, next Apr 20, 2018
@xabbuh
Copy link
Member

xabbuh commented Sep 15, 2018

What about allowing the option to be a closure that would get passed the transformation failure exception and would return the error message to use?

@ogizanagi
Copy link
Contributor Author

@xabbuh : Would you remove the safe message in favor of more specific TransformationFailedException instances then? I'm fine with both solutions, but I thing the safe message approach is more convenient than creating a dedicated exception and treat it in each form type invalid_message option when relevant.

@xabbuh
Copy link
Member

xabbuh commented Oct 9, 2018

After thinking about it again I think having a message key in the exception isn't such a bad idea. It's also consistent with what we support in the Security component.

@ogizanagi ogizanagi closed this Oct 31, 2018
@ogizanagi ogizanagi deleted the feature/form/trans_failed_ex_safe_message branch October 31, 2018 17:41
@nicolas-grekas nicolas-grekas modified the milestones: next, 4.2 Nov 1, 2018
@ogizanagi ogizanagi restored the feature/form/trans_failed_ex_safe_message branch November 5, 2018 23:23
@ogizanagi ogizanagi reopened this Nov 5, 2018
@ogizanagi
Copy link
Contributor Author

Woops. I've closed this one by mistake.

@nicolas-grekas
Copy link
Member

rebase needed. for which branch is this PR?

@ogizanagi ogizanagi removed this from the 4.2 milestone Nov 9, 2018
@ogizanagi ogizanagi added this to the next milestone Nov 9, 2018
@ogizanagi ogizanagi changed the base branch from 3.4 to master November 9, 2018 07:30
@ogizanagi
Copy link
Contributor Author

Rebased on master

@@ -1050,7 +1050,13 @@ private function modelToNorm($value)
$value = $transformer->transform($value);
}
} catch (TransformationFailedException $exception) {
throw new TransformationFailedException('Unable to transform value for property path "'.$this->getPropertyPath().'": '.$exception->getMessage(), $exception->getCode(), $exception);
throw new TransformationFailedException(
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 kept on one line

Copy link
Member

Choose a reason for hiding this comment

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

also, not sure if we really need this change

Copy link
Contributor Author

Choose a reason for hiding this comment

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

not sure if we really need this change

Well, we need to forward the invalid message and parameters to the new exception, otherwise it's just vanished. What did you mean?

@fabpot
Copy link
Member

fabpot commented Mar 24, 2019

@ogizanagi @HeahDude I think we need to take a decision here. Finish/merge or close?

Copy link
Contributor Author

@ogizanagi ogizanagi left a comment

Choose a reason for hiding this comment

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

I still think this is valuable and doesn't bring much complexity.

@@ -1050,7 +1050,13 @@ private function modelToNorm($value)
$value = $transformer->transform($value);
}
} catch (TransformationFailedException $exception) {
throw new TransformationFailedException('Unable to transform value for property path "'.$this->getPropertyPath().'": '.$exception->getMessage(), $exception->getCode(), $exception);
throw new TransformationFailedException(
Copy link
Contributor Author

Choose a reason for hiding this comment

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

not sure if we really need this change

Well, we need to forward the invalid message and parameters to the new exception, otherwise it's just vanished. What did you mean?

@ogizanagi
Copy link
Contributor Author

(PR rebased)

@fabpot
Copy link
Member

fabpot commented Mar 27, 2019

Thank you @ogizanagi.

@fabpot fabpot merged commit d11055c into symfony:master Mar 27, 2019
fabpot added a commit that referenced this pull request Mar 27, 2019
…ng message to display (ogizanagi)

This PR was merged into the 4.3-dev branch.

Discussion
----------

[Form] TransformationFailedException: Support specifying message to display

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #22501
| License       | MIT
| Doc PR        | N/A

Currently, a failed transformation can't display a very accurate message, as it only uses the value of the `invalid_message` option. I suggest to add more flexibility, somehow the same way we did for `CustomUserMessageAuthenticationException`.

A test case in `FormTypeTest` shows a use-case based on @webmozart's [blog post about value/immutable objects in Symfony forms](https://webmozart.io/blog/2015/09/09/value-objects-in-symfony-forms/).

~I named the exception properties and methods the same way as for `CustomUserMessageAuthenticationException`, but do you think the followings would be better:~

- ~`setSafeMessage` ➜ `setInvalidMessage`~
- ~`getMessageKey` ➜ `getInvalidMessageKey`~
- ~`getMessageData` ➜ `getInvalidMessageParameters`~

~in order to echoes `invalid_message` and `invalid_message_parameters` options?~

=> Replaced to use `invalidMessage` & `invalidMessageParameters`

Commits
-------

d11055c [Form] TransformationFailedException: Support specifying message to display
@ogizanagi ogizanagi deleted the feature/form/trans_failed_ex_safe_message branch March 27, 2019 06:53
@nicolas-grekas nicolas-grekas modified the milestones: next, 4.3 Apr 30, 2019
@fabpot fabpot mentioned this pull request May 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants