Closed jlamur closed 3 years ago
I think it's a great idea, not sure why it wasn't done like that in the first place. Maybe the options resolver wasn't that well known at the time?
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
There was some discussions about this:
Some options are global: type
, template
, role
, ...
Some options are specific: inverse
for boolean type, currency
, route
for url type, ...
Custom option could be possible for custom FieldDescription. I could indeed create a type Amount
with an option show_currency: bool
to display or not the currency.
So I'm not sure we can use an option resolver, since we should allow every possible options.
Or we have to say that non-generic options should be in a key templateOptions
and this require a lot of BC-break.
Plus it's just moving the issue from options
to templateOptions
...
Subject
At the moment,
FieldDescription
options are used on-the-fly by templates. It could be great to have anOptionsResolver
to parse these options.Benefits
All the benefits of using an
OptionsResolver
(list options, require them, default values, validation rules, etc...). We could even imagine to generate documentation pages with the help of theOptionsResolver
.Implementation / BC
Because users / bundles may use some options not defined by sonata, we must provide a way to extends / add options to the
FieldDescription
of any type. Moreover, make it BC would be as simple as catching UndefinedOptionsException and throwing a deprecation instead.WDYT?