Opened 17 years ago
Closed 17 years ago
#5027 closed (duplicate)
cannot initial the selectdatewidget value in newforms
Reported by: | anonymous | Owned by: | Jacob |
---|---|---|---|
Component: | Forms | Version: | dev |
Severity: | Keywords: | newforms SelectDateWidget | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description
cannot initial the selectdatewidget value in newforms:
class DateForm(forms.form): date_field = forms.DateField?( widget=extras.SelectDateWidget())
the form do not initial the date field value
data = {"date_field" : "2007-04-07"} form = DateForm(initial=data)
Attachments (1)
Change History (8)
comment:1 by , 17 years ago
Component: | Uncategorized → django.newforms |
---|---|
Resolution: | → invalid |
Status: | new → closed |
comment:2 by , 17 years ago
Has patch: | set |
---|---|
Resolution: | invalid |
Status: | closed → reopened |
I came across this bug too, and it took me a while to root out the problem and see where it was actually going wrong. I was using a custom model field derived directly of DateField
(SelectDateField), here is my code:
class SelectDateField(models.DateField): def __init__(self, *args, **kwargs): if 'years' in kwargs: self.years = kwargs['years'] del(kwargs['years']) else: self.years = range(this_year - 10, this_year + 10) self.years.append(self.years[-1] + 1) super(SelectDateField, self).__init__(*args, **kwargs) def formfield(self, **kwargs): defaults = {'widget': widgets.SelectDateWidget(years=self.years)} defaults.update(kwargs) return super(SelectDateField, self).formfield(**defaults) def get_internal_type(self): return 'DateField'
My code would save dates to the database no problem, but not retrieve them. It took me a while to realize that the actual problem was because I was deriving my custom model field directly of DateField, it was passing a datetime type to SelectDateWidget's render function, instead of the selected string type. I was able to verify this, by putting some temp testing code in SelectDateWidget's render function.
In the end, the patch was very simple, cast value to a string before doing any operations such as split on it. This patch shouldn't break any previous behaviour from what I can see, so hopefully it's ok to include.
by , 17 years ago
Attachment: | widgets.diff added |
---|
Cast value to a string, in case it was a datetime type
comment:3 by , 17 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:4 by , 17 years ago
Patch needs improvement: | set |
---|
I can't figure out where this patch is supposed to be applied; can you please upload a valid patch? See http://www.djangoproject.com/documentation/contributing/#patch-style if you're not sure how to do this.
comment:5 by , 17 years ago
That's would be because I didn't know how to do an "svn diff", I simply had django svn in one folder on my hard drive, and my fixed file in another folder and manually ran the "diff" command from the command line.
Basically it's in newforms/extras/widgets.py line 35, change
value = datetime.date(*map(int, value.split('-')))
to
value = datetime.date(*map(int, str(value).split('-')))
Sorry, the diff file doesn't seem to have path info in it.
comment:6 by , 17 years ago
Hold on.. this doesn't look right. If 'value' is already a datetime instance, converting it to a string so that you can split it up, convert the pieces into ints and then back into a datetime instance is a lot more work than necessary. The right fix would be to check if it's a basestring and if so do the splitting part, otherwise just skip down to the line that extracts the pieces from the datetime.
comment:7 by , 17 years ago
Resolution: | → duplicate |
---|---|
Status: | reopened → closed |
Which is what #5917 does. I'll mark as a dupe of that.
can you double check this? I'm unable to recreate it:
What version of Django are you on?