It is currently impossible to specify a different client-side cache value
than a server-side cache value when using both decorators *cache_control*
and *cache_page* on a view.
For example:
@cache_control(max_age=60)
> @cache_page(timeout=3600)
> def my_view():
> return HttpResponse()
This w
t have
>> further discussion on django-devs - since it already needed a BDFL
>> decision, there was no point making the pretence of discussion in a
>> wider forum. [...]
This doesn't seem odd to me. Makes perfect sense imho.
Cheers,
Danny
--
You received this message beca
sten to
post_save() on both of them to synchronize first_name/last_name/email.
Would be awesome if such a use case was covered.
Cheers,
Danny
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email t
On Thu, Mar 15, 2012 at 22:53, Danny Adair wrote:
>[...]
> I'd like to see a later, "proper" auth.user that can undo that chaos.
I originally thought you intended a setting which let's the user
switch from the existing auth to an email auth with corresponding User
mod
ng I'm going to do is to
bring in what I think the User should look like i.e. use the "auth" to
define what really is a "profile". And so will lots of projects. "The
User model needs a username for this app to work". "The User model
needs a timezone for th
red" of username that's the problem if you don't want a
username at all when authenticating against email.
It would have to be not required and check required fields in clean()
where the backend could be asked what's really required.
And there's Mr. Schema Migration aga
it's that second part that's the problem. That's
where I believe a set of settings and conditions is a kneejerk
workaround.
Cheers,
Danny
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send
On Tue, Mar 6, 2012 at 12:21, Martin Ostrovsky
wrote:
> Danny reading your reply gave me an idea to try and it worked.
>
> I switched the order of the inlines. So I put C first, then B. This way C
> validates properly, then B is deleted and the cascaded deletion deletes C
> and e
x27;s a cascaded delete
invoked by the FK object's delete().
I always wondered why children don't get deleted first (which is how
the database _has_ to do it anyway).
My workaround is to delete in the correct order myself but I wish I
didn't have to.
Cheers,
Danny
--
You received this
s feature, we'd have to bless a timezone
implementation. pytz is pretty much the standard, and it's highly
recommended, but it's possible to use another implementation of tzinfo
classes if you desire."
which makes sense to me.
Cheers,
Danny
--
You received this message because
ake it the "current" timezone.
If you don't do that, the "default" timezone (TIME_ZONE setting) will
be the current timezone.
Whatever a user enters in their "current" timezone is converted to UTC
for storage - UTC is the only sane "common denominator&qu
It would be very weird for me to add a model instance and be told that
I did that "tomorrow".
Cheers,
Danny
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to d
s themselves, not the
mechanism handling them. If USE_TZ is True by default, users without
timezone experience should be advised that "today" can also be a
matter of location.
Cheers,
Danny
--
You received this message because you are subscribed to the Google Groups
"Django developers
in Sydney saving a model instance,
the date will be 21 Feb. No timezone in it.
What else would you want to express with "auto_now" - if you have two
users in different timezones, whose date is the "authoritative" one?
Cheers,
Danny
--
You received this message because
hindsight...
That makes sense, thank you.
I was personally dreaming of a pytz-based optional app where each
relevant component could be replaced. Maybe a thirdparty app will
provide this and mature until it gets added.
Cheers,
Danny
--
You received this message because you are subscribed to the Go
t
isn't (or isn't "supposed to be").
I believe the advent of "ModelAdmin.readonly_fields" is a confirmation
of this need. "R" and "U" are currently mixed together - there are
reasons for why this is the case but I don't see the historic
expl
a default None that falls
back to settings.TIME_ZONE (and probably another hook to override the
default choices).
Cheers,
Danny
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develope
Great achievement, congratulations from Belgium!
We already celebrated on our own release trip. Check out the original
Django museum and his place of birth:
http://www.think-wize.com/nl/django-10-celebration
On Sep 4, 2:07 am, "James Bennett" <[EMAIL PROTECTED]> wrote:
> The Django team is plea
18 matches
Mail list logo
