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,
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 }}
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 becaus
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,
Shaw
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/B
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
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
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 col
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
9 matches
Mail list logo
