@bschussek Any news about this?

@blaugueux Not yet. Maybe this can be tackled in 2.2.

@bschussek if you can guide me thru this I could help out and implement the changes, seeing this is a long standing issue.

Thanks!

@bschussek ping on this issue.

@dlsniper Have you done any work on this?

@mtotheikle sorry, I didn't got any answer from @bschussek and currently I'm pretty booked as well for at least one more month. If you can do it, go ahead :)

Regards.

If this hasn't been started I may be able to look at it over the next week or so, but would need some ideas for how it should be implemented.

Any ideas @dlsniper?

@bschussek does OptionResolver really need this feature? Should be great but can remove the simplicity of the component too.

After a year or so, what is your opinion about this PR?

I think it would be useful. There is a few array options in the form component which would benefit from it attr or the options option of the CollectionType for instance

I agree with both of you. It's useful, but it's hard to implement while still keeping everything simple.

We can give a try, we'll see if things can keep simple. Otherwise the produced code would be re arranged in another component with OptionsResolver as a dependency for example.

any news on this feature? I'm have a similar problem with the attr option in the symfony2 forms, default attr options get overwriten by attributes set in the formConfig

One thing I can think of at this moment is to add setNestedOption(array $options) where the name is the option and the value is an OptionsResolver instance.

$optionsResolver = new OptionsResolver();
$nestedOptionsResolver = new OptionsResolver();

$optionsResolver->setNestedOption(array('option_nested' => $nestedOptionsResolver));

When an value with key 'option_nested' is passed to $optionsResolver->resolve() it will delegate the values to the nested options resolver which will then resolve them.

One minor detail is parent dependency, as some options are lazy evaluated with a Closure they/may should have access to the parent options resolver to check some values for the final value.

And compatibility, we cant expend the Interface as this a BC, so we should either introduce an additional interface or come-up with a with way to reuse the current interface.

I'm new to symfony and the open source community, so I'm not certain about protocol here. And I don't fully understand how this resolver works. But I would very much like to see setDefaults work on nested arrays, so that I can pass in options that are grouped in a sane way (rather than all on the same single level), e.g.

$resolver->setDefaults(array(
'options' => array(
    'enableField'       => array(
        'title'         => FALSE,
        'versionNotes'  => FALSE,
        'timeCustom'    => FALSE
),
    'enableAction'      => array(
        'publish'       => FALSE
    ),
    'enableEntity'      => array(
        'viewSettings'  => FALSE,
        'content'       => FALSE
    )
));

Currently OptionsResolver#resolve() does a foreach() through the options and does a set() which calls Options#overload. So why doesn't overload check if an option is an array and do an array_replace_recursive?

@chadwickmeyer is not not only about defaults. It is also about all the logic resolving options. And we cannot simply make it recurse when it finds an array. This would break existing cases where options are accepting arrays as values (for instance choices or valdiation_groups) rather than as a set of nested options, and so must not be merged with the previous default.
We need to find a way to let the option resolver know that it is a nested option.

Thanks for responding. If I knew the whole system better, I would love to offer my help. But I am not qualified yet to understand the big picture (which is required to implement this feature). For the time being I found another way to do the merging in my application, and then I send all the defaults and the custom values to the form builder, since they have already been merged in my application .

This might be overly simplistic, but wouldn't it suffice to automatically resolve an OptionsResolver that is used as a default value? E.g.:

$nested3rdLevel = new OptionsResolver();
$nested3rdLevel->setDefault('3rd', 1);

$nested2ndLevel = new OptionsResolver();
$nested2ndLevel->setDefault('2nd', $nested3rdLevel);

$nested1stLevel = new OptionsResolver();
$nested1stLevel->setDefault('1st', $nested2ndLevel);

$options = $nested1stLevel->resolve([]); //  ["1st" => ["2nd" => ["3rd" => 1]]]

The only bc-break this would introduce is that an OptionsResolver could not be used as a default value (though this could be fixed by using some internal flag). Which seems to me, is a rare use-case anyway.

I actually have a (seemingly) working implementation for the above (minus access to the parent resolver), though I wanted to first ask if this approach would be acceptable at all?

I will close this issue. It's been open for a while and I don't think that this is something that the OptionsResolver really should support. I also don't see a way to do this without making the implementation overly complex.

For all interested: I've found this package sauls/options-resolver which does support deep options resolving by dot.notation in configuration.

See #27291 for full implementation of the initial request. Could this request be reopened, please?