Re: Multiple timezone support for datetime representation
> I'm going to use the same trick used by USE_L10N and explained by Anssi: set > USE_TZ to False in global_settings.py and to True in the template of > settings.py. This preserves backwards compatibility but the new code is the > default for new projects. This isn't gonna work because your new code will have a hard dependency on pytz. -Paul -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Multiple timezone support for datetime representation
Thanks Paul, Anssi, Mikhail and Daniel for reviewing the proposal! Here are some answers to your remarks. On 3 sept. 2011, at 20:19, Paul McMillan wrote: > My main concern with your proposal is that it may require two > different code paths for a lot of code. Currently, my best guess is: - limited changes in the models layer - some new code in the forms and template layers (if USE_TZ: …) - most of the duplication will be in the tests, because I have to test everything with and without USE_TZ. Of course, I can't be sure before actually writing the code :) > I would like this new code to eventually become the default setting, > but acknowledge that there doesn't seem to be a good way to do that > and maintain our current backwards compatibility (and external > dependency) policy. I'm going to use the same trick used by USE_L10N and explained by Anssi: set USE_TZ to False in global_settings.py and to True in the template of settings.py. This preserves backwards compatibility but the new code is the default for new projects. On 3 sept. 2011, at 21:19, Anssi Kääriäinen wrote: > - Performance: The USE_L10N setting made rendering tables consisting > of numbers much slower (see #14290 for example). It would be good if > there wasn't any major regressions due to this. With USE_TZ, rendering a datetime will be slower because of the conversion to local time. I have no idea of the performance of pytz. I'll do some benchmarks. > - Concurrency: My quick reading of the documentation of pytz > suggests that this should not be a problem. But your implementation > would be thread safe, right? The main problem here is localizing the > timestamps. Certainly, the implementation must be thread safe, because requests may run concurrently in different threads for users in different timezones. I'm pretty sure it will work out of the box, and it will be even more isolated if I can avoid setting os.environ['TZ'] and calling time.tzset(). > - I want to save the following information in the database: The > meeting starts at 08:00 localtime 2011-09-04. Localtime is based on > some other information, maybe the location of the meeting room. > (...) it would be very valuable if there were a way to save just a > plain datetime information in the database if the user so chooses. In my opinion, and more importantly in PostgreSQL's implementation, a DateTime represents a "point in time", in an absolute sense — ignoring relativistic effects :) For your example, I support Daniel's suggestion: use a DateField and a TimeField, plus a way to obtain the time zone (like a foreign key to the meeting room). That's exactly the information you said you wanted to store :) I've hesitated a lot to add a "naive=False/True" keyword argument to DateTimeField. Right now, I'm still convinced that mixing naive and aware DateTimes in the same application a recipe for disaster and that Django shouldn't facilitate it. On 4 sept. 2011, at 00:48, Mikhail Korobov wrote: > I have one concern though. Can you please explain why is USE_TZ option better > than introducing e.g. UtcDateTimeField? In short, Django shouldn't provide two different ways to represent a "point in time". Quoting the Zen of Python: "There should be one-- and preferably only one --obvious way to do it." > USE_TZ=True will break all existing code (including external apps) which > relies on django 1.3 documented DateTimeField behavior, this can be scary and > will introduce a lot of "if getattr(settings, USE_TZ, False): #..." > statements in external apps for backwards compatibility. This is an interesting question. For backwards compatibility, if a DateTimeField is set to a naive datetime (like datetime.datetime.now()) and USE_TZ is True, the value should be interpreted in local time and a warning should be raised. With this rule, I believe that most code should work just fine with or without USE_TZ, thanks to duck typing. Basically, what works on a naive datetime also works on an aware datetime, including timedelta arithmetic. Of course, applications dedicated to dealing with timezones may break. If you're using one, you should probably stick with USE_TZ = False. > Good UtcDateTimeField implementation can be released as a separate package > (and then eventually included in django itself). This way existing django > projects will be able to use it without waiting for a release and backwards > compatibility won't be broken. Are there obstacles in django itself that > prevent this option? In short, my proposal can't be implemented outside of core because it requires a modification of the template engine. If it could, I'm sure someone would have done it already — ticket #2626 has been open for five years. In fact, I tried to implement these ideas without modifying Django in my current project. The result is way too messy for publication, let alone for eventual inclusion in Django. My entry point in the template e
Re: CSRF verification failed. Request aborted.
i think this will help: https://docs.djangoproject.com/en/dev/ref/contrib/csrf/#how-to-use-it allink.creative Die interdisziplinäre und marktnahe Designagentur. Silvan Spross Leiter Informatik / Partner +41 43 333 30 94 allink GmbH Grubenstrasse 9 8045 Zürich allink.ch On 06.09.2011, at 14:38, austiine wrote: > wassup people, am learning django by doing a small app but my form > gives this error "CSRF verification failed. Request aborted." when i > click the submit button. i've to read about CSRF but i dont it get > quite clearly. please help > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: CSRF verification failed. Request aborted.
Please ask questions about using Django on the django-users mailing list. The topic of this list is the development of Django itself. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
CSRF verification failed. Request aborted.
wassup people, am learning django by doing a small app but my form gives this error "CSRF verification failed. Request aborted." when i click the submit button. i've to read about CSRF but i dont it get quite clearly. please help -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Suppressed template errors in admin
Am 25.08.2011 06:19, schrieb h3:
But this would have side effects on the non-admin templates too.. so
it's not ideal.
Maybe something like this:
TEMPLATE_STRING_IF_INVALID = {'default: '!! Invalid var !!',
'django.contrib.admin': ''}
I do a hack in my admin.py:
-
# some django admin stuff is broken if TEMPLATE_STRING_IF_INVALID != ""
# http://code.djangoproject.com/ticket/3579
if settings.TEMPLATE_STRING_IF_INVALID != "":
# Patch the render_to_response function ;)
from django.contrib.auth import admin as auth_admin
from django.contrib.admin import options
def patched_render_to_response(*args, **kwargs):
old = settings.TEMPLATE_STRING_IF_INVALID
settings.TEMPLATE_STRING_IF_INVALID = ""
result = render_to_response(*args, **kwargs)
settings.TEMPLATE_STRING_IF_INVALID = old
return result
options.render_to_response = patched_render_to_response
auth_admin.render_to_response = patched_render_to_response
-
So you can use TEMPLATE_STRING_IF_INVALID, but it's excluded from django admin
;)
--
Mfg.
Jens Diemer
http://www.jensdiemer.de
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Suppressed template errors in admin
On 6 Sep., 09:17, Thomas Guettler wrote: > Ole, can you please set up a a branch at github or bitbucket? Eh, is that not overkill? I don't think discussing this is worth anyone's time. No need to promise anything or elevate this to a Big Decision as long as it's about trivial non-intrusive fixes. I'm still hoping someone (Russ?) will just take the patch and apply it, and I can go back to being the happy camper. :) Ole -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
.save_m2m() failing with multi-database error
I think I might have found an issue related to https://code.djangoproject.com/ticket/14849. The last comment says to please email the django-dev group if there are any questions about the ticket, so here I am. I've done my best to provide a complete test case. I have an Event model with property 'times', which is a ManyToManyField to an EventTime model. https://gist.github.com/c7d8319df96f5eb22cf3 I am processing data from a POST request with a ModelForm on Event, with a custom field and widget: https://gist.github.com/653adb9b0ecbcc823339 The widget takes a few POST fields and generates a set of date ranges as a list of tuples [(, ), (, )...]. The to_python() method of the custom field takes the date ranges and returns a list of EventTime objects. When I try to .save_m2m() the form (test case here: https://gist.github.com/6da4f69ade9bc7dc5b3c) I get... ValueError: Cannot add "": instance is on database "default", value is on database "None" This looks it might be an issue with the new multi-database stuff. I could also be misunderstanding something, but after scouring the documentation for several hours I don't see anything implying that this wouldn't work. I suspect the unusual thing I'm doing is creating instances of a Django model within my field's to_python() method. Most of the existing fields use to_python() to cast to datetime or Decimal. Is it not possible to convert value(s) into instances of Django models? Thanks for your help. -Ben Standefer -Ben -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/uVcisHlDAzkJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Suppressed template errors in admin
On Tue, Sep 6, 2011 at 3:17 PM, Thomas Guettler wrote: > > > Am 03.09.2011 16:13, schrieb Luke Plant: >> On 25/08/11 00:39, Russell Keith-Magee wrote: >> >>> On principle, I have no objection to the idea of making the admin >>> templates more robust in the presence of TEMPLATE_STRING_IF_INVALID; >>> adding dummy values in the context sounds like a reasonable approach >>> -- *if* doing this doesn't undermine broader error handling in the >>> templates. >> >> If we call this a bug, and agree to fix it, does it mean that from now >> on for any changes to the admin template we have to be careful to test >> with TEMPLATE_STRING_IF_INVALID != '' ? >> >> That sounds kind of tedious, and I would be against making a promise >> never to break this again in the future. If we can fix it now with >> relatively little incovenience, fine, but I don't want that to turn into >> a promise. > > If the django core makes a promise that > TEMPLATE_STRING_IF_INVALID=RaiseMissingVariable() is > supported in admin (and other contrib apps), I will help to get it done. > > Up to now, that's why I don't use the template language in my apps. > > Zen of Python: Errors should never pass silently. This particular argument fails because we're not talking about Python, here. We're talking about a template language that renders to a public facing output. Errors on user-facing code isn't cool. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Suppressed template errors in admin
Am 03.09.2011 16:13, schrieb Luke Plant: > On 25/08/11 00:39, Russell Keith-Magee wrote: > >> On principle, I have no objection to the idea of making the admin >> templates more robust in the presence of TEMPLATE_STRING_IF_INVALID; >> adding dummy values in the context sounds like a reasonable approach >> -- *if* doing this doesn't undermine broader error handling in the >> templates. > > If we call this a bug, and agree to fix it, does it mean that from now > on for any changes to the admin template we have to be careful to test > with TEMPLATE_STRING_IF_INVALID != '' ? > > That sounds kind of tedious, and I would be against making a promise > never to break this again in the future. If we can fix it now with > relatively little incovenience, fine, but I don't want that to turn into > a promise. If the django core makes a promise that TEMPLATE_STRING_IF_INVALID=RaiseMissingVariable() is supported in admin (and other contrib apps), I will help to get it done. Up to now, that's why I don't use the template language in my apps. Zen of Python: Errors should never pass silently. Ole, can you please set up a a branch at github or bitbucket? Thomas -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
