Interesting ideas! Scheduled for POST-2.1.

@ruimarinho The padded option must be removed as the issue in #3490 has now been resolved.

@fabpot, I'm going to setup a quick test page since the project where we needed this is running 2.1-dev and, since it's a seasonal project, it's not going to be upgraded to 2.1 beta or even 2.1 stable. I'll remove the padded option, test it and submit this with a new commit.

@ruimarinho Can you rebase this PR and update it according to the comments ?

@stof done - code fixed, including tests which have been rectified and are now passing. Removed the padded option which allowed me to keep this PR much simpler.

I'm going to add a new test case tomorrow to assert the validation of the widgets defined via the array notation. I look forward for your comments to see if I can improve that small code block using solely the OptionsResolver already available.

@bschussek Can we included this in 2.2?

@fabpot Yes we can, I really like this.

@ruimarinho Can you move the normalization of the "widget" option to an option normalizer? Basically you can do it the same way as in the $emptyValueNormalizer in DateType.

Furthermore, if we do this for DateType, we also need to implement the same features for DateTimeType and TimeType. Could add this?

To be precise, the same should be added to TimeType only. DateTimeType should then support the options date_options and time_options which are passed along to the date and time fields.

@bschussek I have moved the widget option processing to the normalizer and added the TimeType implementation counterpart. The normalizers share much of the same functionality, so maybe that can be improved.

Regarding DateTimeType, what do you think is the best approach to pass the widget options? You mention date_options and time_options, but I suppose those would eventually become ($part}_options on each widget?

An example of what I have in mind:

$builder->add('date', 'datetime', array(
    'date_widget'  => array(
        'year'  => 'text', 
        'month' => 'text', 
        'day'   => 'choice'
    ),
    'date_options' => array(
        'year' => array('attr' => array(
            'data-mask' => 'yyyy'
        ))
    )
));

Your last question is a good one. Apparently we currently use several different ways of passing options to fields:

(a) By introducing dedicated options

$builder->add('date', 'datetime', array(
    'date_widget'  => ...,
));

(b) By letting existing options accept arrays

$builder->add('date', 'date', array(
    'empty_value'  => array(
        'day' => ...,
    ),
));

(c) By letting the user pass all options himself

$builder->add('password', 'repeated', array(
    'first_options'  => ...,
));

I think we should clean this up, but the question is how.

The most efficient and flexible way is definitely (c), but it clutters up the API a bit.

So instead of

$builder->add('date', 'datetime', array(
    'date_widget'  => 'choice',
));

you'd then write

$builder->add('date', 'datetime', array(
    'date_options'  => array(
        'widget' => 'choice',
    ),
));

or

$builder->add('date', 'datetime', array(
    'date_options'  => array(
        'month_options' => array(
            'widget' => 'choice',
        ),
    ),
));

if you want to have even more fine-grained control, which is a little less concise than (a theoretical)

$builder->add('date', 'datetime', array(
    'widget'  => array(
        'date' => array(
            'month' => 'choice',
        ),
    ),
));

or even

$builder->add('date', 'datetime', array(
    'widget'  => array(
        'month' => 'choice',
    ),
));

What do you think?

I actually noticed that and I even got confused when accessing the values to merge the widget part options (year_options, etc).

Regarding the different options you presented:

a) Looks concise and practical, but not very extensible. As the widgets get more complex, the harder it gets to maintain this facade.

b) This option requires you to learn about which options can accept an array structure. Unless we can assure we always offer support for this kind of structure, I don't think it is as practical as option a). Plus, on the DateTime widget, the key would either have to be date_day or a nested array.

c) More verbose but also more explicit. Users should not have to learn anything new if they already know how to use the Date or Time widgets. Less practical (more nesting) but more flexible.

A more complex example that didn't feel awkward to write:

$builder->add('date', 'datetime', array(
    'date' => array(
        'widget' => array(
            'year'  => 'text',
            'month' => 'text',
            'day'   => 'choice'
        ),
        'options' => array(
            'year' => array(
                'attr' => array(
                    'data-mask'  => 'yyyy'
                )
            ),
            'month' => array(
                'attr' => array(
                    'data-month' => 'MM'
                )
            ),
            'day' => array(
                'attr' => array(
                    'data-day'   => 'dd'
                )
            )
        )
    ),
    'time' => array(
        'widget' => array(
            'hour'    => 'text',
            'minute'  => 'choice',
            'seconds' => 'choice'
        ),
        'hours'       => range(0, 12),
        'empty_value' => array(
            'hour'    => 10,
            'minute'  => 20,
            'seconds' => 30
        )
    )
));

I also think hours should be moved inside another key (data, initial_value, available_value, choice_value, ...) to visually reassemble the singular part definition. For instance:

$builder->add('time', 'time', array(
    'data' => array(
        'hour' => range(0, 12)
    )
));

What do you think?

Let's save the question about the hours option for a later PR.

Your API sample is ambiguous. First, you renamed *_options to *, e.g., date instead of date_options, year instead of year_options etc. This can be a good thing, but it breaks consistency with RepeatedType.

Second, you nested a key options inside date (which originally was date_options) and that obviously doesn't make sense.

I'm alright with solution c) but we need to decide whether to name the options date or date_options, and then we need to decide how to cascade this pattern in the other compound core types (i.e. types consisting of more than one field).

Closed in favor of #9177