Opened 16 years ago

Closed 15 years ago

Last modified 15 years ago

#6974 closed (duplicate)

Re: #6966: It's impossible to specify input_formats for DateTimeFields in ModelForms

Reported by: johannes.spielmann@… Owned by: nobody
Component: Forms Version: dev
Severity: Keywords:
Cc: James Bennett Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


Well. Sorry to open a new ticket for this, but it seems you don't want to let me post to the other one, namely #6966. So read my comments here:

"Let me rephrase my complaint:

There is no way to specify the way date and time strings work for locales other than the US. Very nice. Date and time string interpretation should be a function of the locale, not of specific fields -- which is not the case here.

I know that I can forgo the benefits of using ModelForms for DateTimeFields by manually inserting DateTimeFields and specifying an input format. But I already specified the locale and the fields.

Do you find it acceptable to repeat all this information for each and every DateTimeField? Is that the intention behind ModelForms?


Change History (7)

comment:1 Changed 16 years ago by James Bennett

Resolution: invalid
Status: newclosed

Who says you have to repeat it for each and every field? It'd be fairly easy to write a custom form field that does precisely what you want, and reuse it over and over; in the meantime, ModelForm isn't meant to automatically handle custom requirements. If you need assistance with this, please consider asking on the django-users mailing list.

comment:2 Changed 16 years ago by johannes.spielmann@…

Resolution: invalid
Status: closedreopened

This is neither an issue of automatically handling custom requirements
nor and form of coding problem on my end. This is about making the
following work:
"In this case, it would be redundant to define the field types in your
form, because you've already defined the fields in your model." [1]
As of now, the above sentence is true for locales that have the same
date/time format as the use, and false for everywhere else. So, basically
this is an internationalization issue.

Alright, since you don't seem to understand the issue here, let
me show you some code example:

class MyModel(Model):
   someDateTimeField = fields.DateTimeField(verbose_name="some datetime field",
						help_text="some help text",

If you are using your locale (or any other that happens to
have the same date/time conventions), creating a form for this model will be:

class MyModelForm(forms.ModelForm):
	class Meta:
		model = MyModel

That's it. Three lines.

However, if the application you are writing uses any other locale, this
becomes the following:

class MyModelForm(forms.ModelForm):
	class Meta:
		model = MyModel

	# per the documentation
	class MyDateTimeField(forms.DateTimeField):
		def __init__(self, *args, **kwargs):
			if not 'widget' in kwargs:
				kwargs['widget'] = forms.DateTimeWidget(input_formats=LOCALE_DEFAULT_DATETIME_FORMAT)
			super(CommentWidget, self).__init__(*args, **kwargs)

	someDateTimeField = forms.MyDateTimeField(label="some datetime field",
						  help_text="some help text",

About 13 lines. And for each DateTimeField in your Model, you have to add
at least another three lines -- that is, duplicate another three

How is this in any way DRY? How is this sane, actually? Code that does
the same thing
for different locales is so vastly different?

No, I don't think that should be the way it is. It should be something
like this:

class MyModelForm(forms.ModelForm):
	class Meta:
		# note the _, since we want to be able to localize this

Or maybe it would even be appropriate to add an entry to the settings file
containing the DEFAULT formats, since it is a global setting.
This shouldn't be too hard to do. If you want, I can code this up for you.

Oh, and please stop your condescending RTFM-attitude. I did read the manual
and I did read the code for ModelForms and it does not handle this case,
which I think it should. If you have any arguments why it shouldn't (other
than "this is a customization issue, RTFM n00b"), I would be really interested
in hearing them.

comment:4 Changed 16 years ago by anonymous

I have to agree, you guys should stop closing this ticket as invalid, international date handling in Django is still a joke
E.G: #6231

comment:5 Changed 15 years ago by Eric Holscher

milestone: 1.0 maybe
Triage Stage: UnreviewedDesign decision needed

comment:6 Changed 15 years ago by Jacob

Resolution: duplicate
Status: reopenedclosed

This is a subset of #7980, which addresses this and other shortcomings in i18n.

comment:7 Changed 15 years ago by (none)

milestone: 1.0 maybe

Milestone 1.0 maybe deleted

Note: See TracTickets for help on using tickets.
Back to Top