8000 [Form] Explain deprecation of `@Assert\Date` on `DateTimeInterface` fields · Issue #13998 · symfony/symfony-docs · GitHub
[go: up one dir, main page]
Skip to content

[Form] Explain deprecation of @Assert\Date on DateTimeInterface fields #13998

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

Jump to bottom
Closed
8000
ThomasLandauer opened this issue Jul 26, 2020 · 11 comments
Closed

[Form] Explain deprecation of @Assert\Date on DateTimeInterface fields #13998

ThomasLandauer opened this issue Jul 26, 2020 · 11 comments
Labels
Form Stalled

Comments

@ThomasLandauer
Copy link
Contributor

symfony/symfony#25015 gives this deprecation note:

DEPRECATION: Validating a \DateTimeInterface with "Symfony\Component\Validator\Constraints\Date" is deprecated since version 4.2. Use "Symfony\Component\Validator\Constraints\Type" instead or remove the constraint if the underlying model is already type hinted to \DateTimeInterface.

This fact should be explained at the corresponding Constraint pages, e.g. https://symfony.com/doc/current/reference/constraints/Date.html

Question: If you just rely on the ?\DateTimeInterface type-hint of the setter, and the user submits an invalid date in a form, how can you show a nice error message? What's the best practice here?
@xabbuh
Copy link
Member
xabbuh commented Jul 27, 2020

At the top of the linked page we have this paragraph:

Validates that a value is a valid date, meaning a string (or an object that can be cast into a string) that follows a valid YYYY-MM-DD format.

What would be your suggestion to make things even more clear?

@xabbuh xabbuh added the Form label Jul 27, 2020
@ThomasLandauer
Copy link
Contributor Author

I think there should be a "New in Version 4.2"-box explaining what the deprecation message says: Do not use this on an entity with \DateTimeInterface type-hinted setter.

But this immediately leads to the next question: What's the recommended way to show a nice error message to the users if they submit 1234-99-99 as date? Cause if you don't do anything, they will get blank page with error 500, right? (I know that the deprecation hasn't changed this, but it raises people's awareness about that question :-)

BTW: "follows a valid YYYY-MM-DD format." in your linked paragraph is ambiguous about what it does exactly: Just check that the submitted data follows this format (like 1234-99-99 does)? Or actually check if it refers to an existing day (i.e. 2020-02-31 fails)?

@apfelbox
Copy link
Contributor
apfelbox commented Jul 27, 2020 •
edited
Loading

As you are probably using a DateTimeType as form input, the transformation of this field will fail and your invalid_message will be shown: https://symfony.com/doc/current/reference/forms/types/datetime.html#invalid-message

No exception, as the form field ensures that the type is valid (if you configure it accordingly).

@ThomasLandauer
Copy link
Contributor Author

Thanks to @apfelbox, I'm now suggesting for the box:

Applying this constraint to a property with a \DateTimeInterface type-hinted setter is deprecated. Since validation is applied only after the setter was called, there's no need to check for a valid date/time again. If you want to show a nice error message in case a user enters an invalid date in a form, use https://symfony.com/doc/current/reference/forms/types/datetime.html#invalid-message

Should I come up with a PR? This message should be shown on all applicable pages (Date, DateTime, Time). Do you want to set up an include for that (don't know how to do that)?

BTW: Completely off-topic: In the first list (table of contents) on https://symfony.com/doc/current/reference/forms/types/datetime.html why are some items black and some blue?

@apfelbox
Copy link
Contributor
apfelbox commented Jul 27, 2020 •
edited
Loading

On one hand, it seems excessive to show that everywhere, on the other hand I have the feeling that invalid_message is pretty unknown (and hard to discover), so maybe it's worth it?

@javiereguiluz we need your wisdom / input here (or any of the other docs members 😄 ).

@xabbuh
Copy link
Member
xabbuh commented Jul 27, 2020

I am not convinced that adding this is really necessary. In general, adding more text often leads to people not reading everything. And if you are using the constraint with DateTime objects, the deprecation message is self-explanatory.

@ThomasLandauer
Copy link
Contributor Author

And if you are using the constraint with DateTime objects, the deprecation message is self-explanatory.

Well, not about invalid_message ;-)
Besides, the docs should educate people in advance, not lead them into fixing deprecation messages later on.

@sdespont
Copy link
Contributor
sdespont commented Dec 16, 2020 •
edited
Loading

Sorry to dig up an old subject, but it is not clear for me and I need a confrimation.

By

Use "Symfony\Component\Validator\Constraints\Type" instead

you mean something like this right?

        - Type:
            type: DateTime
            groups: [person]

@carsonbot
Copy link
Collaborator

Thank you for this issue.
There has not been a lot of activity here for a while. Has this been resolved?

@carsonbot
Copy link
Collaborator

Could I get an answer? If I do not hear anything I will assume this issue is resolved or abandoned. Please get back to me <3

@carsonbot
Copy link
Collaborator

Hey,

I didn't hear anything so I'm going to close it. Feel free to comment if this is still relevant, I can always reopen!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Form Stalled
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@sdespont @apfelbox @ThomasLandauer @xabbuh @carsonbot
0