G
George Sakkis
Didn't have much luck in the Django list, so I'm posting it here just
in case anyone has come up with this problem.
Django maintains two parallel hierarchies of field classes, one related
to models that correspond to table columns and one that maps these
fields to forms. This works ok for the admin interface and in many
typical cases, but what if one wants to have an alternative or
additional widget associated to a field ? For instance, say I have a
"birthday" DateField that I want to render as a date range widget in a
search form ("From - Up to"). What I did so far was a DateRangeField
subclass of DateField and overrode the necessary methods. This works
for rendering the form but breaks several other things (e.g. in the
admin interface I still want to show the field as regular DateField
widget, not a range; also the backend knows nothing about how to map a
DateRangeField to a table column). Any ideas on how to decouple the
field from its widget(s), even by tweaking/patching Django itself ?
George
in case anyone has come up with this problem.
Django maintains two parallel hierarchies of field classes, one related
to models that correspond to table columns and one that maps these
fields to forms. This works ok for the admin interface and in many
typical cases, but what if one wants to have an alternative or
additional widget associated to a field ? For instance, say I have a
"birthday" DateField that I want to render as a date range widget in a
search form ("From - Up to"). What I did so far was a DateRangeField
subclass of DateField and overrode the necessary methods. This works
for rendering the form but breaks several other things (e.g. in the
admin interface I still want to show the field as regular DateField
widget, not a range; also the backend knows nothing about how to map a
DateRangeField to a table column). Any ideas on how to decouple the
field from its widget(s), even by tweaking/patching Django itself ?
George