MultiValueField could be more convenient
|Reported by:||Aryeh Leib Taurog <vim@…>||Owned by:||nobody|
|Has patch:||no||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||no|
It seems to me that the MultiValueField could be a lot more useful. I'm assuming the SplitDateTimeField code exemplifies the normal use case, and I see two things here that bother me.
- To use MultiValueField, coder must create and assign a widget class. Maybe I'm just lazy because the other Field classes seem to provide reasonable defaults, but couldn't this field provide a reasonable default as well?
- compress must be defined on the Field class, but decompress must be defined on the Widget class. I don't know if I'd call this a violation of DRY, but it seems to me it would be much nicer to put these two together, since one is the inverse of the other. Obviously there's nothing preventing me from putting my MultiWidget subclass and MultiValueField subclass together, but if I separate the Widgets from the Fields, as the django source has done, then I introduce room for maintenance errors.
I guess this is mainly about convenience. We do like making good development practice more convenient.
My suggestion for addressing these two points is below. Thanks for reading.
from django.forms import fields from django.forms import widgets class MultiValueFieldWidgetDescriptor(object): def __get__(self, instance, owner): widget_base = getattr(owner, 'widget_base', widgets.MultiWidget) class MyWidget(widget_base): def __init__(self, attrs=None): widgets = [f.widget for f in instance.fields] super(MyWidget, self).__init__(widgets, attrs) decompress = owner.decompress.__get__(self) return MyWidget class MultiValueField(fields.MultiValueField): widget = MultiValueFieldWidgetDescriptor()