Different attributes for DateInput and TimeInput in SplitDateTimeWidget

[slink <gabor@…>]

Current implementation of SplitDateTimeWidget accepts an attrs dictionary and passes it to both DateInput and TimeInput widgets. It would be nice if widgets may have different attributes while attrs still applies to both.

For instance:

widget = SplitDateTimeWidget(attrs={'class': 'input-field'},
                             date_attrs={'dojoType': 'dijit.form.DateTextBox'},
                             time_attrs={'dojoType': 'dijit.form.DateTextBox'})

[Anssi Kääriäinen]

I think time_attrs and date_attrs need to be last in the init argument list for backwards compatibility, it is possible that the init is called in this way

SplitDateTimeWidget({'foo': 'bar'}, 'date_format_string', 'time_format_string')

This patch will of course break that usage.

[slink <gabor@…>]

Replying to akaariai:

I think time_attrs and date_attrs need to be last in the init argument list for backwards compatibility, it is possible that the init is called in this way

SplitDateTimeWidget({'foo': 'bar'}, 'date_format_string', 'time_format_string')

This patch will of course break that usage.

You're right. They should be in the end of the argment list.

[Anssi Kääriäinen]

Looks good to me. Now this ticket needs tests and documentation. I am marking this as DDN, although I can't see a reason not to accept this. But I don't know if I am allowed to accept this ticket...

There is also a question about if things defined in attrs should override date_attrs (as current patch implements it) or if it should be the other way. It feels more logical that the more specific dict is preferred, that is attributes in date_attrs should override attributes in attrs. However this doesn't seem too important, and is probably fine as is. I can't think of a use case where this would be a problem.

[Julien Phalip]

This is in fact a duplicate of #5851. Note that the latest suggested approach is to add this functionality in a more general way inside MultiWidget.