-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Form] DateIntervalType: Allow to configure labels & enhance form theme #20887
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
fabpot
merged 1 commit into
symfony:master
from
ogizanagi:feature/form/date_interval_labels_and_theme
Jan 11, 2017
+122
−16
Merged
Changes from all commits
Commits
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
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
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
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.
This can be simplified by
array_filter($labels)
.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.
No, because it'll filter any empty value (actually more accurratly: any entry that would be converted to
false
).In case someone simply want to disable the label, he'll set it to
false
. Butfalse
would be removed and thus would make it impossible to disable the label rendering from options.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.
@HeahDude : Do you think gathering the labels under a single option is a good idea or should I opt back for
label_x
options?#21002 is suggesting to translate
DateTimeType
subtypes labels and uses dedicated options. I guess it's coherent regarding other options actually, even if it'll looks ugly in the case of theDateIntervalType
. But I guess we should be consistent. WDYT?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 prefer your approach :). Problem is that it mostly depends on the widget we consider.
Having the possibility to define labels is great, mainly to translate them. It means we should be able to define all of them (and that would be consistent).
Also regarding performances, your approach should be better, using one normalizer for one array (even calling an
array_replace
and anarray_filter
) instead of defining many options. Resolving only one option involves cloning the resolver instance and many calls, so that must cost much more.In conclusion, I'd say maybe #20002 should follow what's implemented here, using
date_label
andtime_label
as string or array, so maybeDateType
andTimeType
should have alabels
option too.What do you and others think?
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 opted for this approach as it was my own preference, but expected negative feedbacks about it. Apparently it doesn't look that bad, so I'm satisfied 😅 .
Apart from perfs, IMHO segregating similar options is cluttering form types and makes documentation more complicated and verbose for no gain. Of course it depends of use cases and options, as it makes sense for most of them to be separated from each others in order to benefits of fine control over OptionResolver features like type/values validation and normalization. But even for some of them, a feature like #18134 would be interesting (with an extra cost, though).
My only fear was about consistency with other form types which opted for segregation and autocompletions with the Symfony plugin for PHPStorm for instance.