Re: South - when to start?
Just to add my tiny bit to this: I say start with South right away. But when you're ready to deploy for the first time, wipe it all and to another --initial. The reason is that South is awesome for letting you upgrade a production app that isn't allowed to stop working. So at first deployment, it's nice to start clean so you don't have all those extra migrations for each run of your unittests, etc. Shawn -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Displaying (only) custom form fields in a template.
I found a solution, but it's kind of ugly. In the form I added this:
self.fields[field_name].is_custom = True
And in the model:
{% for field in form %}
{% if field.field.is_custom %}
{{ field.label }} {{ field }}
{% endif %}
{% endfor %}
Is there a clean way to do this?
Thanks,
Shawn
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: OS Error, Permission Denined
The problem here is most likely due to the forward-slash in front of your path name. Django's trying to actually write to a non-existant folder at a level you don't have access to in any case on shared hosting. Try taking it out and see if that fixes it. Shawn -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: A better way of checking if a record exists
Bruno, Great point. I've simplified my old code quite a bit with this suggestion. After creating a dictionary with 12 items in it, I use it for the default in get_or_create, then: [setattr(product, field, value) for field, value in new_values.items()] product.save() Thanks, Shawn -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: how to retreive the body text alone of a webpage
Also, just to save you additional pain, do NOT install anything from the 3.1 series. It's deprecated and had problems. You want 3.0.8.x. According to the maintainer's site they're going to update the 3.0.8.x series to the 3.2.x series to avoid confusion in the future. http://pypi.python.org/pypi/BeautifulSoup/3.0.8.1 If you do a pip install it'll automatically download 3.1. Background: http://www.crummy.com/software/BeautifulSoup/3.1-problems.html However, once you get 3.0.8.x going you may become addicted BeautifulSoup. Shawn -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
manage.py ignores DJANGO_SETTINGS_MODULE
I have DJANGO_SETTINGS_MODULE set in my environment to an alternative settings file. The alternate file imports the original settings file and overrides some values for my development environment. Whenever I try to run ./manage.py runserver, it insists on using the settings.py on the same path as manage.py, despite the fact that running an interactive Python interpreter or a stand-alone script which imports settings from django.conf will import the proper settings file (from DJANGO_SETTINGS_MODULE). Also, this works: ./manage.py runserver --settings=$DJANGO_SETTINGS_MODULE I can see in manage.py that it assumes there's a settings.py in its own directory, but that's evidently overridden by the --settings flag. Why doesn't a correctly-set DJANGO_SETTINGS_MODULE result in the same behavior? I'm using Django 1.1.1. Thanks, Shawn -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: *Immediate* session expiration problem/bug in IE
I have an update. It turns out that setting the timeout in set_expiry to a much larger value prevents the immediate timeout. Of course, this means that people in well-behaved browsers won't time out when they should. This is despite the fact that I've tried sending both an integer (for seconds) and a timedelta object to set_expiry, as described in the docs. My next step is to have a look at HTTP_USER_AGENT in request.META and see if I can find a correlation between its value and the timeout problem. Has anyone had experience with this, especially regarding whether HTTP_USER_AGENT is reliably present and accurate? Thanks, Shawn -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Formatting datetimes - simple question
In your forms and modelforms, you can specify both the allowed input date formats and the display format. http://docs.djangoproject.com/en/1.1/ref/forms/fields/#datefield (see the input_format option) http://docs.djangoproject.com/en/1.1/ref/forms/widgets/ (see the 'format' option) As for collecting and storing your users' preferences, I leave that up to you. Shawn -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Catching User's First Log in
How about the last_login and date_joined fields in the User model? They're both set to the current date/time when the user is created. So, if the user's "first login" is when the account is created, you could check to see if they're less than a second apart. If the user is created automatically, then you can do the same check, and if they're still that close together then you know they've never logged in. I don't think there could really be any problem with race conditions, because both dates are initialized at the same time, when the user is created, so a delta of, say, two seconds should be more than enough. However, it does feel a little bit dirty to me. Not as dirty as having a boolean in a join table that has to be checked on every log in for the rest of the life of the application just for a single use, though. Shawn -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
