TimeField Problem/Question

[Brett Hoerner]

(latest svn checkout)

I can't seem to get a meta.TimeField to work properly (using the admin
panel for now). DateField works fine, and DateTimeField works only if
I let auto_now_add do the work (in other words, if auto_now_add is True
and I don't set the Date/Time manually)

Anyways, for now... TimeField.

******
MODEL:
******

class Post(meta.Model):
date = meta.DateField(auto_now_add=True)
time = meta.TimeField(auto_now_add=True)
modified = meta.DateTimeField(auto_now=True)
title = meta.CharField(maxlength=50)
post_slug = meta.SlugField(blank=True)
content = meta.TextField()
category = meta.ForeignKey(Category, blank=True, null=True)
status = meta.CharField(maxlength=2, choices=STATUS_CHOICES,
radio_admin=True, default='DR')
comment_status = meta.CharField(maxlength=2,
choices=COMMENT_STATUS_CHOICES, radio_admin=True, default='OP')

class META:
unique_together = (("date", "post_slug"),)
module_constants={'slugify': slugify}
admin = meta.Admin(
fields = (
('General', {'fields': ('title', 'category',
'content',)}),
('Status Settings', {'fields': ('status',
'comment_status',)}),
('Date and Time', {'fields': ('date', 'time',)}),
),
)

******
ERROR:
******

KeyError at /admin/blog/posts/add/
"Could not find Formfield or InlineObjectCollection named 'time'"
Request Method: GET
Request URL: http://localhost:8000/admin/blog/posts/add/
Exception Type: KeyError
Exception Value: "Could not find Formfield or InlineObjectCollection
named 'time'"
Exception Location:
C:\Python24\lib\site-packages\django\core\formfields.py in
__getitem__, line 119

I can post more as needed, but this is all I really have to work on now
and I'm pretty confused.

(egenix-mxDateTime 2.0.6, if that matters)

[Brett Hoerner]

By the way, someone noted that I was using "time" and "date" - both
reserved words. Woops. Well, I changed them to "time_posted",
"date_posted", etc, and I still get the same error.

KeyError at /admin/blog/posts/add/
"Could not find Formfield or InlineObjectCollection named 'time_posted'"

[Brett Hoerner]

luminosity in IRC asked if I tried it without "auto_now_add=True" ... I
tried, and it worked.

So what am I doing wrong with "auto_now_add" here?

[Brett Hoerner]

Ah, well... I've realized by messing around that "auto_now_add" assumes
you aren't even going to display it. I was assuming that it would
auto_add if you left it blank ... woops yet again. I think that would
be nice though, or at least clear that up in the Docs, unless I missed
something. :P

[Daniel Ericsson]

I'm not sure you are doing anything wrong. When you set auto_now or
auto_now_add on the TimeField it isn't editable. Inserting it into
the Admin with the META-fields property should maybe revert this and
it does for DateField and DateTimeField but not for TimeField. I've
only had a look at the meta code and if you comment out 629 in django/
core/meta/fields.py and insert kwargs['blank'] = True as for
DateFields you will see your TimeField.

django/core/meta/fields.py
624 class TimeField(Field):
625 empty_strings_allowed = False
626 def __init__(self, verbose_name=None, name=None,
auto_now=False, auto_now_add=False, **kwargs):
627 self.auto_now, self.auto_now_add = auto_now, auto_now_add
628 if auto_now or auto_now_add:
629 #kwargs['editable'] = False
630 kwargs['blank'] = True
631 Field.__init__(self, verbose_name, name, **kwargs)

- Daniel

[Brett Hoerner]

Thanks, so... should this be changed in the Django-svn, or is this some
special functionality I should really need/depend on?

Also, I still think that users should be able to over-ride the values
with auto_add[_now] on ... if they post data that should 'take', if the
field is blank it should do the normal stuff, if that makes sense.
Just a vote though, maybe I'm not seeing a reason for the way it is?

Thanks much though, Daniel.

[Daniel Ericsson]

On 8 dec 2005, at 06.16, Daniel Ericsson wrote:

> On 8 dec 2005, at 04.18, Brett Hoerner wrote:
>
>> luminosity in IRC asked if I tried it without
>> "auto_now_add=True" ... I
>> tried, and it worked.
>>
>> So what am I doing wrong with "auto_now_add" here?
>
> I'm not sure you are doing anything wrong. When you set auto_now or
> auto_now_add on the TimeField it isn't editable. Inserting it into
> the Admin with the META-fields property should maybe revert this
> and it does for DateField and DateTimeField but not for TimeField.
> I've only had a look at the meta code and if you comment out 629 in

> django/core/meta/fields.py and insert kwargs['blank'] = True as for

> DateFields you will see your TimeField.
>
> django/core/meta/fields.py
> 624 class TimeField(Field):
> 625 empty_strings_allowed = False
> 626 def __init__(self, verbose_name=None, name=None,
> auto_now=False, auto_now_add=False, **kwargs):
> 627 self.auto_now, self.auto_now_add = auto_now,
> auto_now_add
> 628 if auto_now or auto_now_add:
> 629 #kwargs['editable'] = False
> 630 kwargs['blank'] = True
> 631 Field.__init__(self, verbose_name, name, **kwargs)

There seem to be a fix in the new-admin branch -> http://
code.djangoproject.com/changeset/1244

- Daniel

[Tom Tobin]

On 12/8/05, Daniel Ericsson <de...@monowerks.com> wrote:
> There seem to be a fix in the new-admin branch -> http://
> code.djangoproject.com/changeset/1244

Or, in other words, the current trunk, since new-admin got merged a
little while back. :-)

