I can't see the problem in that article.
Also, the datetime objects have changed since then, taking a timezone
as optional parameter:
http://docs.python.org/library/datetime.html#datetime-objects
I mean we are using date/time already with our pre-save way of doing
things, why should auto_add act
get_absolute_url is just a shortcut for one stupid thing: Get some url
returned by the model.
It does not have to be about the object. It can be: google.com.
Whatever!
All the things you are concerned with can be created using urls+views
so you shouldn't even need to worry about get_absolute_url
Sorry about the attitude, sometimes I think a bit too much of myself.
When do you think will get implemented?
On Sep 11, 5:31 pm, Ivan Sagalaev wrote:
> drozzy wrote:
> > Yes, I Do, How about that he never replied to the Collin Grady's
> > commend about HOW it would break
Yes, I Do, How about that he never replied to the Collin Grady's
commend about HOW it would break the code.
Seems like the ticket was never discussed but monopolized by a little
hush-hush discussion...
On Sep 11, 10:55 am, Karen Tracey wrote:
> On Fri, Sep 11, 2009 at 9:40 AM, drozz
Just dug up a 2year old ticket on this:
http://code.djangoproject.com/ticket/2891
Can some core-developer modify the trunk or merge it in?
SmileyChris's patch looks good:
http://code.djangoproject.com/attachment/ticket/2891/2891-backwards-incompatible.patch
On Sep 11, 10:36 am, drozzy
It's called ADMIN_MEDIA_PREFIX in global_settings.py
On Sep 11, 10:33 am, drozzy wrote:
> Reference:http://docs.djangoproject.com/en/dev/howto/static-files/#how-to-do-it
>
> I propose we change the admin's media prefix from "media" to
> "admin_media".
Reference:
http://docs.djangoproject.com/en/dev/howto/static-files/#how-to-do-it
I propose we change the admin's media prefix from "media" to
"admin_media".
When I was just starting out with Django, this was a major problem, as
I could not figure out why my static media did not display correctly.
I find it amusing how people like to use fancy words like DRY, without
explaining exactly how it applies.
I am not trying to argue for keeping auto_now, but I just don't see
what the fuss is about?
The lazy date thing seems more "un-DRY" to me that this. But then
again, why not have both? + the "
Well, that is the purpose of that. I mean if you want a custom field
that saves only on Thursday, it makes sense to write a modified save
routine..
On Sep 10, 1:19 pm, Andrew Gwozdziewycz wrote:
> On Thu, Sep 10, 2009 at 9:35 AM, Ryan K wrote:
> > I'm trying to give advice to people but I can't
I see, but what strikes me as odd is the comment in the source:
"#HACKs : auto_now_add/auto_now should be done as a default or a
pre_save."
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To
Hi,
I've looked at the svn and I don't quite understand what's wrong with
auto_now or auto_now_add.
Can you see a problem with it?
http://code.djangoproject.com/browser/django/trunk/django/db/models/fields/__init__.py#L453
On Sep 10, 10:35 am, Ryan K wrote:
> I wrote an article
> herehttp://
Just read the "Replacing get_absolute_url proposal":
http://code.djangoproject.com/wiki/ReplacingGetAbsoluteUrl
and personally I think adding two functions get_url_path and get_url
is a lot more confusing. One can never remember which one gets the
Absolute url and which one gets the Relative url.
12 matches
Mail list logo