In general, if you're having a problem and you're using 0.90, try out
trunk to see if your problem has already been solved -- just like
magic! :-D

[Brett Hoerner]

Well, I'm using the latest svn checkout, at least as of last night, as
I noted in my first problem post. So, the error with TimeField and
auto_add* is still there for me.

[Tom Tobin]

I guess I got thrown off by Daniel's suggestion; sorry to hear that
the problem's still there for you. :-(

[Daniel Ericsson]

On 8 dec 2005, at 06.41, Tom Tobin wrote:

> On 12/8/05, Daniel Ericsson <de...@monowerks.com> wrote:
>
>> There seem to be a fix in the new-admin branch -> http://
>> code.djangoproject.com/changeset/1244
>
> Or, in other words, the current trunk, since new-admin got merged a
> little while back. :-)

Your're right, somehow I got the impression that was a recent commit.
Actually wondered why it was against new-admin since it has been merged.

- Daniel

[Robert Wittams]

both auto_now and auto_now_add are quite hackish little puppies.

auto_now should really be equivalent to a _pre_save that sets the field
to the current time.

auto_now_add should really be equivalent to a non-editable field that
gets set to the current time on insert, and is just statically displayed
afterwards.

So to get these working 'well', I think we need :

* the event framework for fields to add handlers to (just like
ImageField, FileField etc. ) I will probably hack this up as just lists
of callbacks for now, but I would still prefer a real event system.

* the ability for FormFields to be replaced by static versions, eg
allowing special things to be put in the follow argument of the
manipulator, maybe a constant or even a FormField class.

This could alternatively be hacked around by making
TimeField,DateTimeField and DateField return different FormFields when
auto_now_add is true.

[Brett Hoerner]

Robert Wittams wrote:
> both auto_now and auto_now_add are quite hackish little puppies.
>
> auto_now should really be equivalent to a _pre_save that sets the field
> to the current time.
>
> auto_now_add should really be equivalent to a non-editable field that
> gets set to the current time on insert, and is just statically displayed
> afterwards.

I think you got them reversed, I think auto_now currently works as
intended. If you display it (your mistake I guess?) and edit it, it
will still cram in the current time on insert.

As for auto_now_add, I got rid of those and added,

def _pre_save(self):
import datetime
if (self.date_posted == None):
self.date_posted = datetime.datetime.today()
if (self.time_posted == None):
self.time_posted =
datetime.datetime.strftime(datetime.datetime.now(), "%H:%M:%s")

(by the way, for some reason date wants a datetime object, and time
wants either a datetime object or a string, I think... if you give time
a datetime object it won't insert H:M:S though (as it would if you set
the time manually through the form) - it puts in the timezone too, etc.
That's why I strftime the variable, if that makes any sense, I wanted
it to be uniform across the column.

[Robert Wittams]

Brett Hoerner wrote:
> Robert Wittams wrote:
>
>>both auto_now and auto_now_add are quite hackish little puppies.
>>
>>auto_now should really be equivalent to a _pre_save that sets the field
>>to the current time.
>>
>>auto_now_add should really be equivalent to a non-editable field that
>>gets set to the current time on insert, and is just statically displayed
>>afterwards.
>
>
> I think you got them reversed, I think auto_now currently works as
> intended. If you display it (your mistake I guess?) and edit it, it
> will still cram in the current time on insert.
>

Erm, no. I was talking about the internal implementation of these options.
Even though they do work in some situations, they are hacky and do need
to be cleaned up at some point.

By "insert" I mean the initial creation of a tuple with that id in the
database, not subsequent updates of it.

[Brett Hoerner]

> By "insert" I mean the initial creation of a tuple with that id in the
> database, not subsequent updates of it.

Yeah, sorry, I was thinking "insert" in English, not INSERT as in
INSERT vs UPDATE, etc.